As a number of individuals have responded, they create their own
"custom" classes to deal with serializing the data out of the ResultSet
into a 'locally' managed "non-database-related" class.
This is the whole design intent of the CachedRowSet, but it will not
be a custom implementation that differs from one project/vendor/user
to the next, but is reusable across both internal projects and vendor
collaborative works, such as commercial beans.
You could argue that, just by it's packaging in the javax.sql package,
or whatever package it ends up in, that it is "database related." This
is no different from a custom class that knows how to serialize a java.sql.
ResultSet object. Any such object must be database "aware."
There is no requirement to batchUpdate ( Resynch ) the updates, or
even to update for that matter. Just understand how much flexibility
in design this model can offer you.
Remember that each JSP page is really a Servlet, and can as easily
use new java classes as it can manipulate Strings and Request data.
>To: Arthur Alexander/FSG/CSC@CSC, [EMAIL PROTECTED]
>cc: [EMAIL PROTECTED]
>Subject: RE: JDBC from JSP
>
>My application is a reporting & monitoring application. Personally, I don't
>want to use any database related classes in jsp page. Instead, I would like
>to create report (wrapper ?) beans and use them in the page. But, should I
>create a bean for each row (entity) or use a manager bean as wrapper class
>for resultset ??
>
>Any comments ??
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Monday, November 15, 1999 11:25 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: JDBC from JSP
>
>Hi Kamalesh,
>
>Ideally the new JDBC CachedRowSet would provide the best
>communication vehicle is some of the scenarios that have been
>proposed on this subject in this newsgroup.
>
>Having (virtually) a disconnected ResultSet object that you can
>pass around within the context of a JavaVM, update and then
>have resychronized against the datastore would keep you from
>the various issues of User Context, Thread affinitiy, Bean chains, etc.
>
>Just my point of view . . . comments?
>
>
>-----Original Message-----
>From: Loganathan, Kamalesh <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Monday, November 15, 1999 10:48 AM
>Subject: Re: JDBC from JSP
>
>>Is it a good idea to use the 'Resultset' class from a bean in a JSP page ?
>>
>
>>-----Original Message-----
>>From: Starsinic Frank [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, November 12, 1999 5:55 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: JDBC from JSP
>>
>>
>>>From a theoretical sense, there should (in my opinion) not be too many
>>"JDBC in a JSP page" examples out there.
>>
>>JDBC should be done in a Java Bean, perhaps, and then the JSP page can do
>>the
>><jsp:useBean > tag to gain access to the JDBC by proxy.
>>
>>>From a good architecture point of view, JDBC should not be done in a JSP
>>page.
>>
>>Comparing, JSP to ASP, i think this is where you will find JSP to be quite
>>superior.
>>
>>This helps keep the code out of the JSP....
>>
>>Keeping that in mind, here is some example code where the bean does the
>JDBC
>>and
>>the JSP page hardly does anything at all. This example shows how an
>>Application
>>Bean
>>is used to Cache database table info for the jsp application ...
>>
>>Notice how the <select> box is populated via one method call to the
>>ReferenceClientBean Bean.
>>Also, in this case, the method also excepts an "id" parameter and makes
>that
>><option > SELECTED automatically.
>>
>>The "beans" both connect to the database as RMI clients to an RMI server
>>that
>>does
>>the real connecting to the database.
>>
>>I realize that there are no JDBC calls in the JSP here, so you might be
>>pissed,
>>but I feel that
>>this is the preferred method of developing a JSP application. It separates
>>Code
>>form HTML
>>and also keeps your database code in one layer, middle tier stuff in
>another
>>layer, etc. etc.
>>
>>One key benefit of this approach that is implemented is that the Bean
>caches
>>all
>>the tables
>>in a hashtable, so the next time somone needs this info, it is looked up
in
>>cache instead of
>>the database.
>>
>><jsp:usebean id="sqlRefTables" class="ReferenceClientBean"
>>scope="application"/>
>><jsp:usebean id="sqlUserTable" class="UserBean" scope="application"/>
>>
>><% user.loadUser(request.getParameter("idno")); %>
>>
>><LOTS_OF_MISSING_HTML>
>><form method=post>
>>
>><table border=0 cellpadding=1 cellspacing=0 bgcolor=gold>
>> <td>Employee # <input name=employeeID
>>value="<%=sqlUserTable.getEmployeeID()%>"
>> length=10 maxlength=30></td><td> </td>
>>
>> <select name=job_title_k>
>> <%=
>>sqlRefTables.getHTMLReferenceList("REF_LA_JOB_TITLE",sqlUserTable.getJobTi
t
>l
>>eKey().toString())%>
>> </select>
>>
>> <select name=access_type_k>
>> <%=
>>sqlRefTables.getHTMLReferenceList("REF_LA_BRANCH_TYPE",user.getBranchAcces
s
>T
>>ypeKey().toString())
>>
>>%>
>> </select>
>></LOTS_OF_MISSING_HTML>
>>
>>
>>
>>
>>Sudha Gopalakrishnan <[EMAIL PROTECTED]> on 11/12/99 01:05:41 PM
>>Please respond to Sudha Gopalakrishnan <[EMAIL PROTECTED]>
>>
>>To: [EMAIL PROTECTED]
>>cc: (bcc: Frank Starsinic/TMS)
>>
>>Subject: JDBC from JSP
>>
>>Hi,
>>
>>Can someone point me to an example where you do
>>database connecctivity from a JSP page. ( Like you use
>>ADOs in ASPs, what is the equivalent in JSPs?)
>>
>>Thanks,
>>sudha
>>
>
>
>
>
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
