tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SANTOS, DANIEL (SBCSI)" <ds7...@sbc.com>
Subject RE: I've officially decided that JSTL is one of the worst things to ever happen
Date Tue, 06 Jul 2004 17:40:39 GMT
> 	There are a lot of java classes that return nulls as 
> part of normal operation.  For instance - sets.  
> Set.get(someobj) returns null if object is not there.  And 
> when you do ${my.set.blah.wee} and "blah" wasn't found, and 
> you get some crazy EL error, you'll remember my words.

This gets back to design issues to me.  You should know if a bean can
return null if you know your design.  Were you to attempt the same thing
in java you would get NullPointerException.  I agree that the error
messages can sometimes not be so easily interprted, but I think it comes
back to design.  So as far as actually *dealing* with those conditions
the sky is the limit:

<c:if test="${my.set != null}">
	..blah blah
</c:if>

or

You have ${my.set == null ? 'no' : 'some'} blah.

or even 

You have ${my.set == null ? 'no blah' : (my.set.blah == null ? 'blah
with no wee' : 'a lot of wee')}.

Either way (java, EL) you are going to have to navigate a hierachical
tree.  The real question that I ask myself is "am I doing business logic
or processing in my view layer?" and if so, "does this belong in another
layer?".

Daniel

> -----Original Message-----
> From: Ivan Jouikov [mailto:ivj@comcast.net] 
> Sent: Monday, July 05, 2004 2:44 AM
> To: 'Tomcat Users List'; ariel@arielvalentin.com
> Subject: RE: I've officially decided that JSTL is one of the 
> worst things to ever happen 
> 
> 
> See below for my replies
> 
> > 
> > >	What should we use instead?  Welcome to the front page of JSP
> > manual:
> > >
> > >	<% if( yourmoma ) { %>
> > >		Do some things
> > >	<% } %>
> > >
> > >	To me, it seems EASIER than this:
> > >
> > >	<c:set var="yourmoma" value="<%=yourMomaFromCode%>"/>
> > >	<c:if test="${yourmoma}">
> > >		Do some things
> > >	</c:if>
> > >	What happened to the good old idea of using JAVA, with all its
> > beautiful
> > >features, in the JSPs themselves?
> > >	Understandable output?  Do you really think you can find one
> > designer who
> > >would understand a simple calendar written in tags?  Hell 
> no.  And for
> > me,
> > >as a programmer, understanding good old java code inside 
> <% %> is MUCH
> > MUCH
> > >easier than understanding all the tag BS. Besides, old 
> java tags <% %> do
> > >very good job of presenting "understandable layout".  
> <%=%> and ${} are
> > >both equally to understand to me.
> > 
> > A key phrases in that example is "To me, it seems EASIER... 
> And for me, as
> > a
> > programmer... both equally to understand to me"
> > But that is you, a programmer with experience using various 
> programming
> > languages.
> > Why not use scriplets? Because of the development worlds 
> experiences with
> > ASP and CF where pages were riddled with code and vew 
> developers (not
> > designers) hard a hard time maitaining these view components.
> > View developers in large teams have their respective 
> discipline and it
> > becomes more difficult for them to maintain thier tier. 
> JSTL allows them
> > to
> > use familar syntax and structures from SGML/HTML and all those other
> > markup
> > languages, hence making it easier for them to "display" data, not
> > processing
> > it. Or would a company rather employ a perfectly good server side
> > developer
> > writing view code? If they have no usability skills it will 
> be a waist of
> > the company resources.
> 
> 	The key phrase is "display data, not processing it", 
> which is what I agree with.  However, that's not what JSTL 
> agrees with.  Tags like c:if and c:foreach shift XML from 
> data to logic, which is NOT what XML is for.  Didn't I say 
> that before?
> 
> > 
> > >But you're missing the point, again:  the (major) reason 
> JavaScript is
> > NOT
> > >server-side, is because of its sloppy syntax which is like 
> a warm oven
> > for
> > >bacteria - bugs just GROW in it.  EL is making the same 
> mistake over
> > again.
> > 
> > Valid point for JavaScript, but again treat JSTL-EL as a view helper
> > component not as a pure processing solution. Also did not 
> mean to mention
> > EJB it had no place in this arguement.
> > 
> > >	That's one of the things that EL might be actually useful for:
> > printing
> > >stuff out and escaping XML.
> > 
> > Exactly...
> 
> 	But again, you're forgetting that taglibs actually 
> FORCES you not to use <% %> code inside tags (when you make 
> tag files).  And tags like c:if and c:foreach have no place 
> in this world, I think we have a consensus on this.
> 
> > 
> > >But still, what if TModel might return a null value?  Then 
> you're in for
> > a
> > >nice 2 hour debugging ride with your EL syntax, or a 5 
> second adding if
> > >statement ride, if you used Java.
> > 
> > The null values should be handled in the Model or in a 
> heavy Controller...
> > if those values are missing or a failure occurs send them to the
> > appropriate
> > view.
> 
> 	There are a lot of java classes that return nulls as 
> part of normal operation.  For instance - sets.  
> Set.get(someobj) returns null if object is not there.  And 
> when you do ${my.set.blah.wee} and "blah" wasn't found, and 
> you get some crazy EL error, you'll remember my words.
> 
> > 
> > >	<% if( yourmoma ) { %>
> > Lets leave "yourmoma" out of this... lol
> > 
> > Cheers!
> > Mr. Ariel S. Valentin
> > mailto:ariel@arielvalentin.com
> > 
> > _________________________________________________________________
> > MSN 9 Dial-up Internet Access fights spam and pop-ups v now 
> 3 months FREE!
> > http://join.msn.click-url.com/go/onm00200361ave/direct/01/
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > 
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.701 / Virus Database: 458 - Release Date: 07.06.2004
> > 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.701 / Virus Database: 458 - Release Date: 07.06.2004
>  
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message