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]
