You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Bill Pfeiffer <ws...@tampabay.rr.com> on 2001/05/16 05:20:39 UTC
Proposal: DBTags and RowSet
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
Re: Proposal: DBTags and RowSet
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
Glenn,
I've put it on my website temporarily:
http://home1.gte.net/pfeiffer/Download.html
There is no documentation with it, but essentially what I have done is
replaced ResultSet with RowSet. The RowSetTag has a couple extra attributes
to tell it where to pull the populated RowSet object from.
Note that is does require the early access RowSet implementation from Sun:
http://developer.java.sun.com/developer/earlyAccess/crs/
Let me know if you have questions on it,
Bill Pfeiffer
----- Original Message -----
From: "Glenn Nielsen" <gl...@voyager.apg.more.net>
To: <ta...@jakarta.apache.org>
Sent: Thursday, May 17, 2001 7:08 AM
Subject: Re: Proposal: DBTags and RowSet
> Bill,
>
> Could you submit your changes as a jar to the list.
> I would be interested in looking at them.
>
> Glenn
>
> Bill Pfeiffer wrote:
> >
> > Glenn,
> >
> > The reworking I've done of the DBTags - ResultSet tag is using the Sun
> > CachedRowSet. I happen to cast it to RowSet as defined by the j2ee api
but
> > the actual object creation on the ejb side is done using the early
access
> > CachedRowSet (1.0ea4) stuff.
> >
> > Bill Pfeiffer
> >
> > ----- Original Message -----
> > From: "Glenn Nielsen" <gl...@voyager.apg.more.net>
> > To: <ta...@jakarta.apache.org>
> > Sent: Wednesday, May 16, 2001 7:42 PM
> > Subject: Re: Proposal: DBTags and RowSet
> >
> > > Morgan,
> > >
> > > Recently I have been looking at the CachedRowSet now available as
> > > an early access download from Sun. The CachedRowSet combines the
> > > connection, statement, and result set into one class. It can do
> > > disconnected operations, so it works well in an environment where
> > > you want to page through sub sets from the entire result set.
> > >
> > > Take a look at:
> > >
> > > http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
> > >
> > > The question becomes, should DBTags support an API only available
> > > as from Sun as an early access download. Perhaps call it
experimental?
> > > Do a conditional build of DbTags that includes support for
CachedRowSet
> > > if it exists at build time?
> > >
> > > Regards,
> > >
> > > Glenn
> > >
> > > 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
> > > > >
> > > > >
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> > > MOREnet System Programming | * if iz ina coment. |
> > > Missouri Research and Education Network | */ |
> > > ----------------------------------------------------------------------
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
Re: Proposal: DBTags and RowSet
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Bill,
Could you submit your changes as a jar to the list.
I would be interested in looking at them.
Glenn
Bill Pfeiffer wrote:
>
> Glenn,
>
> The reworking I've done of the DBTags - ResultSet tag is using the Sun
> CachedRowSet. I happen to cast it to RowSet as defined by the j2ee api but
> the actual object creation on the ejb side is done using the early access
> CachedRowSet (1.0ea4) stuff.
>
> Bill Pfeiffer
>
> ----- Original Message -----
> From: "Glenn Nielsen" <gl...@voyager.apg.more.net>
> To: <ta...@jakarta.apache.org>
> Sent: Wednesday, May 16, 2001 7:42 PM
> Subject: Re: Proposal: DBTags and RowSet
>
> > Morgan,
> >
> > Recently I have been looking at the CachedRowSet now available as
> > an early access download from Sun. The CachedRowSet combines the
> > connection, statement, and result set into one class. It can do
> > disconnected operations, so it works well in an environment where
> > you want to page through sub sets from the entire result set.
> >
> > Take a look at:
> >
> > http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
> >
> > The question becomes, should DBTags support an API only available
> > as from Sun as an early access download. Perhaps call it experimental?
> > Do a conditional build of DbTags that includes support for CachedRowSet
> > if it exists at build time?
> >
> > Regards,
> >
> > Glenn
> >
> > 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
> > > >
> > > >
> >
> > --
> > ----------------------------------------------------------------------
> > Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> > MOREnet System Programming | * if iz ina coment. |
> > Missouri Research and Education Network | */ |
> > ----------------------------------------------------------------------
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Proposal: DBTags and RowSet
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
Glenn,
The reworking I've done of the DBTags - ResultSet tag is using the Sun
CachedRowSet. I happen to cast it to RowSet as defined by the j2ee api but
the actual object creation on the ejb side is done using the early access
CachedRowSet (1.0ea4) stuff.
Bill Pfeiffer
----- Original Message -----
From: "Glenn Nielsen" <gl...@voyager.apg.more.net>
To: <ta...@jakarta.apache.org>
Sent: Wednesday, May 16, 2001 7:42 PM
Subject: Re: Proposal: DBTags and RowSet
> Morgan,
>
> Recently I have been looking at the CachedRowSet now available as
> an early access download from Sun. The CachedRowSet combines the
> connection, statement, and result set into one class. It can do
> disconnected operations, so it works well in an environment where
> you want to page through sub sets from the entire result set.
>
> Take a look at:
>
> http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
>
> The question becomes, should DBTags support an API only available
> as from Sun as an early access download. Perhaps call it experimental?
> Do a conditional build of DbTags that includes support for CachedRowSet
> if it exists at build time?
>
> Regards,
>
> Glenn
>
> 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
> > >
> > >
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
Re: Proposal: DBTags and RowSet
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Morgan,
Recently I have been looking at the CachedRowSet now available as
an early access download from Sun. The CachedRowSet combines the
connection, statement, and result set into one class. It can do
disconnected operations, so it works well in an environment where
you want to page through sub sets from the entire result set.
Take a look at:
http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
The question becomes, should DBTags support an API only available
as from Sun as an early access download. Perhaps call it experimental?
Do a conditional build of DbTags that includes support for CachedRowSet
if it exists at build time?
Regards,
Glenn
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
> >
> >
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Proposal: DBTags and RowSet
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
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" <Ed...@Sun.COM>
To: <ta...@jakarta.apache.org>
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" <mo...@apache.org>
> > To: "Taglibs-Dev" <ta...@jakarta.apache.org>
> > Cc: "Taglibs-User" <ta...@jakarta.apache.org>
> > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>
Re: Proposal: DBTags and RowSet
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
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" <mo...@apache.org>
> To: "Taglibs-Dev" <ta...@jakarta.apache.org>
> Cc: "Taglibs-User" <ta...@jakarta.apache.org>
> 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
> > > >
> > > >
> > >
> > >
> >
> >
Re: Proposal: DBTags and RowSet
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
That all sounds good. I'll look for it in DBTags 1.1.
Thanks,
Bill
----- Original Message -----
From: "Morgan Delagrange" <mo...@apache.org>
To: <ta...@jakarta.apache.org>
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" <mo...@apache.org>
> > To: "Taglibs-Dev" <ta...@jakarta.apache.org>
> > Cc: "Taglibs-User" <ta...@jakarta.apache.org>
> > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: Proposal: DBTags and RowSet
Posted by Morgan Delagrange <mo...@apache.org>.
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" <mo...@apache.org>
> To: "Taglibs-Dev" <ta...@jakarta.apache.org>
> Cc: "Taglibs-User" <ta...@jakarta.apache.org>
> 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Proposal: DBTags and RowSet
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
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" <mo...@apache.org>
To: "Taglibs-Dev" <ta...@jakarta.apache.org>
Cc: "Taglibs-User" <ta...@jakarta.apache.org>
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
> > >
> > >
> >
> >
>
>
Re: Proposal: DBTags and RowSet
Posted by Morgan Delagrange <mo...@apache.org>.
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
> >
> >
>
>
Re: Proposal: DBTags and RowSet
Posted by Morgan Delagrange <mo...@apache.org>.
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
> >
> >
>
>
Re: Proposal: DBTags and RowSet
Posted by Morgan Delagrange <mo...@apache.org>.
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
>
>
Re: Proposal: DBTags and RowSet
Posted by Morgan Delagrange <mo...@apache.org>.
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
>
>