crud.inc

Posted by Boris Mann on March 15, 2007 at 7:30pm

Hi all -- so, great to see a handful of install profiles start showing up.

One thing I noticed today with the new "Drupal for Churches" (see the full list of install profiles here: http://cvs.drupal.org/viewcvs/drupal/contributions/profiles/) is that Mike P included the helper file "crud.inc".

This is a file that we put together that bundles simple functions for working with data structures in Drupal and configuring them "out of the box" for install profiles (fyi -- CRUD == Create / Read / Update / Delete).

See https://svn.bryght.com/dev/browser/bryghtbase/DRUPAL-5/trunk/html/profiles for the latest version. Which brings me to my point :P

We need to, I think, have this file somewhere central where we can work on it together...the version I pointed to is already updated from what Mike P checked in. I've talked to the CVS maintainers to see what the best place is...I may just check in basic.profile as well as an example, and of course we need to get started with DrupalEd as another candidate.

I think Mike P and I are the only ones using this type of crud.inc so far, but right now I'm looking to see at a) how we can pull out config from Drupal core and move it to default.profile as well as b) how to get more of these functions in core rathering than having to do somewhat hack~ish database updates.

Comments

Core efforts at CRUD

Posted by webchick on March 15, 2007 at 7:44pm

Creating a library of CRUD API functions for Drupal - mostly discussion about best practices.
General _load, _save, and _delete methods for all objects, plus a single object hook - has an actual patch.
Simplify hook_user() and user_save(), etc. to be more consistent with other object methods - efforts to simplify hook_user, etc. as they are a major barrier to the general _load, _save, etc. patch.

As far as where to put stuff like this... maybe a "Profile Helpers" profile which is just a collection of .incs, .modules, etc. that simplify or make the process of making profiles easier... it could be setup like:

/profiles/_profile_helpers/crud_inc/crud.inc
/profiles/_profile_helpers/crud_inc/README.txt
/profiles/_profile_helpers/wizard/wizard.module
/profiles/_profile_helpers/wizard/wizard.info
/profiles/_profile_helpers/wizard/README.txt

(there currently is no 'wizard' module to my knowledge, but it's only a matter of time before someone develops a generic means of injecting forms after the db setup process... I think it's one of our SoC proposals)

I "think" that CVS access can be doled out on a per-directory basis, so you could still have maintainers of individual projects and everyone else working through the issue queue. Someone would need to check with Derek/dww about that to be sure.

Re: crud for install helpers

Posted by mikey_p on March 15, 2007 at 8:15pm

I think you might just want to consider calling it install profile helpers or something like that. While it's true this all will be much easier when CRUD is in core, this still seems to go a little bit beyond what basic crud functionality would include.

BTW, Wizard module does exist. http://drupal.org/project/wizard

And it looks like the SoC project of the same name is to work on that project. I've begun some work on a module that would provide the functionality to walk the user through a set of system config forms. I hope to be able to commit something shortly.

CVS implications

Posted by dww on March 15, 2007 at 8:56pm

Dries asked me (and as usual, i made it happen) to enforce that only .profile and .txt files get committed to contributions/profiles, until we figure out how we're going to do the full packaging stuff. we do *NOT* want to duplicate code from contribs, core, etc, in this directory, we just want to add the stuff that's needed for the profile itself. at some point, you'll be able to add a [profile_name].package file or something, that defines what other code should be included with your install profile's tarball. but for now, that's not the case, so no other code (e.g. wizard.module) should go there, and our CVS access control scripts won't let you commit anything in those directories other than .txt and .profile.
We discussed making an exception for .inc files, for exactly this kind of thing. however, a single .inc file shared across *all* profiles will be hard without this "grab foo from somewhere else and include it in my tarball" functionality. core is obviously the better place for that, but that clearly doesn't help for the 5.x profiles. not sure what to do here. i'd certainly feel comfortable relaxing the ACL stuff to allow .inc in /contributions/profiles/ but, that alone won't really solve this problem. it's kind of difficult in the README.txt for the DrupalED distro to say "download the profile helpers profile, too, before you try to install this. :( but, for *right* now, at least having a single, canonical "master copy" of crud.inc is probably a good move, even if it's still difficult for end users to use it, so that things don't get forked while we work on making the install profiles actually easy to use by fixing the packaging stuff i mention above.
CVS access is per-project, not per-directory. Packaging is per project, not per-subdirectory, too. So, it's not like you could have a single /contributions/profiles/profile_helpers dir, with sub dirs for the different things you care about, and give out CVS access to each one differently, and have each one tagged/released/packaged separately. if you want that, make them separate project nodes (then you get separate issue queues, too). however, as i said above, "wizard" has no place in /contributions/profiles anyway, since it already exists in /contributions/modules and we will not duplicate code. so, perhaps you just need a single directory, that only holds crud.inc and a README.txt?

that's all the news for now. wish i had a nicer story to offer, but at this point, things are still rather primitive. problem is, it'll be a lot of work to figure out how all the packaging stuff should work, and then yet more work to actually make it happen. i have no time for this right now, and unless someone wants to offer me a nice pile of cash, it's probably not going to be able to happen very soon. i hope to at least make some progress on the design debate at OSCMS next week...

Project or Install Profile?

Posted by Boris Mann on March 15, 2007 at 10:29pm

OK, thanks for the lengthy feedback DWW, much appreciated as always.

I suspect I will create either a Project or an Install Profile to keep that master file available on d.o. I'm leaning towards a project right now.

BTW -- it seems the ACLs aren't working, because crud.inc is included in DFC / Drupal for Churches....

ACL weirdness

Posted by dww on March 16, 2007 at 2:09am

yeah, that's nuts. profiles/development even includes (forks of, EVIL!!) generate-content.php and generate-users.php from the devel module. argh. i'll look into this right away.

use of "project" is confusing...

Posted by dww on March 16, 2007 at 2:16am

huh? ;) install profiles, modules, themes, theme engines, and translations are all represented by project nodes on d.o. so, i don't understand what "create either a project or an install profile" means. maybe you meant:

