From: Jukka U. <juk...@vt...> - 2000-12-04 20:49:14
|
Sorry, I haven't been around for some days but now i am back :) This task list is great job, and some thoughts came up Wed, 29 Nov 2000, Bill Wrote : > My thoughts on tasks; these need to be prioritized and pared down, as not > all of these should be "immediates". Please comment, add, object, give > thoughts on priorities, etc. My priority list is at the bottom. > > MAIN ARCHITECTURAL STEP: > 1) separate "engine" and presentation layers, perhaps using > Model-View-Controller architecture; the goal is to have presentation totally > decoupled from the core code, so that "pluggable" presentations are easy. > I think this is number one. Should be first thing before even plan anything else. > CORE CODE TASKS: > > 4) switchable connections to multiple db`s. This was Jukka`s idea, and is > in code he sent me: Jukka, is it in cvs yet? > Not yet, but asap i hope. :) > 5) get rid of the hard-coded Class.forName(drivername) stuff at the > begining; I`m leaning toward putting the driver classnames into a properties > file so they can be read in and loaded. The version of code that was > checked in to cvs has this, but it`s not been tested at all (compiles ... > ;-) > Maybe this can be done by using command "load/unload <driver>" . Few days i tested different versions of Solid drivers and this kind of feature might be nice. But maybe drivers named in properties file is ok in version 1. > > 6) look at exception handling: right now, the tool crashes if there`s a > SQLException. it should just print a warning and continue on, especially if > it`s because of something like a typo in a query ... > I think this is basic functinality and must work. Normally exceptions are not fatal errors. > > 7) Jukka and Peter: multi-db queries, two phase commits for premier release, > or is this further in the future? > IHMO, this is not necessery for premier release but we should keep that in mind so we can "leave door open for this one". > > 8) decide on a package name; I still haven't heard from Sourceforge on using > "net.sourceforge.ijsql". > I think this is also one of fist things. If net.sourceforge is not avalable, maybe we just use Bill's domain name if that is avalable? We need real package name, but we should not make this too hard thing. > > VIEW-ORIENTED TASKS: > > 14) Servlet and/or JSP view: do we want a defined, standard servlet or jsp > view, or do we just want the core code as pluggable as possible? Or both? > ;-) I think this goes hand in hand with first architectural step and our aim should be to make core code as pluggable as possible. If we make good separation with core code and user interface code, there should not be big thing to do gui/console/servlet or whatever user interface or just api-level interface to iJsql. |