struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Dollin <Ed...@BLUE-MOOSE.NET>
Subject RE: [struts-el] What's the benefits ?
Date Thu, 06 Mar 2003 11:49:29 GMT
The ambiguity of the syntax is disconcerting and is probably why I limit
it's use.  Whenever I use it, it seems like a guess since the rules are so
loose.  Of course I always guess incorrectly which adds to the frustration.
I for one prefer the more complex syntax and the NPE's, since then you have
a clue as to what is going on.

Edgar

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
> Sent: Wednesday, March 05, 2003 8:52 PM
> To: 'Struts Users Mailing List'
> Subject: RE: [struts-el] What's the benefits ?
> 
> 
> 
> 
> > From: alexj [mailto:alexj@freesurf.ch]
> >
> > I didn't find the benefits of the use of jstl extention.
> >
> > Who can explain me the benefits ?
> 
> > From: p2 - apache <apachep2@hotmail.com>
> >
> > Some body don't want to see <% .... %>? Just a guess.
> 
> There's lots of advantages to the expression language that 
> Struts-EL uses (copied from JSTL 1.0, and to be embedded 
> everywhere in a JSP page in JSP 2.0).  My favorite feature is 
> independence from the underlying implementation of the 
> properties.  Consider the following expression:
> 
>   ${customer.mailAddress.city}
> 
> This works for all of the following scenarios (as well as 
> some others):
> 
> * "customer" is a bean with a getMailAddress() getter, which in term
>   returns a bean with a getCity() getter.
> 
> * "customer" is a bean where getMailAddress() returns a Map that has
>   (among others) an entry with a key of "city".
> 
> * "customer" is a Map that has a key "mailAddress" whose value is a
>   bean with a getCity() method.
> 
> * "customer" is a Map with a key of "mailAddress" that returns a Map
>   that has a key of "city" ...
> 
> You get the idea?  The business tier developer has a fair 
> amount of freedom in how they implement the beans 
> representing the data required by the view tier -- or even 
> skips implementing them if Maps do the trick. And changing 
> your mind among these choices does not invalidate the syntax 
> of the expression that is embedded in your page.
> 
> The other thing I like about EL expressions is that the 
> syntax is very close to what page authors familiar with 
> JavaScript already understand, so it's natural for them to be 
> able to script with it, without having to know any java at 
> all.  Consider a personnel management app that wants to 
> restrict the display of salary information to managers.  In a 
> JSP 1.2 environment (with JSTL), you could write:
> 
>   <c:if test="${user.role = 'Manager'}">
>     <c:out value="${employee.salary}"/>
>   </c:if>
> 
> and have a fair chance that the page author can understand it 
> -- while the corresponding scriptlet version is pretty opaque 
> to a non-programmer:
> 
>   <%
>      if (user.getRole().equals("Manager")) {
>        out.println(employee.getSalary());
>      }
>   %>
> 
> to say nothing of the fact that the Java code requires you to 
> expose "user" and "employee" as instance variables in the 
> page class, while the tagged version doesn't.  (And, by the 
> way, you'd better be prepared for NullPointerException errors 
> in the scriptlet, while the expression language deals with 
> them for you.)
> 
> By the way, in a JSP 2.0 environment, this example will get 
> even simpler:
> 
>   <c:if test="${user.role = 'Manager'}">
>     ${employee.salary}
>   </c:if>
> 
> because you will be able to use EL expressions anywhere 
> (including template text), not just in tags that understand it.
> 
> Craig McClanahan
> 
> 
> 

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


Mime
View raw message