I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic JavaBean handling. This topic has come up so many times and I
still feel it is a major barrier to entry for Struts.
-bp
On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
Well yes, that's by default, but with the new EL api you can plugin a
new EL resolver like:
JspApplicationContext jspApplicationContext =
JspFactory.getDefaultFactory().getJspApplicationContext
(servletContext);
jspApplicationContext.addELResolver(new CompoundRootELResolver());
and the container will delegate to that resolver. BTW the JUEL plugin
is in better shape than I thought, Tom are you out there?
musachy
On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
<antonio.petre...@gmail.com> wrote:
2009/11/3 Antonio Petrelli <antonio.petre...@gmail.com>:
2009/11/3 Musachy Barroso <musa...@gmail.com>:
We also have FreeMarker , Velocity and we have a lot of expression
evaluations from Struts code itself.
And in this case you're right, EL at Struts-side is obligatory.
But exactly, is a bad idea to use the capability of the container to
resolve EL expressions into values?
This is just an idea.
Another thing, sorry for the noise :-D
If EL Expressions are interpreted Struts-side, this means that in JSP
tags the attributes that represent expressions should not be "rtexpr"
activated.
This means that they might not have an expression, so you cannot
write:
<struts:tag expression="${myexpr}" />
because it is not interpreted as a string, but as an expression
illegally placed.
So you should do funny things, like string composition, to let it
work.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
