Re: Servlet-JSP question
While it won't provide an answer, you may gain some insight by reading
http://www.aptura.com/technology/jspBook_Architectures.html . I'll warn
you, I haven't finished writing it yet. It is part of an effort by
several people to write a "book" on JSP.
If you're interested in more, check out
http://www.esperanto.org.nz/jspbook
Lance Lavandowska
-Original Message-
From: Alik [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Sunday, June 20, 1999 9:51 PM
Subject: Servlet-JSP question
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?)
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).
Thanx in advance for your help.
_/_/_/_/ _/_/ _/ _/ http://Orbit.Stanford.EDU/~alik
_/_/ _/_/ _/ _/
_/_/_/_/ _/_/ _/_/ ftp://Orbit.Stanford.EDU/people/alik/
_/_/ _/_/ _/ _/
_/_/ _/_/_/_/ _/ _/ _/ mailto:[EMAIL PROTECTED]
=
==
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".
===
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".
Servlet-JSP question
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?)
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).
Thanx in advance for your help.
_/_/_/_/ _/_/ _/ _/ http://Orbit.Stanford.EDU/~alik
_/_/ _/_/ _/ _/
_/_/_/_/ _/_/ _/_/ ftp://Orbit.Stanford.EDU/people/alik/
_/_/ _/_/ _/ _/
_/_/ _/_/_/_/ _/ _/ _/ mailto:[EMAIL PROTECTED]
===
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".
Re: Servlet-JSP question
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
