So while doing the custom data hook, CRM-1594, I also implemented a hook for setting the default values of a 'Form' in CiviCRM, CRM-3176. So now we have a defaults and validate hook for the form object. The two missing hooks are for buildQuickForm and postProcess, which I'm planning to implement in the next couple of days. This coupled with template customization will allow developers to inject form elements and save them to the database (similar to drupal hook_form_alter). I'm also planning to implement the ACL improvements as an ACL related hook (along with a sample implementation). These new features should give CiviCRM developers more power and flexibility in tailoring CiviCRM to their specific needs without hacking core.

While doing the hooks, i realized that it makes more sense to have specific hooks (as some users have advocated in the past) rather than general civicrm_pre/civicrm_post hooks. Also the various hooks take varying number of parameters. Similar to what we did with the v2 API's i'm considering standardizing on the hook function signature to:

/**                                                                                                                          
 * Hook Definition for xyz
 * 
 * @param  array (reference) $params input parameters
 *
 * @return array (reference) if error, is_error is set
 * 
 */

If a hook returns an error, it needs to set 'is_error' and give an informative message in 'error_message'. Am not sure how we'll deal with errors as yet, but we'll handle them at some stage.

This will reduce a fair amount of duplicate code across the different CMS's (Drupal, Joomla, Standalone). I don't think we lose too much functionality with this approach, but gives us the ability to send in more objects if available.

Comments / feedback on this would be great

Update: After sleeping on it and playing around with the code, i've stuck to the current scheme. Each hook will define the number of parameters it takes. Except for strings / id's all other parameters will be passed by reference. I've generalized the code at the CMS level, and avoid adding a new function for every hook. The form hooks are now commited to svn