I see your point about the dangers of using <servlet></servlet> tags. The
HTML is indeed stored on the servlet side. A workaround that my project
group implemented was to in fact provide the servlet access to external
files that contained the HTML (specified in the servlet properties file).
Admittedly this was probably not the most elegant solution, as it runs
into trouble when dealing wiht a lot of pages. We only deal with about 19
or so pages of HTML, most of which are very simple (not using tables,
even).
If I were to re-implement I would probably look into JSP. It's pretty
much for that reason that I'm following this mail list. :)
Sahala
---------------------------------------------
Sahala Swenson
Information/Decision Systems/Computer Science
Carnegie Mellon University
On Sun, 14 Mar 1999, Craig R. McClanahan wrote:
> 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".
>
===========================================================================
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".
