+1 del $op. Couldn't this also lead to some deeper integration with actions/triggers and allow people to write their own $op states as functions? <br><br>Regardless I think it's a logical progression instead of everyone writing a switch statement to parse out which $op it is everytime.<br>
<br><div class="gmail_quote">On Fri, May 9, 2008 at 8:35 AM, Moshe Weitzman <<a href="mailto:weitzman@tejasa.com">weitzman@tejasa.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree that we should move away from op to dedicated hooks. for<br>
example, hook_nodeapi_delete().<br>
<br>
Hook_help can be should be shot and killed by advanced_help module.<br>
<div class="Ih2E3d"><br>
On Fri, May 9, 2008 at 5:23 AM, Gábor Hojtsy <<a href="mailto:gabor@hojtsy.hu">gabor@hojtsy.hu</a>> wrote:<br>
</div><div><div></div><div class="Wj3C7c">> Hello,<br>
><br>
> Now that the registry patch landed, it looks like the time of $op<br>
> might be over. General hooks implementing different branches with $op<br>
> will always be loaded regardless of the exact need for them. Larry<br>
> already suggests using the more granular *_preprocess_hookname() type<br>
> of callbacks instead of the generic *_preprocess() callbacks for theme<br>
> stuff, so that only those needed will be loaded. Take nodeapi for<br>
> example. Code for loading nodes might often be needed, but not code<br>
> for updating or deleting them, right? Those could easily be admin.inc<br>
> stuff.<br>
><br>
> So what do you think about $op? Should we evaluate on a case-by-case<br>
> basis to make function level callbacks out of $op's or just do it<br>
> wholesale (no, I am not volunteering for a patch) to get an overall<br>
> consistent API.<br>
><br>
> Gabor<br>
><br>
</div></div></blockquote></div><br>