CRUD in Drupal
Posted by: dnorman in Uncategorized, tags: drupal, module, provisionator, thinkingoutloudNo. 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…)
Entries (RSS)
I am just starting to configure Provisionator module in my site, after looking for something like that for a while (tried to get Bryght’s HostMaster, but couldn’t find it online, nor got any feedback from Boris Mann).
It seems Provisionator is the right solution for my needs, and I would like to encourage you in your work.
If needed, you are welcome to ask for my help during the development and/or testing.
Regards,
Shushu
If you emailed me at my personal account, I usually take…about forever to respond
Try me at boris AT bryght.com….wait, I just found your email…from yesterday. 24 hr response time is pretty good, I think 
Hostmaster is big and nasty and complex and not for shared hosting. It is GPL’d and available at https://svn.bryght.com/hostmaster…we‘re still asking for people to have an account to get in, and we happily give that to anyone.
Darcy — so glad to continue to see you coming to the light in the full Drupal Way
— Adrian wrote some billing code around the concept of sites that might be useful.
Also, there is Erik Drexell’s backup / restore database code that might fit in in interesting ways.
I’ve been looking at the Provisionator concept twofold: one as a simple, shared hosting compatible version of easy point and click multi-site, and secondly for the concept of multisite “dashboards”. The dashboard could do cross-site operations, and maybe do interesting things with allowing users on different servers permissions across sites…think OpenID and solving the identity-to-role-by-domain issue.
P.S. Feedparser is the one true aggregator base code. I mean, Leech? Come on, even the name is slanted in the wrong direction
Another benefit of the node route will be for people working with other database platforms there should in theory be fewer headaches ..
shushu - any help is welcome. Let me do the first pass at converting to a node-based module, and I’ll update the CVS on drupal.org.
Boris - I’d love to check out the code for hostmaster. Sounds like it does some similar things, but in a different way.
I’ll take a look for Erik’s backup/restore code. Is that sympal_scripts, or something different?
I’ll also take another look at FeedParser. When I first looked, Leech sounded like a better fit, but I may have missed something. I trust your guidance, so if you say FeedParser rülz, I’ll give it a shot.
Chris - good point. Another bonus is the availability of BlogAPI, so I could build (or use) a desktop application to deploy sites on the shared Drupal server…
Boris - I just remembered what swayed me to Leech.module. It integrates nicely with Organic Groups, which lets me implement the concepts of Classes, Groups, Cohorts, etc… trivially with OG. Doesn’t look like FeedParser knows about OG.
Let me put it this way: FeedParser is built on a better foundation, and has a better chance of pieces of it making it into Drupal core.
What frustrates me is that no one bothers to, say, extend core aggregator code (or, as Feedparser did, act as a drop in replacement) so that we can have this in core. We have several architecturally half-assed solutions….
I took a few minutes to sketch out a node-based system of representing Provisionator data.
I’ve managed to see first light on the first of the two new custom content types. There will be content types for “Provisionator Site” and “Provisionator Client” - the Site is skeletonized (but not backed by database yet) as I start getting familiar with the nodeAPI and more familiar with the formsAPI.