tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Cox <b...@virtualschool.edu>
Subject Re: An alternative to JSP
Date Thu, 11 Jan 2001 19:57:21 GMT
At 11:12 AM -0800 01/11/2001, Craig R. McClanahan wrote:
>* I don't see any reasoning for why HTML-in-Java is better
>   than any of the alternatives -- just a presumptive conclusion.
>   The vast majority of the article is simply a description of your
>   recommended approach.

Good point. I'll expand on this argument in the article even though 
it is most relevant in the context of JSP *AND* MLS versus the 
template approaches I'm aware of. That's because both JSP and MLS use 
a general purpose language for executable inclusions, whereas the 
template systems I've examined closely (one at this point) do not 
provide general-purpose language capabilities.

>* Worse, this approach does other things:
>
>     * Embeds presentation and business logic in one class,
       which is not a particularly scalable approach

>     * Requires a Java developer to do your page development
>
>     * Makes it difficult to leverage page authoring tools

Perhaps I miscommunicated. The private methods that contain the 
{{html}} need not be private methods in the controller class, 
although that is the style I demonstrated in the paper and that I use 
in my own work.

Noting requires the view methods to contain hardcoded strings, other 
than the crude measurements in the Conclusion section that makes me 
doubt that the space issue is a primary concern. Each method could 
aim MLS at an html file at runtime (using the doStream() method that 
MLS provides for this purpose but which I didn't mention in the 
article) and let it do the executable inclusion at runtime. But good 
point; I'll make this explicit in the article.

This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my 
belief that html experts and their tools couldn't be trained to 
ignore the {{...}} wrappers around the html? I'd be interested in 
hearing more about this. After all, JSP has the same problem its <%= 
... %> executable inclusion syntax.

>
>* My personal preference for the presentation layer is JSP (and has
>   been since long before I adopted a "sun.com" email address :-), for
>   several reasons:
>
>     * Separation of concerns - Mixing business logic and presentation
>       logic in one file (no matter what the syntax) works OK for simple
>       applications, but is not a particularly flexible long term approach.
>       All of the alternatives you compare yourself to have learned (and
>       implemented) this lesson.  Is there perhaps a message here that
>       you are missing?

I never advocated this. Syntactic validation is the responsibility of 
each field, low-level semantic validation is the responsibility of 
the controller, and high-level semantic validation is the 
responsibility of the Bean, in some cases even in the DBMS (although 
MySQL doesn't support this).

>     * Custom tags - can be used to encapsulate sophisticated
>       functionality in a variety of ways, including smarter generation
>       of HTML to configuring application functionality).  See the
>       Struts Framework project <http://jakarta.apache.org/struts>
>       to get a feel for what's possible.  (And Struts/Turbine/Barracuda
>       each offers an alternative approach to the organization of the
>       business logic as well.)

I've looked at struts but not at the others. Struts sounds like a great
improvement to JSP and I'd probably have adopted it were it not for 
the base objection to the whole java-in-html approach.

>     * Development tools - Watch what tools like Macromedia Ultradev
>       do for page developers (*not* Java developers!!!) who want to
>       author pages that use custom tags for dynamic pages.  I do
>       not see a big future in hand coded HTML.

See above re reading html from files through MLS.

>     * Alternative implementations - If Tomcat doesn't generate "good
>       enough" or "fast enough" code for you (and it's pretty minimally
>       acceptable at the moment), you've got choices of other vendors,
>       with a reasonable shot at your pages being portable if you take

MLS relies only on Java and the servlet API. Should be portable to 
anywhere, right?

-- 
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

Mime
View raw message