Hi Bill,
If your initial goal is to simply make RowSets work within the
current ResultSet tags without much alteration, it shouldn't be a big
deal. Since RowSet extends from ResultSet, all we probably need is to
allow the ResultSet tag to optionally grab its rows from an attribute
rather than from a Statement. (This is something I've contemplated
anyway, so that people could use the resultSet tag without messing about
with the rest, if they want.)
I can't get to that link you posted for the source code, but it sounds
like you've added an XML attribute for the name of the Servlet attribute,
and an XML attribute for the scope. Actually, the latter is probably not
necessary, since we can use findAttribute() to recursively check all
scopes.
If this will meet your needs, it sounds reasonable to me. I would want to
implement it on a branch, however, since DBTags 1.0 will be released soon,
and this sounds like a good feature for DBTags 1.1.
- Morgan
On Wed, 16 May 2001, Bill Pfeiffer wrote:
> Morgan,
>
> In my opinion these properties make RowSet useful in the n-tier J2ee
> environment:
>
> 1. It implements ResultSet and can be used anywhere (including your
> ResultSet tags/nested tags) that a ResultSet can
>
> 2. It will cache updates to itself which can be perfromed by the RowSet when
> it is back on a tier that can do the update.
>
> 3. Its serializable so it travels well:)
>
> My goal with my original rework of the DBTags was to allow me to populate my
> RowSet in a Session Bean. The session bean would be called by a Struts
> action. The action puts the returned RowSet into the
> pageContext.setAttribute(), and the tag just yanks the object out of the
> specified context based on attributes set in the tag.
>
> This approach treats the RowSet as a mearly serializable ResultSet. The
> advantage to this is that it provides and easy way to get a mulitrow,
> readonly, dataset from the EJB tier to the presentation tier.
>
> Sticking with this approach, the only changes that would need to be made to
> the ResultSet tag would be how it gets its data. Perhaps adding a
> "datasource" attribute to the tag which would indicate have the following
> possible values:
> "Statement", "Page", "Request", "Session", "Applicaton". This would allow
> for either the actual execution of the Statement OR just yanking a
> "ResultSet" object out of the specified scope.
>
> Here's the code that I added to the beginning of yout
> ResultSetTag::doStartTag() code in place of the execution of the parent
> Statement. Note that RowSet can be replaced with ResultSet and it would
> still behave the same. Also note that _rsScope and rowsetId are attributes
> I added to tell me where to pull the rowset from:
>
> if (_rsScope.toUpperCase().equals("PAGE"))
> {
> _rowset = (RowSet) pageContext.getAttribute(_rowsetId);
> }
> else if (_rsScope.toUpperCase().equals("REQUEST"))
> {
> _rowset = (RowSet) pageContext.getRequest().getAttribute(_rowsetId);
> }
> else if (_rsScope.toUpperCase().equals("SESSION"))
> {
> _rowset = (RowSet) pageContext.getSession().getAttribute(_rowsetId);
> }
> else if (_rsScope.toUpperCase().equals("APPLICATION"))
> {
> _rowset = (RowSet)
> pageContext.getServletContext().getAttribute(_rowsetId);
> }
> else
> {
> throw new JspTagException("Invalid rowset scope value: '" + _rsScope +
> "'");
> }
>
> Modifying the current source to do this shouldn't be too difficult if you
> think its a good idea.
>
> Let me know,
>
> Bill Pfeiffer
>
>
> ----- Original Message -----
> From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> To: "Taglibs-Dev" <[EMAIL PROTECTED]>
> Cc: "Taglibs-User" <[EMAIL PROTECTED]>
> Sent: Wednesday, May 16, 2001 5:12 PM
> Subject: Re: Proposal: DBTags and RowSet
>
>
> > Seems like I always send emails in pairs. :)
> >
> > Bill, do you think it would be sufficient to have RowSet tags that
> > paralleled the ResultSet tags but were agnostic as to how the Servlet
> > attribute containing the RowSet was populated? That sounds like a fairly
> > manageable task. Then, I suppose, there would have to be some tag that
> > generates the RowSet itself.
> >
> > On Wed, 16 May 2001, Morgan Delagrange wrote:
> >
> > > Hey Bill,
> > >
> > > I have to admit, I'm not too up on RowSets. I have a general idea what
> > > they're supposed to do, specifically in terms of portability around the
> > > environment, but I don't know them intimately. Do you have any ideas
> > > about how specifically you might alter the API? That might ground your
> > > ideas a bit for me.
> > >
> > > On Tue, 15 May 2001, Bill Pfeiffer wrote:
> > >
> > > > BACKGROUND:
> > > >
> > > > For my current project, I have reworked the DBTags ResultSet tags (and
> > > > nested tags) to pull a javax.sql.RowSet out of a specified scope
> attribute
> > > > and make the RowSet data available. This modification removes the
> > > > statement.execute() call and allows me populate the RowSet in another
> tier
> > > > (EJB). My RowSet tag iterates just like the ResultSet tag and makes
> its
> > > > data available to nested tags in the same manner as ResultSet.
> > > >
> > > > After reviewing what I did, I thought it would make more sense for the
> > > > DBTags to support this, rather than do the rewrite that I did.
> > > >
> > > > PROPOSAL:
> > > >
> > > > I'd like to put forward the question to both the dev and user mailing
> lists:
> > > >
> > > > Does it make sense / would it be useful for the DBTags to have the
> option of
> > > > pulling a ResultSet object from some specified scope, as an
> alternative to
> > > > performing a statment.execute() to obtain a ResultSet?
> > > >
> > > > Note that the object stored in the specified scope COULD be a RowSet
> as
> > > > RowSet implements ResultSet.
> > > >
> > > > BENEFIT(S):
> > > >
> > > > The major benefit of this approach would be the seperation of data
> retrieval
> > > > (business logic) from data presentation.
> > > >
> > > >
> > > > What do you think?
> > > >
> > > > Bill Pfeiffer
> > > >
> > > >
> > >
> > >
> >
> >
>
>
