At 11:03 AM -0800 01/25/2001, Mel Martinez wrote:
>That presumes the line termination
>character of choice for the output is a linefeed
>character.
Good point. Will fix when I get a moment.
>Another issue is that the example creates catenated
>String literals. I would hope that the actual code
>produced would use appropriately initialized
>StringBuffers or performance could be a problem.
I've been assuming that concatenation of constants is collapsed
at compile time. I'm sure this is true for SOME compilers but
less sure this is true across the board. Could you elaborate
on this point?
Concatenation of non-constants is, of course, a different
matter. I do use StringBuffers for these.
>Just some thoughts on the implementation. On the
>larger issue of this thread, I don't really see the
>benefit of something like MLS over JSP, which
>potentially allows you to completely remove all Java
>code from the html (by using jsp tags and taglibs),
>but take that as an imho.
I don't view "eliminating java" as automatically beneficial.
My goal is more to "eliminate html"; e.g. hiding it from view within
classes in a format (MLS) that can be manipulated even by
nonprogrammers, without "..."+ noise in the way.
In other words, I view html as a problem to be hidden away
and forgotten whereas JSP uses it as the foundation of the
very programming language which keeps it right in my face.
Some specific gripes with html: page references (<a href>, <form>)
are hard-coded into each page. There is no way to check referential
integrity except by testing each and every link.
More seriously, every link bypasses all url session-encoding
logic, so the user's session will be lost if they ever browse
to a hard-coded html page. This has really poisonous user interface
implications obviously.
Finally, request.getParameter() returns Strings and/or nulls
instead of providing a consistent validation architecture as
described in the paper. Of course such an
architecture could be easily added to JSP as user-level code
(I offered to do as much for Tomcat but never heard back).
The complaint is that JSP leaves this up to each user by
implying that fields should be managed as Strings instead
of taking active steps to help users realize that
Strings (and nulls) should NEVER appear in higher-levels of
an application, which is the very level that JSP addresses.
For those who missed it, the article we're discussing is
at http://virtualschool.edu/wap
--
---
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]