"i suspect i will create a project as either a module or an install profile to keep that master file available on d.o ... i'm leaning towards a module right now."

right? if that's the case, i'd probably call it something like "install_profile_api", since that's what it's going to be -- a library of programmer interfaces to make writing install profiles easier, no?

cheers,
-derek

Sorry...

Posted by Boris Mann on March 16, 2007 at 9:12pm

I meant a module project.

nice

Posted by moshe weitzman on March 20, 2007 at 12:57am

good stuff ... except what it does is not what I would call CRUD. i guess that happens over time.

lullabot developed a similar "profile helpers" module. we must unite for D6

Why do you say it doesn't do

Posted by Boris Mann on March 20, 2007 at 8:29am

Why do you say it doesn't do CRUD? It creates, reads, and updates values in the Drupal DB.

Yep, check Angie's list of such things in core. Lots of refactoring to be done for D6. I posted elsewhere, and Dries has confirmed, that he would like to see a collection of install profiles available in core for D6, so that's probably the best place to focus.

Profile helpers module? Is it in CVS? Can I join / co maintain to stick crud.inc in there?

Committed Install Profile API

Posted by Boris Mann on March 31, 2007 at 7:48am

OK, I committed the Install Profile API -- http://drupal.org/project/install_profile_api

Please ping me if you want to co-maintain. Ideally, anyone working on install profiles will join us, and we'll work on pinpointing functions that should move to core.

Thank you -

Posted by alex_b on July 18, 2008 at 2:18pm

Very nice work. I'm a happy user of crud.inc now.

The sad thing is it's missing a sibling: every create function should have an export function as a counterpart that can export the data structure in a compatible format.

$something = array(array('really complicated'));
$export = export_something();
install_something($export);
// $something = array(array('really complicated'));

So many bits and pieces are there:

content_copy
views export / import
imagecache export

many are easy to do

permissions
roles
menus

and then: why not content export/import functions too ;P ?

http://www.twitter.com/lxbarth