Jason Hildebrand wrote:
> On Wed, 2004-02-25 at 13:37, Aaron Held wrote:
>> Personally I would be against subclassing a 'core' class such as
>> sessions, I would rather see some hooks for calling implementation
>> specific code.
> Hi Aaron,
> I'm curious as to your rationale for preferring hooks over
> using subclasses
> to do customization. I keep my own copies of modified
> Webware source in CVS
> (merging is a painful operation), so I'm interested in making
> Webware more
> extensibile too, but I'm unsure of how we can best achieve this.
> Several years ago I wrote a framework in PHP which provided a lot of
> callbacks for customization. On problem I ran into is that
> depending on
> how you need to customize, you might want to execute some code before,
> instead of, or after an event:
> This led to a proliferation of callback functions which
> achieved the goal of
> customizability, but had several shortcomings:
> - difficult to keep track of all the callback methods and
> their names
> - to maintain sanity, the three callbacks for an event (pre, the
> event itself, and post) need to have the same parameters, which
> means changing in three places
> - I ended up with a pile of 'bare' callback functions (not
> attached to a class), for which it would be difficult for
> else to understand
> the interplay.
> I eventually realized that using classes would clean a lot of this up.
> With classes you only need one method per event. Any subclass which
> overrides this method can call the superclass' method (or not) when it
> needs to, thereby controlling whether the new functionality
> is executed
> before, instead of, or after the event.
> This is food for thought. I'd like to hear more about what
> you envision for
> a good way to make Webware extensible -- maybe we can make
> some progress on
> this front.
I think I agree with you, Jason -- Webware should provide an easy hook to
swap in a subclass for a key class like Session and it shouldn't feel like a
hack. The Mixin stuff feels like too much of a hack, and adding a bunch of
hooks at specific places in the code just adds clutter.
Perhaps a setting in Application.Config could specify classes to use in
place of the standard classes:
'Session': 'MyPackage.MyModule:MySession' ,
The syntax on the right side is the same as PSP syntax for specifying a base
class. This would get translated at runtime into this:
from MyPackage.MyModule import MySession as Session
from MyPackage.MyModule import MyRequest as Request
Just a thought...