Sahala T Swenson wrote:
> One additional thing I don't think has been mentioned, however, is the
> fact that for HTML-heavy solutions HTML files can contain
> <servlet></servlet> tags which call content-producing servlets. I've
> actually found this to be great alternative to JSP since the bulk of the
> logic resides in servlet classes and not in the HTML. I am using Sun's
> Java Webserver to do this, however, so I'm not so certain how this works
> with other web servers.
>
> Sahala
>
This is true -- just as you can use NCSA-style server side includes to include
dynamic output from a CGI script, if you want to. But this does not address
one of the key issues (for many people), which is a separation of HTML
generation from Java coding.
Let's take a specific example to illustrate the point. You've got a shopping
cart application, so somewhere (presumably in an HttpSession if you're using
servlets) you have the items that the user has selected stashed away. Now,
you are designing the checkout page, and you have two basic alternatives for
the part that lists the items being purchased.
(1) <SERVLET> or other mechanism for server-side includes. The servlet
that you execute has embedded HTML codes to do the formatting, as
necessary -- for instance <TR> and </TR> tags around each item, and
<TD> and </TD> tags around each field, because you chose (in the
page itself) to use a <TABLE> to manage the overal format of the list.
(2) JSP or page-templating mechanism that uses <LOOP> tags (or the
equivalent for the page template language in use) to surround the
logic for a single row, and embeds <DISPLAY> tags to retrieve just
the data values into the HTML formatting code already present in the
page.
Either approach works. Your store site is received well, and the logic has no
bugs in it. But, like nearly every successful web site ever built, you decide
to do a visual makeover to freshen the look and feel. The logic of how things
work is still OK -- you just want to modify how it is presented. Which
approach takes more effort and coordination?
(1) Change both the page that includes the <SERVLET> tag, and the HTML code
generated by the servlet itself. In environments where the HTML is
designed
by a web designer, rather than a Java programmer, this means you are
still
forced to use the services of a Java programmer to make a "cosmetic"
change.
(2) The HTML code embedded in the JSP or page template page is modified, with
no changes at all to the business logic that is embedded in the beans
containing
the shopping cart data. All changes can be made by someone familiar with
HTML
and the JSP or page templating system in use -- leave the Java
programmers
working on the next new application until you need to change the business
logic.
IMHO, mixing business logic and presentation -- whether in a JSP page (by
using lots of <% %> scriptlets containing the logic) or in a servlet
(generating the HTML code from the servlet itself) -- is not a clean design
architecture. It works fine at "Hello, world" levels of complexity. It can
indeed scale to large 100% dynamic sites that are all servlet generated.
But I've written some of these large (70+ pages) 100% dynamic sites, and I am
speaking from experience: changing appearance after the fact in this world is
much more work, and changing the look of web sites is a constant that you have
to plan for in large scale environments. It would be even more work in a
mixed design that uses <SERVLET> tags to get the dynamic part, because the
formatting HTML codes are still split between the enclosing page and the
dynamically generated output of the servlet.
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".
