Your answer to my first question makes complete sense.  I assumed that was
the case, but wanted to make sure there weren't other issues to be aware
of. (I'm a JSP newbie.)

However, regarding the second question, I'd like to limit myself to one
physical page per application page.  Given that, it seems like my
controller servlet is going to have to:

(1) Open up and parse the JSP.

(2) Find all references to "Tables" (as explained in my example).

(3) Load each database table exactly once (even if it is referenced more
than once on the page).

(4) Create one bean per loaded table.

(5) Forward these beans to the JSP for rendering.

I'm wondering if I can leverage Jasper somehow, as I'm using Tomcat as my
servlet/JSP environment?

Thanks for responding.

Jay

 > -----Original Message-----
 > From: Chen, Gin [mailto:[EMAIL PROTECTED]]
 > Sent: Thursday, April 25, 2002 10:27 AM
 > To: [EMAIL PROTECTED]
 > Subject: Re: Model 2 questions
 >
 >
 > Suggestions/Comments inline.
 > -Tim
 >
 > -----Original Message-----
 > From: Jay Burgess [mailto:[EMAIL PROTECTED]]
 > Sent: Thursday, April 25, 2002 10:22 AM
 > To: [EMAIL PROTECTED]
 > Subject: Model 2 questions
 >
 >
 > (I got no replies on the JSP list to these questions, so I
 > thought I'd try
 > here...)
 >
 > In the Model 2 architecture:
 >
 > (1) Is there a difference between having the controller
 > servlet store the
 > "model" beans in the Request or the Session before forwarding
 > to the JSP?
 > Is one better than the other, or preferred from some reason?
 >
 > >>>
 >         The request object "dies" after it receives a
 > response from a page.
 > Therefore, it really depends on what you need the bean for.
 > For example: if
 > I have a bean that is being used to display a snapshot stat
 > of something
 > (like box scores etc) I might only want this bean to be used
 > one time in
 > that page. And after it is displayed.. I dont need it again
 > (why keep it if
 > they dont want to see the scores anymore). Therefore, just
 > put it into the
 > request. But if I have a shopping cart and that is
 > represented by a bean.
 > Then I want to keep that around not just for the page that
 > shows it.. but
 > for any page that uses it.
 > Therefore, I would want to put it into the session scope.
 > This keeps it
 > around for future use AND associates it with a particular client.
 >
 > A good rule of thumb would be... if more than one page for a
 > particular
 > client uses the bean.. store it into session scope.. if more
 > than one page
 > for ALL clients use the SAME bean and information in the bean
 > then store it
 > into application scope.. else page scope (request) will be sufficient.
 >
 > >>>
 >
 > (2) How am I supposed to handle the case where the bean(s) that the
 > controller servlet is supposed to instantiate are determined
 > by the tags
 > that are present in the requested JSP? Does the servlet have
 > to open and
 > parse the JSP somehow in this case? As an example:
 >
 > Assume I have 2 custom tags, one that displays the data from
 > a database
 > table as an HTML table, and one that creates a .JPG chart
 > image of table
 > data.
 >
 > If Page1.jsp contains three tags ("show Table 1 as a chart",
 > "show Table 1
 > as a table", and "show Table 2 as a table"), then I'd like to
 > load Table 1
 > data into one bean, Table 2 data into a second bean, and then
 > forward to
 > the JSP and let the custom tags do their drawing and charting
 > with the two
 > beans. This is most efficient, as I'm only requesting data for Table 1
 > once, even though it's being used twice in the JSP.
 >
 > But in this scenario, how can my controller servlet determine which
 > table(s) it needs to create beans for from the database?
 >
 > >>>
 >         The best way to do this is for another page to send a
 > request to the
 > Servlet to tell it what is needed before the Servlet sends out to the
 > displaying JSP.
 >         Another way to do it is for the displaying JSP to set
 > up the bean
 > (using useBean). Of course if it needs to do some data
 > population/calculation.. this is not really the preferred approach.
 > >>>
 >
 > Jay
 >

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to