This is not an easy issue as it all resides on whether you want to actually
split things on an architectural level (ie business logic versus
presentation) or if you want to split it on a skillset level (ie who can
code java and who can code HTML/make graphics)
For example, an applet is quite clearly a presentation layer thing because
it presents something to the user and need an interface designer's input.
one could argue that a piece of inline java like this
<%
for(int i=0 ; i<rs.getRecordsSize();i++){
RowBean rob = rs.getRecords(i);
for(int j=0 ; j<rob.getColumnSize();j++){
out.print(rob.getColumn(j) + " ");
}
out.println("<BR>");
}
%>
is infact presentation logic rather than business logic, because, for
example, if one was to change the interface one would have to change this
logic.
don't get me wrong, from a skillset point of view, I'd love to have my
HTMLers use only the <DISPLAY> and <LOOP> style tags, but I can't help
thinking that perhaps this might be a little idealistic.
after all, skillsets of people working on a project affect its
time-to-market in the *FIRST* instance whereas architectural issues
generally only have their impact felt when changes to an existing
application need to be made.
brad
-----Original Message-----
From: Gabriel Wong [mailto:[EMAIL PROTECTED]]
Sent: 16 March 1999 06:11
To: [EMAIL PROTECTED]
Subject: Re: What is the so great about JSP ?!
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".
===========================================================================
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".
