Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A7081A2.3D153C15@metrixpoint.com>
Date: Thu, 25 Jan 2001 14:42:26 -0500
From: Paul Speed <Paul.Speed@metrixpoint.com>
Reply-To: pspeed@progeeks.com
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: An alternative to JSP
References: <20010125190323.10103.qmail@web1904.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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.
> mmartinez@g1440.com
> 
> --- Brad Cox <bcox@virtualschool.edu> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org