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 :))
Marco
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
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
means
> > 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):
>
> ${customer.name}
>
> 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="${customer.name}"/>
>
> <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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
