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
