Ivan,
Points well taken, you have very strong position, I enjoy this dialog. Sorry if I misinterpreted them in your earlier email. I think I see where we both disagree and it's mainly what JSTL and EL are good for.
You don't feel this argument holds? When you have a poor little tomcat running 100 different web applications with 10,000 clicks/day on each, it DOES become an issue. Your choice: get a new server, OR replace all the ${} with <%=%>. I've been faced with similar situation many times, and trust me, it drives you nuts.
We will probably never agree on this one... So I think we should just drop it... lol
EL syntax sort of "encourages" designers to be free to throw expressions and tags around, which could result in SERIOUS logical errors when you pull some important ${} out of the loop, and as a result, the dev will have to spend two day figuring out why his code isn’t working (this is where CVS is a charm).
Debugging is a risk that comes with the territory and will always be tough with respect to webapps. I see your point though it is easier just to see the exception in plain english than buried in the stack.
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.
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 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.
<% 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 � 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]
