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
> >
> >
>
>
