Without getting into the larger issue, one problem
that jumped out at me from your article is (at least
in your examples) the MLS precompile looks at the
expression inside the digraphs and replaces line
terminations in the *.j source with linefeed
characters ('\n'). That presumes the line termination
character of choice for the output is a linefeed
character. It may be a '\n' is fine for most cases,
but the truth is that it depends on the platform upon
which the output is to be used. In generall, it is
always best to use the line.separator property instead
or use a PrintWriter's println() method to insert the
correct line termination.
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.
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.
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Brad Cox <[EMAIL PROTECTED]> wrote:
> At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
> >I agree with most of your discussion of the
> disadvantages of JSP/ASP/etc,
> >but I believe your solution does not address a
> fundamental problem, which
> >is the complete separation of presentation
> resources from presentation logic.
>
> That is correct. My goal at this point is to get
> free of JSP so the
> goal was only to duplicate what JSP does in a way I
> can live with.
>
> >Having the HTML embedded in a java class may be
> suitable for small
> >applications
> >built by engineers but does not address the vast
> majority of applications
> >where designers work on HTML using many different
> HTML editing tools
> >while developers work on the application logic in
> Java using various IDEs and
> >editors.
>
> 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 I-do-it-all work.
>
> Also there is nothing that requires these 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 it 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.
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
