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; [EMAIL PROTECTED]
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
