Defining the SQL commands in struts-config.xml is definately a
leap-forward (I missed link to the sample WAR at first, and
didn't see how you were implementing everything.)
Though, if stay on this road, larger project swill have to start
assembling their struts-config.xml from smaller files, as some
people do with their Applicaton Resource now. ;-)
The bean factory proposal seems excellent, and I'm going to try
and take a closer at it this weekend.
< http://www.sura.ru/~gonza/bean-factory/ >
It's an exciting idea, and works well with the J2EE patterns I'm
using now.
Being able to define the various beans we need in XML could bring
a real productivity boost to a lot of Struts developers, myself
included. I'm also getting ready to do something about a code
generator, which could work well with a factory like this.
Incidentally, getting this to work is a real testament of how
easy Java app configuration can be. Edited two lines
in struts-config.xml and I'm up and running with some other
DBMS.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Oleg V Alexeev wrote:
> TH> Speaking of configuration issues, I've also played with the idea of
> TH> loading SQL commands from a resource, so they could be changed and
> TH> reloaded without restarting the application. It would also be easier to
> TH> optimize command sets for different DBMS packages. Just wondering if
> TH> anyone else has implemented a SQL command resource.
>
> I already implement this as part of my bean generation framework. It
> contains JDBC bean factories (for single row, for all rows from result
> set, for window from the result set) and bean-templates (may be wrong
> term, of course) in which SQL queries can be defined. At bean creation
> process factory uses attributes, properties and parameters from
> request (all needed for this bean=template) and conserves result in
> session or request scope to display with jsp page.
