Alik wrote:
> Hello.
>
> First of all, I am new to this list, so if the question I am asking was
> previously covered, please point me to the appropriate archive (and accept
> my appologies)
>
> I am trying to build an application that separates business logic from
> presentation (i.e. I want to allow my designers to work separately from
> programmers).
> Most "large" systems that do that (like Locomotive), although do a good job,
> require their proprietary engines - i.e. they are not fully servlet comliant
> and can't run under a generic Servlet runner.
> Couple systems that I looked at - WebMacro most notably - provide excellent
> functionality, but, again, are not standards based (i.e. they have a
> proprietary markup language).
> So now I am settling on Servlet/JSP combination, where the servlet performs
> all processing, then constructs a bean with data, selects a JSP pages and
> uses it to render the data. (This can easily be changed to XML, for example,
> by using XML/XSL parsers to process the bean, instead of the JSP engine).
>
> My two questions are:
> 1) Does this look like a sound architecture choice? (Any other suggestions?)
I'm making pretty much the same choice (stay with standard servlet and JSP
implementations) for pretty much the same reasons, and using the same
architectural approach you are, so it sounds pretty good to me :-). One thing
to note, though, is that using open-source technology like Locomotive or
WebMacro does reduce some of the pain of "proprietary" (as in non-standard --
not as in "closed to the world") technology. You do have the source code
available, in case you need to add some feature or provide support for it. If
you're concerned about platform portability, though, standards-based
implementations are the way to go.
The architecture of having servlets do the processing, and then redirect to JSP
pages for the presentation, has some compelling advantages, especially on larger
scale projects:
* Separates the functional business logic from the presentation
(in my case, I have to present the same web site in five languages,
but the functional logic is identical across all of them -- doing this
lets me reuse it without having to change five JSP pages every
time I make a single functional-level change).
* Lets people with different skillsets focus on the different portions
of the system (business logic versus presentation).
* Even if you are doing the whole thing, it helps maintenance later
to have this separation, rather than intermixing logic and presentation.
>
> 2) How do I invoke JSP from a servlet? In JSDK2.1 there is
> 'RequestDispatcher.forward()', but that seems to allow the browser to access
> that JSP page directly (i.e. if I can call 'forward("/foo.jsp")', the browser
> can call 'http://myhost.com/foo.jsp' [ignoring the incorrect semantics of
> 'forward' I used] ) - which is really bad (and I do not want to get into the
> game of setting the web-server to disallow access to certain pages from a
> browser).
>
Using RequestDispatcher.forward() is the appropriate mechanism to do this.
You've got several weapons to use in avoiding the problems of users trying to
bookmark the middle of your application and go there:
* Obscurity -- When you do a RequestDispatcher.forward(),
the browser's displayed URL doesn't change. It will normally
be the URL of the servlet that the most recent form was
submitted to. There won't necessarily be any evidence that there
is are individually addressable JSP pages at all.
* State Checking -- Your JSP pages should begin with appropriate
checks for whether they were invoked in the correct state (i.e. if
they expect some beans to be passed in the request, are they actually
there) and you can redirect the user if not. Or, if you want to be a
little more blatant, you can just let the user experience the JSP errors
that will occur because you declared a <jsp:useBean> but it isn't there :-)
* New Browser Window -- I'm setting up my Servlet/JSP based apps
to run in a new browser window with no location bar displayed, and with
status message overrides on all links. I want to train the user that this is
an application, not a web site, and the only way to move around is to use
the provided navigation controls inside the window.
I've also employed a strategy of combining multiple pieces of the resulting page
with RequestDispatcher.include() if I'm building a page in a servlet, or the
corresponding <jsp:include page="..."> directive in a JSP page. This is
especially nice for including things like common navigation controls in more
than one page, without having to use frames. The approach increases the
disincentive for users to try to access the JSP components directly as well,
because they won't see the whole thing even if they do call that URL directly.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
