Ted Husted wrote:
> Being able to autogenerate the "logical data beans" would be excellent!
> And very much in keeping with the rest of the Struts framework.
> Ideally, this would be a mechanism that could also be used in other
> applications (e.g. Swing-based).
>
> So, in general terms, it seems we're coming down to this:
>
> (data bean) :: (query bean) :: (action form) :: (action object) | JSP
>
> Where the DataBean is totally unaware of Struts, and the QueryBean
> might be only vaguely aware, through use of the GenericConnection and
> GenericDataSource classes.
>
You should program in terms of the javax.sql.DataSource interface, rather than
hard coding GenericDataSource. That way, you will not be tying yourself to the
Struts connection pool implementation.
By the same reasoning, the thing you get back from DataSource.getCoinnection()
is just a java.sql.Connection -- you do *not* want to be dependent on any
particular underlying implementation.
>
> I would also say that the QueryBean should be able to read its base
> query from a resource file, so that these can be adjusted without
> recompiling (and centralized for control and documentation).
>
If you do it this way, do you need more than one QueryBean? Couldn't you create
a generic one that processes different kinds of query strings based on the name
of the resource you told it to read?
>
> In my own work, I subclassed the QueryBean from ActionFormBean (in case
> I figure out how to read it from the struts-config file).
Let's say your QueryFormBean has a property named "resource", with corresponding
getResource() and setResource() methods. This should be configured by doing
something like this in struts-config.xml:
<form-bean name="SearchForm"
type="com.mycompany.mypackage.SearchFormBean">
<set-property property="resource" value="...path to resource..."/>
</form-bean>
but it won't work until tonight's nightly build, when I make it legal to embed
<set-property/> inside a <form-bean> :-)
> In the
> meantime, I tried to give it a standard properties file to read the
> base SQL strings. No problem if I hardcode a system path, but no go if
> I try to find it on the classpath. To wit:
>
> public void resetQuery() throws IOException {
> // Must call setName first!
> Properties props = new Properties();
> String name = "d:\\QueryFormBean.properties";
>
> /*
> InputStream is = null;
> is = this.getClass().getClassLoader().getResourceAsStream(name);
>
> if (is != null) {
> props.load(is);
> is.close();
> setQuery(props.getProperty(getName()));
> }
> */
>
> FileInputStream in = new FileInputStream(name);
> props.load(in);
> setQuery(props.getProperty(getName()));
> in.close();
>
> }
>
> The commented code was taken from the Struts PropertyMessageResource,
> but doesn't seem to work. (Not that I understand what it's doing - I'm
> just banging the rocks together!) If I hardcode the path, everything is
> hunky-dory.
>
If you want to use ClassLoader().getResourceAsStream(name), the name you pass
should look like a Java class name, but with periods changed to slashes. In
other words, if your class is in package com.mycompany.mypackage, and your
resource file name is "QueryFormBean.properties", the resource name is:
com/mycompany/mypackage/QueryFormBean.properties
This resource will be looked up along the runtime classpath for your web app,
just like classes are looked up.
>
> A hacked example of all this, that works around the properties glitch,
> is available as a ZIP file at
> < http://husted.com/about/struts > as "Struts with a Fruit Glaze".
>
> Comments appreciated!
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/
Craig
