On Fri, 2004-09-17 at 17:04, Cees Hek wrote:
The extra hook you have added looks like it occurs immediately after the teardown hook. So it doesn't look like it realy adds a new location for a hook, since a simple teardown hook will do exactly the same thing.
This is true at first glance but, the way I see it the teardown hook is part of a public interface that should only be implemented by the final application package. The intended use of the of the module I'm developing is like this:
package My::CGI::Application::Subclass; use base 'CGI::Application';
sub cgiapp_init { do common stuff... } sub cgiapp_finish { do common stuff... }
package Some::Future::Application use base 'My::CGI::Application::Subclass';
sub setup { do application specific stuff... } sub teardown { do application specific stuff... }
Can you explain why you need this addition? Is it because you are already using the teardown hook elsewhere, hence you can't use it again? If so, then maybe we should bring up the multi hook patch that I supplied to the list quite a while ago. This would allow you to register multiple methods to each hook. So with that patch, you could reuse the teardown hook without risking it being overridden in a subclass.
Interesting, this is one of the things that my module would provide.
Yes, but the problem is that if someone tries to subclass your application into something that they then use as a base class they will run into the same issue as having to remember to call the SUPER method.
I think its a good idea to bring up the ability to register multiple callbacks for the same hook like Cees mentioned some time before. It would also open up the door for new plugins and base classes that could be published.
For instance, things like photo galleries, mail pages, mail forms, etc won't have to be complete apps where the user just customizes the templates. But rather the user can customize the app by using it as a base class and they can register their own hooks to customize just about anything.
I thinks it at least worthy of another look.
Another solution is to just reuse the teardown method, and be sure to call $self->SUPER::teardown within any teardown method you create. This will walk up the inheritance tree and execute the teardown method of the superclass.
I thought about doing this but then it puts the onus of remembering to call SUPER::teardown on the subclassor. The idea behind what I'm working on is to make a more extensible drop in replacement for CGI::Application. I may subclass this module 6 months from now or it may get published to CPAN and then every one that uses it has to remember to SUPER::teardown
Maybe I should package up what I have so far and see what people think. I'm going to use it in a project I'm working on regardless but I was thinking about publishing it eventually anyway.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- 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]
