struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Musachy Barroso <musa...@gmail.com>
Subject Re: [SUNDAY] Struts 2 and EL
Date Mon, 06 Jul 2009 18:04:30 GMT
yes, type conversion has been a pain for me, and the reason why I
couldn't just use MVEL. Implementing value look ups is easy with any
of the ELs, setting values is a different matter, because other ELs
don't have an API as flexible as OGNL.

If you are not using bytecode for getting/seeting values, you can use
asm easily:

http://svn.opensymphony.com/svn/xwork/branches/parameter-binder/core/src/main/java/com/opensymphony/xwork2/parameters/bytecode/AccessorBytecodeUtil.java

musachy

On Mon, Jul 6, 2009 at 10:41 AM, Brian Pontarelli<brian@pontarelli.com> wrote:
> I sorta figured it would be pretty slow. You might also run into some issues
> with the APIs depending on how you want to handle type conversion stuff.
>
> The JCatapult EL is mostly decoupled from the rest of the framework except
> that I use the JCatapult ObjectFactory to create instances of the type
> converters. However, that would be simple to replace. Eventually I'd like to
> figure out where my slow-down is compared to MVEL and see if I can get it to
> perform the same. I think my caching needs a bit of love and also it might
> be helpful to compile the statements into Java classes at some point.
>
> -bp
>
>
> On Jul 6, 2009, at 11:28 AM, Musachy Barroso wrote:
>
>> yes, I was testing different engines yesterday, and groovy is around
>> 30 times slower than OGNL, and Rhino around 17 times. JEXL seemed to
>> be the faster one, around 7x slower.
>>
>> That being said, it doesn't change anything because what I am
>> suggesting is decoupling the actual implementation, OGNL could still
>> be used thru jsr 223, as an option and default implementation.
>>
>> we would need the value stack just to lookup values, for setting
>> values we could use the new binder implementation, to which I just
>> added bytecode generation for setters/getters.
>>
>> is your EL decoupled fro jcatapult?
>>
>> musachy
>>
>> On Mon, Jul 6, 2009 at 10:13 AM, Brian Pontarelli<brian@pontarelli.com>
>> wrote:
>>>
>>> I would say the reason you don't want to dive into 233 would be primarily
>>> because of performance. You'd either need to have a compiled statement
>>> cache
>>> or pre-compile. Most of the scripting frameworks that comply with 233 are
>>> full blow languages (Groovy, JavaScript, etc) and have pretty slow
>>> parsers
>>> compared to EL parsers out there. You could give them a try and see, but
>>> I
>>> would guess you would see a large drop in performance using them. I
>>> personally think MVEL is one of the better ways to go once they finish
>>> some
>>> of the new features they have in mind for the next version (i.e.
>>> annotations
>>> and such).
>>>
>>> Or just write your own. I wrote one for JCatapult and it took about a
>>> day.
>>> It isn't as fast as MVEL, but it works fine for what I need and it
>>> doesn't
>>> mean it can't be improved on. The primary reason I did that exercise was
>>> to
>>> fully support 1.5 and generics as well as provide a better type
>>> conversion
>>> API with annotation support. The way I wrote it you can specify
>>> additional
>>> attributes using the taglibs or via an annotation that tell the API how
>>> to
>>> convert Strings to things like Money, dates, and JODA classes.
>>>
>>> -bp
>>>
>>>
>>> On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote:
>>>
>>>> After fighting OGNL and MVEL for a while I've got to the conclusion
>>>> that they aren't the best horses to bet my money on, some of the
>>>> reasons are not even technical so I won't go into them. So I have been
>>>> playing with a new idea, why should we couple struts to an EL, when we
>>>> can use JSR 223 (Scripting for the Java platform, some docs here:
>>>>
>>>> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/),
>>>> and just make Struts EL agnostic? I know security would be a concern,
>>>> but at least we got standard ways to limit what these scripts can do
>>>> or not. it would be very cool if I could just set
>>>>
>>>> <constant name="struts.scriptEngine" value="groovy" />
>>>>
>>>> and then just use all of groovy's cool stuff in the tags. So if people
>>>> can just pick their favorite engine, instead of being stuck with our
>>>> supported implementation. What do you think?
>>>>
>>>> musachy
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>



-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message