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]
