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
