Mel Martinez wrote:
>
> 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 thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
