No. Not crud. CRUD. Create, Read, Update, Delete. The basic operations a web app needs to do on database records.
I’ve been working on the Provisionator module, which helps with institutional-scale deployments of Drupal sites on a shared hosting server. The module began life as a separate PHP application, and evolved into a Drupal module wrapping those functions. It essentially managed a table within a Drupal site’s database, adding rows for each website deployed.
I was just working on adding the rest of the CRUD support (it already handled Create and Read OK, but not Update (edit) nor Delete). I was looking for The Drupal Way™ when it hit me. I don’t know why I didn’t see it before.
I don’t need to manage a table, nor do I need to manually implement CRUD operations.
All I need to do is define a custom content/node type, and let Drupal take care of the basic CRUD operations. The Provisionator module will then simply implement relevant bits of the node API and have it get called when nodes of the appropriate type are inserted, edited, or deleted. I can add whatever “fields” I want as properties of the custom node type, so it should be easier to extend than the current hard-coded table.
I’m going to attempt converting to the Drupal node + hooks + node API pattern ASAP. I think it’s going to be relatively straightforward, and offers some pretty cool benefits. Instead of having an essentially static list of sites in a custom database table, I’ll be able to add sites (as nodes) to various taxonomies, enable comments on the site node, and easily implement various permissions (user can create sites, user can list sites, user can edit all sites, user can edit own sites, user can delete all sites, user can delete own sites, etc…)
No. Not crud. CRUD. Create, Read, Update, Delete. The basic operations a web app needs to do on database records.
I’ve been working on the Provisionator module, which helps with institutional-scale deployments of Drupal sites on a shared hosting server. The module began life as a separate PHP application, and evolved into a Drupal module wrapping those functions. It essentially managed a table within a Drupal site’s database, adding rows for each website deployed.
I was just working on adding the rest of the CRUD support (it already handled Create and Read OK, but not Update (edit) nor Delete). I was looking for The Drupal Way™ when it hit me. I don’t know why I didn’t see it before.
I don’t need to manage a table, nor do I need to manually implement CRUD operations.
All I need to do is define a custom content/node type, and let Drupal take care of the basic CRUD operations. The Provisionator module will then simply implement relevant bits of the node API and have it get called when nodes of the appropriate type are inserted, edited, or deleted. I can add whatever “fields” I want as properties of the custom node type, so it should be easier to extend than the current hard-coded table.
I’m going to attempt converting to the Drupal node + hooks + node API pattern ASAP. I think it’s going to be relatively straightforward, and offers some pretty cool benefits. Instead of having an essentially static list of sites in a custom database table, I’ll be able to add sites (as nodes) to various taxonomies, enable comments on the site node, and easily implement various permissions (user can create sites, user can list sites, user can edit all sites, user can edit own sites, user can delete all sites, user can delete own sites, etc…)
Related
Comments are closed.