Webware for Python

Ken, 

I like the "Kit" (mix-in) approach mentioned by Tom, 
this would keep the database access code properly out
of the WebKit core.  

That said, I understand the problem with the 
funcitonality that belongs in the Application 
object.  Right now my application isn't cleaning
up database connections (yuck!).  Perhaps there 
could be a "clean-up" registration function added?
This way other processes could be run when the
AppServer shuts down?

The problem I have in general is that database connectivity
is not a simple goal that has the same form for all
applications.  For instance, I have multiple databases,
each with a well-known user and password.  Alternatively,
I'm sure that there is someone with a multiple-user 
approach... who wants the database to enforce security.
Or possibly even a multi-database multiple-user approach.
The approach you are providing is too simplistic for
me... although it may work for many others.

Best,

Clark

On Wed, Oct 24, 2001 at 09:16:00PM +0200, Tom Schwaller wrote:
| Ken Lalonde wrote:
| > 
| > 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.
| 
| I personally agree to put this into the core, since it is probably the
| first thing
| people will use when developing dynamic web applications with Webware.
| I was never really happy with the situation to implement this kind
| of stuff myself.
| 
| The other possibility would be a small DBKit, which does the same thing
| and makes available some more convenience routines (some of them
| published
| on this mailinglist some time ago). I used this kind of approach a long
| time ago
| and switched to the "Derive from SitePage" approach later, but a cleaner
| solution would be nice. Maybe even a PoolKit, which makes pooling
| avaliable
| in a much general sense (like Poolman in the Java world,
| http://www.codestudio.com)
| 
| -- 
| 
| Tom Schwaller
| tschwaller@...
| http://www.python.de