String/StringBuffer (was Re: An alternative to JSP)

[Arieh Markel <Ar...@central.sun.com>]

> Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
> list-help: <ma...@jakarta.apache.org>
> list-unsubscribe: <ma...@jakarta.apache.org>
> list-post: <ma...@jakarta.apache.org>
> Delivered-To: mailing list tomcat-dev@jakarta.apache.org
> From: Paul Speed <Pa...@metrixpoint.com>
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: An alternative to JSP
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> 
> 
> 
> 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

Paul,

Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:

new StringBuffer ("My").append("dog").append("has").append("fleas").toString();

It is also possible to write a statement like:

	"My" + "dog" + '.'
	
The ability to concatenate a char points at an underlying StringBuffer
implementation, which supports append(String) and append(char) methods.


Last paragraph in the java.lang.String javadoc says:

The Java language provides special support for the string concatentation operator
( + ), and for conversion of other objects to strings. String concatenation is
implemented through the StringBuffer class and its append method. String
conversions are implemented through the method toString, defined by Object and
inherited by all classes in Java. For additional information on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java Language Specification. 



Arieh

> 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 <bc...@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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org

--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)