oh yeah, this would definitely go into another branch. I am almost
done with it, I am adding more tests.
musachy
On Fri, Apr 24, 2009 at 12:54 PM, Rene Gielen <gie...@it-neering.net> wrote:
> Great stuff!
>
> wouldn't that be a good topic for the XW/S 2.2 branches discussed lately?
>
> Musachy Barroso schrieb:
>> Not yet, the MVEL stuff is pretty much a draft at this moment. We
>> could roll this in 2 steps, first stop using OGNL for parameter
>> binding, and then, plugin MVEL. After #1 is achieve, #2 should be
>> easy. The good thing is that the new parameter binding implementation
>> can be turned on/off with a constant, so we can get people to test it
>> for a while with no risk. I will commit it sometime this week.
>>
>> musachy
>>
>> On Tue, Apr 21, 2009 at 5:56 PM, Mathias Bogaert <m.boga...@memenco.com>
>> wrote:
>>> Musachy,
>>>
>>> Great stuff! Is the new implementation using ScriptEngine (JSR 223) in
>>> some way? Both OGNL and MVEL have a ScriptEngineFactory
>>> implementation, and many other scripting languages do, maximal
>>> decoupling.
>>>
>>> Regards,
>>>
>>> Mathias
>>>
>>> On Sun, Apr 19, 2009 at 11:28 PM, Musachy Barroso <musa...@gmail.com> wrote:
>>>> Every attempt to replace OGNL by another EL library hits a big wall
>>>> because of the tight integration between xwork and OGNL. The biggest
>>>> problem comes from the "magical" instantiation of null objects in
>>>> expressions, and type conversion (applied together). This magic
>>>> instantiation is only used during parameter binding.
>>>>
>>>> That being said, I am toying with a new implementation of the
>>>> parameter binding process, which does not use OGNL and is very simple.
>>>> It doesn't support any fancy expressions, besides nested and indexed
>>>> properties. The null handling (instantiation) and type conversion work
>>>> the same (existing classes are used). The advantages of using this
>>>> implementation are:
>>>>
>>>> # decoupling. We don't depend on OGNL for parameter binding, so to
>>>> plugin in a new EL we just need to provide a new ValueStack (with its
>>>> helper classes) (then I can finally use my MVEL implementation..woot!)
>>>> # security. We don't need to worry about parameter names being
>>>> evaluated as evil expression ("System.exit(1)"="die die!")
>>>> # performance. Parameter binding will be faster (no big deal really)
>>>>
>>>> I would say the main reason to do something like this, is that it give
>>>> us the possibility of getting rid of OGNL eventually, which is not
>>>> possible now, and as far as I know, OGNL is not maintained anymore.
>>>>
>>>> thoughts?
>>>>
>>>> musachy
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
