I agree with you that such functionality should be split up into separate functions. Currently, way to much modules just perform their database changes in a submit function (or something like that) without providing other modules to do the same thing through a nice interface. +1 on this idea. 2006/8/20, Angela Byron <drupal-devel@webchick.net>:

On 20-Aug-06, at 2:06 AM, Boris Mann wrote:

...

I don't know what the best approach is here, but if, as Angie says, we can make functions a bit more modular so that they CAN be called externally with predictable results...it's a good thing.

Let me elaborate for a moment what my current train of thought is.

Let's take user_admin_role() as an example. This ~50 line function encompasses full CRUD (create, read, update, delete) and then some on user roles. However, it takes no parameters, so there is no way to get in there and pull out specific pieces to do just one of the things it does.

I was thinking we could go one of two ways on this. Either a series of functions like:

user_role_create() // or user_role_insert or user_role_add user_role_read() // or user_role_get user_role_update() // or user_role_save user_role_delete() user_role_list() // retrieve a list of all user roles as an array of objects or whatever

Or one "mega" function which incorporates the logic like:

function api_user_role($op, $name = NULL, $id = 0) { switch ($op) { case 'create': db_query("INSERT INTO {role} (name) VALUES ('%s')", $name); break; case 'delete': db_query('DELETE FROM {role} WHERE rid = %d', $id); db_query('DELETE FROM {permission} WHERE rid = %d', $id); // Update the users who have this role set: db_query('DELETE FROM {users_roles} WHERE rid = %d', $id); break; // etc. } }

(I named it "api" because it would be nice if all such functions were grouped together so you could find them easily, a better prefix probably exists :))

Then, user_role would be changed internally to call:

api_user_role('create', $edit['name']); // or user_role_add($edit ['name']);

but at the same time I could put in my install file:

api_user_role('create', 'Seamonkey'); // or user_role_add('Seamonkey');

From a calling module's point of view, there's no difference; user_admin_role() still takes no parameters, and it still encompasses all of the functionality it ever did. The difference is that now we can actually get at that functionality in bite-sized chunks to do specific things.

Obviously, each "thing" in Drupal should get its own set of functions/ mega function. I don't know which approach is better... I lean towards the micro-functions though rather than the mega-function, even though it will add to the number of functions Drupal has. Open to ideas on this point. :)

-Angie

After speaking with chx and JonBob about this, it seems pretty unrealistic to get this functionality in this release because of the rather large potential for bugs. And even if we did, it would likely be rushed and not thought out properly. So I've created an issue to talk more about this, in the hopes we can start laying down some code in Brussels: http://drupal.org/node/79684 Thanks in advance for any input. :)

Boris Mann wrote:

Yep. Definitely need to do all these things to build install profiles. And we end up with little PHP code libraries that reach into Drupal and call stuff, or try and twiddle variables, usually in somewhat unclean ways.

I don't know what the best approach is here, but if, as Angie says, we can make functions a bit more modular so that they CAN be called externally with predictable results...it's a good thing.

-- Boris I had a patch in the queue a while ago that added those sorts of functions for blocks and themes in particular -- I too found it was pretty essential for a good install profile. I'd be willing to help out with these functions.

--Jeff