I haven't gone in that direction because I haven't had the need myself.
However, I am using the Sun early access RowSet classes. This package
provides a class called WebRowSet that extends the CachedRowSet. It provides
XML reader/writer capability. I don't know much about java XML parsing, but
it looks like this implementation will allow you to read/write result sets
to io streams as xml document streams. It also APPEARS to allow you to plug
in different parsers via the XmlRead/XmlWriter interfaces (not really sure
about this).
My major focus right now is getting the RowSet integrated with current
DBTags. I have a need on two projects I'm working on to generate tabled up
data and the RowSet seems to give me the n-tier way to do it. Using DBTags
to handle the RowSet gives me a clean tag-based means of presenting it.
Bill Pfeiffer
----- Original Message -----
From: "Eduardo Pelegri-Llopart" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 7:53 PM
Subject: Re: Proposal: DBTags and RowSet
> Have you considered providing an XML view of the rowset? There have
> been proposals along that direction for a while, and actually JSR-114
> specifically mentions that approach.
>
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_114_rowset.html
>
> JSR-114 is still quite early so there are no specific proposals to play
> with, but you could follow that direction and see what we all learn.
>
> - eduard/o
>
> 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>
