Believe or not but I agree with both of you guys!
To me the main benefit of JSP is it is more efficient than Templates and
it allows for the PROGRAMMATIC separation of business logic and
presentation. In today's environment the separation is PROGRAMMATIC NOT
SKILL SET because as Norman points out a regular graphics designer will
have a hard time working with JSP tags given the lack of tools available
today. I think anyone considering the use of JSP should analyse both
views. So the truth is somewhere in between...
Norman Katz wrote:
>
> Craig R. McClanahan wrote:
> > 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.
>
> The fact that architectures based on mixed business logic
> and HTML are difficult to modify is not what makes using this approach a bad
> idea.
> On the contrary, it's the lack of good editing tools that are tightly
> coupled with server-side content generators whether it be
> ASP, JSP, or any other in-process thread that produces things like
> recordset loops.
>
> There have been some attempts at this, but the results I've seen
> are "lock-you-in" IDE's like Visual Interdev, that create
> excessive, hard-to-tune code that tends to be more cryptic than what you can
> do with clean loops in your own embedded scripts.
>
> I think the genesis of a solution will likely come from a
> professional HTML page layout app product company that adds
> script handling after the fact. Allaire's HomeSite is close,
> but still very much a programmer's HTML editor, rather than
> something that is within a graphic artist's comfort zone.
>
> Norm
>
> Craig R. McClanahan wrote:
> >
> > 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".
===========================================================================
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".
