I'm very interested in any work on adding mixin classes to Application or
subclassing Application. In addition to database pooling, there are many
examples of runtime caches that can be maintained by the application. We
subclass Application to add in additional caching services for pieces of
servlet output and a content scheduling system.
I've extended AppServer to allow specification of Application classes based
on the configuration file. The methodology is borrowed from WebKit's
ServletFactory, we read in the class name from the config file and look for
it in the main WebKit path. It's a bit of a hack. I'd like to switch this
so it searches the python path or something.
Here's the change to AppServer.createApplication() and the new method,
AppServer.applicationClassName():
def createApplication(self):
'''
Creates and returns an application object. Invoked by __init__.
Reads the configurable ApplicationClassName setting
'''
appClass = self.applicationClassName()
return appClass(server=self)
def applicationClassName(self):
name = self.setting('ApplicationClassName')
print 'Appserver creating Application class: ' + name
path = self.serverSidePath(name + '.py')
g = globals()
execfile(path, g)
assert g.has_key(name), 'AppServer: Cannot find %s in file %s.' %
(name,path)
appClass = g[name]
assert type(appClass) is ClassType, 'AppServer: %s is not a ClassType.' %
appClass
assert issubclass(appClass, Application), 'AppServer: %s is not a subclass
of Application.' % appClass
return appClass
Note that OneShotAppServer.createApplication() must be changed, as well.
This is based on 0.5.1rc3 source.
Cheers,
Ben
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Geoff
Talvola
Sent: Wednesday, October 24, 2001 4:23 PM
To: Ben Parker; [EMAIL PROTECTED]
Subject: RE: [Webware-discuss] A few patches
That brings up the larger question of "where do I put resources that are
global to the application?"
I usually just put stuff like that into regular Python modules. Then
whenever I need it, I just import the module (at which time it gets
initialized) and use it. Sometimes I put in some helper methods into
SitePage to make it more convenient to use within servlets.
But the compelling reason to put this directly into Application is so that
it can shutdown cleanly. I haven't needed that up till now.
So perhaps there needs to be a more general way to register stuff into
Application so that it initializes when the app starts up, is available
throughout the whole application, AND shuts down cleanly when the appserver
is stopped.
But I still agree with Clark that specific stuff like this doesn't really
belong directly in Application; rather, there needs to be a plug-in
mechanism so that it's easy to add stuff like this into Application via a
configuration setting. Like perhaps in Application.config, there could be
a list of Python files with mixins that automatically get applied to
Application. Or a way to substitute your own derived version of
Application instead of the original Application.
At 02:43 PM 10/24/01 -0400, Ben Parker wrote:
>Second that. We've implemented centralized database access via the
>Application object as well, and were planning on adding pooling support,
but
>now I'll most likely be switching our system over to Ken's patch. We
>require central database access for a content scheduling system, which
>manages content for the servlets.
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Ken
>Lalonde
>Sent: Wednesday, October 24, 2001 10:47 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: [Webware-discuss] A few patches
>
>
>Thanks for your comments, Clark.
>
>I'd argue for putting Application.getDbConnection() in the core
>as follows:
>- putting it in SitePage makes it inaccessible
> to code that doesn't subclass SitePage.
> For example, I keep WebKit session data in a postgresql database,
> and the code to implement that is unrelated to SitePage.
> The pool is logically part of the application, not the Page servlet.
>- cleaning up DB connections at exit time is more awkward
> when subclassing SitePage. I guess you can do it with atexit,
> but it's messy, and some people won't bother.
>- it took me a little fiddling around to figure out the best way
> to do pooling connections, and I imagine others will
> waste time reinventing the same thing.
> Providing an application-wide connection pool with proper
> cleanup at exit fills a very common developer need,
> and is appropriate for the core.
>
> > From: "Clark C . Evans" <[EMAIL PROTECTED]>
> > To: Ken Lalonde <[EMAIL PROTECTED]>
> > Subject: Re: [Webware-discuss] A few patches
> >
> > Ken Lalonde wrote:
> > | * WebKit/Application.py:
> > | New method: getDbConnection()
> >
> > This is interesting, but I'm not sure that it should
> > be added to the core of WebKit since it is certainly
> > easy enough to add in one's SitePage.py
> >
> > Your other changes sound good.
--
- Geoff Talvola
[EMAIL PROTECTED]
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
