The parameters binder branch is now merged into xwork trunk (manual
merge thanks to svn being a PITA)(for those unaware, this contains
some experimental code to set parameters in the actions without using
OGNL directly, it is faster, and more secure) . Now we can start
playing with other ELs seriously.
musachy
On Tue, Nov 3, 2009 at 10:20 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
> It's been a while, but that is really more of an current action stack (I
> call it the ActionInvocation stack). I recall that I was able to get most of
> the functionality I needed into JCatapult while still using the FTL/JSP
> expression languages.
>
> -bp
>
>
> On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote:
>
>> That would be ok except for one thing: the value stack. To support the
>> value stack in those view technologies is the problem. I have tried so
>> many things, and failed in all of them that it is lame. I will finally
>> merge my parameters-binder branch in xwork into trunk, and see if I
>> can get some folks to look at it. With the parameters problem solved,
>> the rest is not *that* hard.
>>
>> On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli <br...@pontarelli.com>
>> wrote:
>>>
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
