Why dont you wrap rowsets like you do with Multipart Request. ??
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 07, 2001 5:30 PM
Subject: Re: Struts 1.1 To-Do - RowSets
>
>
> 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
>
>
