I would go one step further: Write a BeanNavigator that uses reflection to navigate any arbitrary object graph consisting of regular java objects....
Frank Sauer The Technical Resource Connection, Inc. a wholly owned subsidiary of Perot Systems Tampa, FL http://www.trcinc.com ----------------------------------------------- Java: The best argument for Smalltalk since C++ -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED]] Sent: Monday, October 22, 2001 12:12 PM To: Ken Fitzpatrick; [EMAIL PROTECTED] Subject: [Jaxen] Re: Jaxen-based Implem of java.sql.ResultSet Hi Ken Funnily enough I was having a similar discussion with some of the JSPTL (standard tag library for JSP) expert group this morning - that XPath is a nice way to work with SQL result sets. I've CC'd the Jaxen list so see what other Jaxen developers and users think of this idea - it certainly sounds interesting. Just being devils advocate for a second, would a cached RowSet implementation help here? Certainly making a Navigator (say) that used a ResultSet as the 'model' sounds an interesting idea! James ----- Original Message ----- From: "Ken Fitzpatrick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 22, 2001 5:05 PM Subject: Jaxen-based Implem of java.sql.ResultSet > I have used Jaxen extensively to complete an initial > implementation of the behavior of the java.sql.ResultSet > interface (ReadOnly aspects, thus far) using an XML > Document rather than a database query ResultSet and > ResultSetMetaData. In this solution, the database query > ResultSet is executed, then converted to an XML String, > then promptly closed. The XML String can be used to create > the XML Document, which is processed using Jaxen to support > the implementation of the ResultSet behavior. > > The primary benefit of this approach is an implementation > of the behavior of a ResultSet without the associated > overhead (e.g., of holding ReadLocks across the respective > rows across the database, of having an open Connection, > Statement and Cursor, etc.) Also, in subsequent > transactions of multi-page web applications there is no > need to serialize and deserialize or repeatedly execute the > database query ResultSet, since the XML String can be more > easily serialized and deserialized and used to create > subsequent instances of the XML Document. > > Translation: The behavior of a ResultSet that can be > utilized in multi-page transactions and long-running > programs without the overhead of a database query ResultSet. > > I have designed and developed interfaces and the code for a > ResultSet-to-XMLString converter and an XMLDocument-to- > ResultSet adapter (other components are included, but not > of keen interest at this point.) I have followed the same > Abstract-with-Delegation-through-Templates design pattern > as used in the Jaxen implementation to support the various > XML models. > > There are no copyright or proprietorship issues concerning > this code, since I designed and developed it independently. > > My question is, would this be a nice addition to the Jaxen- > based Applications Hall of Fame? > Would this be a useful addition to your open source efforts? > I have a DTD that suites my purposes, but is there one > already established? > > Thanks, > Ken Fitzpatrick > www.KenFitzpatrick.com > http://www.kenfitzpatrick.com/resume/KenFitzpatrickPrintable > Resume.html > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
