Re: [cgiapp] feedback on ::Plugin::ConfigAuto update (a use for register_hook?)

[Cees Hek <suppressed>]

On Mon, 1 Nov 2004 09:14:22 -0500, Timothy Appnel <suppressed> wrote:
> Over the weekend I got a chance to look this code over and give it some
> thought. Here is what I came up with in no particular order.

Thanks for having a look at this stuff.

> * I think a means of automatically creating pre and post callback hooks
> for any run mode would be a nice touch.

Can you give and example of where this would be useful?  If it is just
doing this for a single runmode, then why not put the code right in
the runmode?  If you want to do it for all runmodes, then we already
have the prerun and postrun hooks.

I have used Hook::Lexwrap with CGI::Application for debugging purposes
(it allows you to wrap all functions or methods with a pre and post
callback).  Actually, it was
Sub::WrapPackages that I used, but it uses Hook::Lexwrap to do the callbacks.

> * Shouldn't the add_callback method check that a code reference is
> being passed in?

Actually, it will work if a string is passed in as well.  This is
similar to how CGI::App handles runmodes.  either pass in a ref to the
method, or the name of the method in a string.  I would probably be
useful to check anyway though.

> * The call_hook method may be better named run_callbacks,

Ya, I wouldn't have any problems changing that.

> * I think the error handling of callbacks could be more graceful and
> refined. If the callback mechanism is being used for outside
> extensibility, I don't think an app should just die if an error occurs.
> I'm partial to Class::ErrorHandler as a rather graceful means catching
> an error and handling it in a user-friendly way.

I usually only make the code die if there is an actual mistake made in
the programming.  If a developer is calling a function with the wrong
number of parameters, then I would consider that an error and the
program should die.  If a callback that doesn't exist is added, then I
would also consider that a programming error.

If you can provide some code that uses a cleaner error handling
mechanism we could look at incorporating it.

> * Also I think the hook processor should have the option of monitoring
> the return value if it so choose. One example is a callback hook that
> acts like a filter where any callback returning a false value would
> cause some step to be skipped.

How would we actually control that?  Are you suggesting that if a
callback returns a false value, then possibly the next callbacks don't
get executed?

Thanks for your input

Cheers,

-- 
Cees Hek

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed