The Redbooks URL is: http://www.redbooks.ibm.com/
Dan
> ----------
> From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> Reply To: Craig McClanahan
> Sent: Tuesday, October 12, 1999 11:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Servlet/JSP Architecture
>
> Larry Riedel wrote:
>
> > > BTW Andrzej, in case you start thinking that Craig's design
> > > model, as he describes it below, is odd, or different, and
> > > thus to be avoided, I would encourage you to adopt it.
> >
> > And it seems to fit in well with the new J2EE Application
> > Programming Model, available for preview now at:
> >
> >
> http://developer.java.sun.com/developer/earlyAccess/j2sdkee/download-docs.
> html
> >
>
> Yep, and also in several IBM white papers on web application architecture,
> including an online Red Book (unfortunately, I've misplaced the URL :-( )
> that
> includes a pretty comprehensive application example based on this
> architectural
> model.
>
> >
> > Also, on the general topic of Servlet/JSP architecture,
> > I don't know yet if it's a good idea or not, but I am
> > tending to like the idea of not having URLs in HTML pages
> > point to actual pages/servlets, but instead just having
> > the URL be some command string which might only make sense
> > to the dispatching servlet - enough to figure out where to
> > dispatch the request.
>
> For servlets, I've dealt with this issue a couple of different ways, both
> based on
> the concept of having only one servlet in the application, which is
> responsible
> for dispatching all requests to an appropriate Action procedure.
>
> * Map the servlet to an extension (I use ".go") and
> use the portion of the request URI prior to the extension
> as the lookup key.
>
> * Map the servlet to a specific prefix, and use the value
> returned by getPathInfo() as the lookup key. Mapping
> the servlet to "/process" has a nice mnemonic feel.
>
> In these scenarios, the destination URL for the processing function that
> saves a
> customer might be something like "/customerSave.go" in the first case, or
> "/process/customerSave" in the second case. To the page author creating
> the input
> form, it matters not at all how the mapping happens -- they think in terms
> of
> business function terminology. In either case, the person developing the
> business
> logic can choose to implement a single servlet that dispatches action
> requests, or
> individual servlets for each request, simply by defining the mappings.
> Nothing
> has to change in the JSP pages.
>
> For the JSP pages themselves, I strive to name them after the purpose that
> the
> particular page serves -- for example, it might be a page named
> "/customerEdit.jsp" that contains the input form submitting to the
> customer save
> business function. In either case, the actual mechanism used to map the
> processing request to the appropriate business logic is transparent to the
> JSP
> page author (which is as it should be).
>
> Once the servlet has processed the request, and prepared any output beans,
> there
> needs to be a mechanism for identifying the page to which control should
> be
> forwarded (with RequestDispatcher.forward()) to display the results. In
> past apps
> I've been hard coding this -- which ties the business logic more tightly
> than I
> like to the user interface. More recently, I've made the action procedure
> accept
> a query parameter containing the path of the "subsequent" page to be
> displayed
> (which can be passed as a hidden field on the input form). I've seen
> other
> applications that define a lookup table to map from logical user interface
> names
> (such as "Display Customer List") to physical page URLs
> ("/displayCustomers.jsp")
> so that you can set the mapping in the initialization parameters of the
> servlet.
>
> > Also, for some reason I prefer the
> > idea of precompiling JSP pages and deploying them as servlet
> > classes, rather than deploying the raw JSP text pages and
> > compiling them on the fly when they are first requested,
> > as seems to be popular; I don't see why I want to be
> > doing that any more than deploying my whole application as
> > Java source and letting the application/web server figure
> > out what to compile as it goes along, while the user waits.
> > But then again, I have no idea what I'm talking about. :)
> >
>
> You are really going to like some of the enhancements in the JSP 1.1 and
> Servlet
> 2.2 specs, as soon as they are implemented in your favorite server:
>
> * JSP 1.1 defines a portable mechanism to request
> page precompilation that should work across any
> JSP development environment.
>
> * Servlet 2.2 defines a portable deployment format
> so that you can package up an entire application
> (servlet class files, JSP pages or class files, static
> HTML pages, and other resource files) in a Web
> Application Archive (WAR) file that can be deployed
> on any compliant server.
>
> >
> > Larry
> >
>
> Craig McClanahan
>
> ==========================================================================
> =
> 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
>
===========================================================================
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
