> -----Original Message-----
> From: Ian Bicking [mailto:ianb@...]
> On Wed, 2002-11-13 at 17:43, Stuart Donaldson wrote:
> > I was looking for a clean way to implement my own Session class.
> > It appears that this is passed into the constructor for
> > however the specific Application is called for out of
> AppServer which is sub
> > classed by ThreadedAppServer.
> > So, my plan was to create:
> > class MyAppServer(ThreadedAppServer):
> > ...
> > def createApplication(self):
> > return Application(server=self, sessionClass=MySessionClass)
> > It seems like the lower layers are pretty well designed
> with the idea of
> > supporting this kind of behavioral change through sub
> classing. It's just
> > that the ThreadedAppServer module didn't carry all of that
> through, and
> > seems to be designed a little more as a terminal class.
> That was a portion of the design that was never really fleshed out.
> Another approach is MiscUtils.MixIn, which might work better for you,
> since it doesn't require subclassing, which makes it easier to upgrade
> and easier to exchange and intermix code.
It looks like the MixIn approach would work, but it doesn't feel like a good
solution. Perhaps I just don't have enough of the python religion, but it
feels like this kind of solution should be reserved for extreme cases.
The well designed solution seems to encourage the approach of overriding the
methods through subclassing. This works better for documentation tools, and
just plain old following the code. The idea of the MixIn is pretty cool for
cases where subclassing can't be implemented. But in the case of Webware,
we have control over the modules in question, and the design of the rest of
the system seems to support subclassing.
I would prefer to see the ThreadedAppServer support the subclassing approach
just as its base class does.
Any chance we can get this fixed? If you want, I'd be happy to create a
proposed patch which improves the ability to subclass ThreadedAppServer.
Who would I send it off too?
BTW - Should this type of discussion actually be taking on the webware-dev
list, rather than the webware-discuss list? webware-dev doesn't seem to get
into much technical details, and I'm wondering if we're just sort of
defaulting to using webware-discuss?