I'll take a look at Struts, but I'm not sure I'm convinced... :) Our webapps are a collection of JSPs, all hyperlinked together. Each JSP can provide from 1 to n combinations of tables and charts on a page, where each table and chart can be of ANY table that the user has defined in his/her specific database.
For instance, your webapp may define PAGE1.JSP to include "draw DB1-Table1 as a table, draw DB1-Table1 as a chart, and DB1-Table2 as a chart". My webapp, however, may have a PAGE1.JSP that says "draw DB1-Table9 as a chart, and draw DB2-Table1 as a chart". If that's the case, when the user asks for a given page, how else can I determine which tables to load in the controller servlet without first looking inside the requested JSP? Thanks again. And I'll take a look at Struts and make sure there's not something obvious I'm missing. Jay > -----Original Message----- > From: Richard Yee [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 11:09 AM > To: [EMAIL PROTECTED] > Subject: Re: Model 2 questions > > > Jay, > One approach is to separate your JSP pages into different > 'actions''. The > controller servlet can then determine route the request to > the particular > action handler class or code which in turn handles the > instantiation of the > necessary beans for the page and then forwards the request to the > appropriate view JSP. This is how the Jakarta Struts > framework works. Check > out jakarta.apache.org/struts. > > There is no need to parse the JSP file. > > Regards, > > Richard > > At 10:52 AM 4/25/2002 -0500, you wrote: > >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
