I think I agree with both of your points -- allowing subclassing of ThreadedAppServer is a good idea, and also your point about calling contextInitialize in addContext.
Can you upload your diffs to the SourceForge patch manager? - Geoff > -----Original Message----- > From: Stuart Donaldson [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 19, 2002 10:32 AM > To: 'Ian Bicking' > Cc: Webware devel > Subject: RE: [Webware-devel] RE: Developer access to WebKit module > > > Ian, > I appreciate your skepticism, and think that it is healthy to > question and discuss the issues. The open discussion helps all > of us to better understand the software, and to better > organize any changes that do get in. > > That being said, there are two separate issues now as I see it: > > -- first issue: subclassing ThreadedAppServer -- > The ability to Subclass the ThreadedAppServer which I think > is a good thing: a) Subclassing continues along with the paradigm > that AppServer already uses, and allows further refinement of the > operation by a subclass. b) Subclassing is a well understood > OO paradigm of extending or altering functionality of a class. > > I think the MixIn approach is pretty cool, and offers some > advantages over subclassing. In particular as Ian points out, > the ability to have separate modules both alter the behavior > of different parts of a class. But that doesn't mean it > should be used instead of subclassing where subclassing is > the logical choice. > > On this topic, I think some minor changes to the run and main > functions within ThreadedAppServer.py will make it very easy > to subclass ThreadedAppServer. Furthermore, if these methods > (in particular 'run') were placed on the abstract baseclass > AppServer, you would have a very clean model for subclassing > and starting an appserver. Create an instance of the specified > AppServer, and then call the run method. > > -- second issue: addContext() not calling contextInitialize() -- > > While testing the MixIn alternative to subclassing > ThreadedAppServer, I discovered that addContext() method does > not call contextInitialize() if the module is already loaded. > There is a check for sys.modules.has_key(importAsName) and if > this is set, the contextInitialized() function will not > be called. This could be true if your particular module had > been imported by some other module. > > I suggest that the contextInitialized() method should be > called if it exists, and the name is not in self._contexts. > This way, other modules are free to import items under > a kit, and contextInitialize() will always be called only > once when the context is added. > > I have attached a diff which I believe solves the addContext() > problem. It also outputs an error if there was an ImportError. > Prior behavior was to simply ignore this condition. Arguably, > an ImportError might be something that should result in the > AppServer failing to load. > > -Stuart- > > > >On Mon, 2002-11-18 at 20:51, Stuart Donaldson wrote: > > > > > >>Ok, so I can see the value of MixIn() in some cases rather than > subclassing, > >>depending on what you are doing. However in my case, I > wanted to replace > the > >>createApplication method on ThreadedAppServer, and I tried > doing this in > the > >>__init__ method of my module. > >> > >>I need to import my module prior to starting the > ThreadedAppServer because > I > >>want to affect how the ThreadedAppServer starts. If I do > this, then the > >>Application method addContext() fails to call > contextInitialize() because > >>the module has already been loaded. > >> > >> > > > >If you want to change the session class, then maybe you should change > >that class directly instead of trying to change the > AppServer. If you > >want to create an entirely new session class, I can understand the > >problem. Even then, couldn't you modify the instance variable of the > >AppServer after the fact? > > > >I mean, *I'm* not opposed to making local subclassing possible, and I > >don't think anyone else is (like you say, most of the code is already > >there with this in mind) -- but I'm also not sure it's > necessary. It's > >purely in a desire to be minimal that I'm being skeptical. > > > >You mentioned sessions before -- what specifically do you > want to do? > >I.e., which class do you want to subclass (since there's a lot of > >candidates)? > > > > > > > >>Perhaps addContext() should be maintaining a list of > contexts which have > >>been initialized, rather than just initializing them if > addContext() is > the > >>actual place where they are loaded? > >> > >> > > > >I don't follow this, though. If you're looking for something with > >somewhat different semantics than addContext, maybe a plugin > that uses > >InstallInWebKit(appServer)? > > > > Ian > > > > ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
