That all sounds good. I'll look for it in DBTags 1.1.
Thanks,
Bill
----- Original Message -----
From: "Morgan Delagrange" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 12:13 PM
Subject: Re: Proposal: DBTags and RowSet
> 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
