On 6/17/05, Michael Peters <[EMAIL PROTECTED]> wrote: > I may be in the minority, but this actually sorta bothers me. I believe > the goal of the plugin system should be to create something flexible > enough that plugin authors can create something that is as transparent > to the users as possible. The ideal would be that the user doesn't have > to call any methods themselves unless they are setting some config params.
I have to agree with you here. The point is not necesarily to make things easier for the plugin authors (that is a side benefit), but we are trying to make things easier for people using the plugins. > Just so that I'm not misunderstood, I don't like either approach. Maybe > we should have the before_hook/after_hook hooks? So call_hook() would > execute the before_hook(), hook() and after_hook(). And these > before/after hooks would act just like normal hooks. I think I am starting to go hook crazy... And not crazy in a good way ;) Let me see if I can decifer what you meant here with an example using postrun: cgiapp_postrun is the legacy method that implements the hook. We can now register a callback at the 'postrun' stage, and they all run just before legacy cgiapp_postrun method gets called. What you are proposing is that we also allow the registering of a callback after the call to cgiapp_postrun. Is that correct? That is not as major a change as I initially thought when I read your comments above. That could be easily done (in a backwards compatible way) by having a positional arguement to add_callback that is either 'before' or 'after' and it defaults to 'before'. This is only slightly different from our first attempt using 'first', 'last' and 'middle', but I think it is actually quite a bit clearer. It still doesn't really cover strict ordering, but gives a bit more flexibility. I have another (admittedly radical) idea about dealing with ordering of callbacks. If we created a method that allowed us to view a list of callbacks that are registered, then when a callback is executed, it could check to see if there are any more callbacks registered after itself (ie am I the last callback or is there another one after me). If there is another callback waiting, then this callback could register itself again at the end of the list, and then return without actually doing what it is supposed to do. Now the rest of the callbacks go through, and we get to the last one again, and it now executes as it normally would as the last callback (the callback must make sure that it doesn't bump itself to the end more than once). This idea sounds kind of dangerous to me, but might be workable in extreme situations. > > I think it's best to keep the params to 'use' for real imports or stuff > > that really needs to happen at install time. > > I agree for the most part. import() is for importing... not classs > initialization. And the param() method of C::A works well for passing > around plugin config data too. Using param() is fine for callbacks registered to an object, but what about class based callbacks? You have to remember that you will not always have $self to work with. So in that case you need to work with Class variables (Globals). Cheers, Cees --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
