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

Reply via email to