> 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:[EMAIL PROTECTED]
> Sent: Monday, July 05, 2004 2:44 AM
> To: 'Tomcat Users List'; [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> >
> > _________________________________________________________________
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---
> > 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
