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 | [EMAIL PROTECTED] | http://www.python.de _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
