Hello there,
If it just the case that you prefer to use other tools to achieve your
desired outcomes then the subject of your posting is rather misleading.
Speaking from experience a well designed framework can make efficient use of
JSPs in the presentation layer without resorting to large chunks of business
or processing logic in the page.
On the other hand an important issue worth considering when choosing any
tool is whether the vendor has sufficient resources to continue to improve
and support the tool.
cheers
Patrick Brosnan
Sydney, New South Wales
[EMAIL PROTECTED]
----- Original Message -----
From: "Brad Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, 27 May 2001 9:30 PM
Subject: Re: Just say no to JSP
> If separation of presentation (html) and logic (java) is your primary
> concern, that's an equally strong reason for getting rid of JSP and
> moving to a template language like Jakarta's Velocity. See
> http://jakarta.apache.org/jakarta/index.html.
>
> As I explained in the article, the same thing could be done in WAP by
> using MLS to read and parse HTML from files on the fly. This wasn't a
> priority in my shop where all the html coders (me) are fluent in
> java. If I get a moment I'll add documents on how to do this.
>
> At 11:10 AM +1000 05/27/2001, Patrick Brosnan wrote:
> >Hi there,
> >I have recently been working on a web portal development that employ's
J2EE
> >architectures and have not encountered the problems your framework sets
out
> >to solve. The idea in our application is to use as much HTML as possible
in
> >the JSPs and only resort to JSP escapes to control whether a logical
> >section of the page should be displayed or to add dynamic data to the
page.
> >We have made extensive use of custom tag libraries to achieve this and
have
> >developed data model and view model interfaces to screen the business
layer
> >from the view layer.
> >As I understand it your model seems to be binding the application to HTML
as
> >the display medium which makes reuse impossible should you want to switch
to
> >a GUI or WAP device.
> >
> >cheers
> >
> >Patrick
> >
> >Patrick Brosnan
> >Sydney, New South Wales
> >[EMAIL PROTECTED]
> >----- Original Message -----
> >From: "Brad Cox" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Sunday, 27 May 2001 3:17 AM
> >Subject: Just say no to JSP
> >
> >
> >> I've just completed a major revision of the WAP software and
> >> articles that were published in the last two month's Dr. Dobb's
> >> Journal.
> >>
> >> The software and articles are available at
> >> http://virtualschool.edu/wap. The demonstration application isn't
> >> working there yet (tomcat configuration still underway).
> >>
> >> Please check it out. I welcome all comments, particularly suggestions
> >> as to how to get this approach broadly adopted.
> >>
> >> Just say no to JSP
> >> Abstract
> >> Perl and JSP encourage the view that web pages are files, links are
> >> file names, and request and database fields are strings. But although
> >> html does represent everything as data, html is a restriction on
> >> browsers, not web applications.
> >>
> >> Java should be used as a fully object-oriented language, not as a
> >> deficient Perl. Pages should be page objects, links between pages
> >> should be messages between objects, and fields should be instances of
> >> application-specific fields that encapsulate the ability to validate
> >> user input.
> >>
> >> WAP was developed and tested with the Apache/Tomcat/JServ servlet
> >> engine but should work with others such as Resin. If the engine
> >> supports JSP it is not used. The software replaces the sole useful
> >> feature JSP provides with the MLS preprocessor described below. JSP
> >> was designed as an html extension language, which is a very bad idea.
> >> JSP should under no circumstances be used. If you really must view
> >> web applications as string/file processors, use Perl not Java. Perl
> >> was designed for just that.
> >>
> >> --
> >> ---
> >> For industrial age goods there were checks and credit cards.
> > > For everything else there is mybank.dom at
http://virtualschool.edu/mybank
> > > Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
> > >
> > >
>
>___________________________________________________________________________
> >> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> >body
> >> of the message "signoff SERVLET-INTEREST".
> >>
> >> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> >> Resources:
http://java.sun.com/products/servlet/external-resources.html
> >> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >>
> >
>
>___________________________________________________________________________
> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> >of the message "signoff SERVLET-INTEREST".
> >
> >Archives: http://archives.java.sun.com/archives/servlet-interest.html
> >Resources: http://java.sun.com/products/servlet/external-resources.html
> >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
> --
> ---
> For industrial age goods there were checks and credit cards.
> For everything else there is mybank.dom at http://virtualschool.edu/mybank
> Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
