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-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
