struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Tedone" <>
Subject Re: JSTL and Struts-el
Date Sun, 10 Aug 2003 21:36:01 GMT
That's sounds great Craig, thanks. I can guess that you will define what
customer is and where to get it somewhere, presumibly a configuration file.
Now, to know all this stuff, where shall I look at? Is there any
documentation available, does it come with the Struts distribution? (I just
realized that I was still in 1.1-rc1 :))

----- Original Message ----- 
From: "Craig R. McClanahan" <>
To: "Struts Users Mailing List" <>
Sent: Sunday, August 10, 2003 10:20 PM
Subject: Re: JSTL and Struts-el

> On Sun, 10 Aug 2003, Marco Tedone wrote:
> >
> > Where's the java code here? How could it be done with less effort by
> > of JSTL and Struts-el?
> One aspect that hasn't been touched on in this thread (completely aside
> from readability, which tends to be a subjective judgement call) is the
> fact that the page author does not need to know as much about the data
> structures being provided by the application's business logic.  (A subset
> of the same benefit accrues when you use Struts tags, but the expression
> language syntax is not quite as powerful.)
> Consider the following scriptlet:
>   <%= customer.getName() %>
> It's pretty clear that "customer" must be some bean (not shown here is the
> ugliness of getting "customer" defined as a local variable so that this
> can actually work).  But the key takeaway is that it's clearly a bean
> property being displayed.  If the application developer changes his or her
> mind about the data representation (say, making "customer" a Map instead
> of a bean), the page author is forced to accomodate that change.
> Now consider a corresponding EL expression (which in a JSP 2.0 container
> can be used directly in your template text, since EL expressions are
> allowed everywhere):
>   ${}
> Note that this works for a JavaBean, as before.  But it also works if
> "customer" is really a Map -- in that case it turns into the equivalent
> of:
>   <%= customer.get("name") %>
> instead.
> Separation of concerns about data representation is very powerful.
> Note that if you're in a pre-JSP-2.0 container, or you want to use Struts
> tags instead, you have to go to a little more work:
>   <c:out var="${}"/>
>   <bean:write name="customer" property="name"/>
> but you gain the same benefit of insulation from whether "customer" is a
> bean or a Map.
> In this use case, the Struts and EL versions have essentially equivalent
> power.  EL expressions show their improved value, though, when:
> * You need more complicated expressions than Struts tags
>   support:  "${customer.address[customer.preferredAddress].street[2]}"
> * Your page compiler generates optimized code for the EL expression
>   (Resin and others do this already for JSTL tags), whereas a Struts
>   tag is always going to generate the standard custom tag stuff.  In
>   such a container, the performance of the EL variant will be better
>   even if the functionality is equivalent.
> >
> > I would be really interested in it.
> >
> Appearance to the page author is only one aspect of deciding which
> approach to take.
> > Marco
> Craig McClanahan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message