On Sat, 7 Jul 2001, Ted Husted wrote:
> "Craig R. McClanahan" wrote:
> > 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).
>
> Do we need to mandate, or just recommend? I believe that since a RowSet
> is a ResultSet, we might not need to care if someone shoots themself in
> the foot or not.
>
Well, we should certainly warn against the problems if we don't
mandate! Besides the issues mentioned earlier about closing the result
set (which will be a *very* common mistake), there's also the problem that
not all ResultSet implementations are scrollable -- so you are really out
of luck if you want to do things like iterate backwards, or use the RowSet
more than once in the same page.
> Of course, I would intend to continue to snag the RowSet in the action,
> as I do now. Otherwise, I could just use dbTags.
>
> > 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.
>
> Bill Pfeiffer has already hacked the dbTags ResultTag to use RowSets.
>
> < http://husted.com/about/struts/rowsettags.htm >
>
> I'm giving it a whirl now. This would also be a useful addition to
> dbTags, since it lets you send in a ResultSet/RowSet instead of relying
> on the other tags in the library.
>
Cool.
> When you say "similar to this has been discussed", do you mean as in
>
> "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."
>
> along with the "Extend BeanUtils/ConvertUtils/PropertyUtils" part.
>
The discussions have included the above "dream" statement (transparent
access to rowsets or trees of JavaBeans), transparent access to DOM trees,
as well as XPath-based access to trees of JavaBeans, rowsets, and DOM
trees.
JSPTL won't have to deal with the "extend BeanUtils versus the tags" part,
because each implementation of JSPTL will be making their own decisions on
how to implement. (I don't believe that the reference implementation that
will appear in jakarta-taglibs uses the BeanUtils utility code.)
In many cases, the JSP page compiler will probably become smart enough to
recognize the JSPTL tags and generate optimized code for them (instead of
the generic custom tag code that is generated for Struts tags and all
other tag libraries). Thus, the JSPTL version of any given Struts tag
will generally be more performant.
> It's not so much pumping out a RowSet using something like
> getColumn(int), but also using html:link and bean:write in the same
> iteration.
>
> Right now, it's whether I put a lot of effort into wrapping RowSets in
> accessors, mutators, and iterators, or go for the Big Fix.
>
If your needs are immediate, the "big fix" is probably the right
approach. Just be aware that in the long term future it will make sense
for Struts based apps to migrate to JSPTL tags (once they become widely
available and implemented).
> -Ted.
>
Craig
