On Sat, 7 Jul 2001, Ted Husted wrote:
> "JDBC RowSet Support. Update all of the relevant tags to get and set
> attributes from a JDBC RowSet (or ResultSet) object ... "
>
> So, I'm itching to do something about this. I've been wrapping my
> RowSets up in iterators and conventional JB facades, but it's like way
> too much work.
>
> I'm just getting started so if anyone has any "whiteboard" notes they'd
> like to pass along, feel free.
>
I've only got some thoughts that haven't ever made it into a document yet
...
The basic dream was that a page developer could use the <bean:write> and
friends type tags that they know and love, but the tag would be smart
enough to understand that a RowSet is treated like an array of JavaBeans,
with the columns being the properties. In an ideal world, the Action
could start out passing the RowSet, but change to an encapsulating
JavaBean, without the pages accessing this data needing to be changed.
Conceptually, this can be accomplished in (at least) two different ways:
* Extend BeanUtils/ConvertUtils/PropertyUtils to do the conversions
as necessary. Advantage: useful elsewhere besides in Struts-based
JSP pages. Disadvantage: makes a RowSet a "special case", so BeanUtils
and friends don't really treat all objects the same (the way that
they do now).
NOTE: if you decide to go this way, I'd prefer that the work be
done on the commons version of these classes. I want to migrate
Struts 1.1 to these (as soon as I go create releases over there).
* Extend all the appropriate tags (and include functionality in any
future tags) to do an appropriate "if this is a RowSet, do this;
otherwise use PropertyUtils as before" logic. Advantage: keeps
BeanUtils et. al. logically pure and simple. Disadvantage: there
are *lots* of tags that want this (although maybe we can abstract
it into RowSetUtils type functionality so it's pretty easy).
An important consideration if you use real ResultSets is in how to ensure
that the ResultSet (and the corresponding Statement) are closed, and the
underlying connection returned to the connection pool. It might be best
to mandate the use of RowSet instead, so that we can use the
"detached" RowSet implementation. That way, the Action would copy the
data into the RowSet, and release the database resources, before
forwarding to the page. (Note to self -- check the redistribution terms
on the Sun CachedRowSet implementation).
One more thing to think about at design time - even though it is not very
Model 2-ish, some folks are going to want to use things like the
"dbtags" library in jakarta-taglibs to encode their SQL queries inside
the page. It's worth at least a few minutes of thought to see if we can
cleanly interoperate with those sorts of mechanisms.
> The original TODO included XML DOMs, but I thought I would start with
> ResultSet/RowSets.
>
Makes sense.
An additional complicating factor -- the JSP standard tag library is
likely to make an early access version of their reference implementation
available "real soon now", under the jakarta-taglibs project. I know that
accessing RowSets in a manner similar to this has been discussed -- we
might want to see if the problem has been solved already there before
investing lots of effort building it into the Struts tags.
> -Ted.
>
Craig
