struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: [SUNDAY] Struts 2 and EL
Date Mon, 06 Jul 2009 19:07:59 GMT
Yeah, same here. Everything broke down when it came to two use cases:

	- The difference between a user type conversion error (user puts in  
'a' in a text box that is mapped to an Integer field property) and a  
developer type conversion error (developer didn't specify the date  
format for a specific field)

	- Generics

I figured as long as I was in there, I might as well make my type  
converters handle most anything. The only thing they don't handle well  
right now is when you have two fields that map to a single immutable  

public class MyAction {
   // For select
   public List<String> currencies = ...;

   // From the form (requires a currency code to be valid)
   public Money amount;

[@jc.form action="/my-action"]
   [@jc.text name="amount"/]
   [ items=currencies name="amount.currencyCode"/]

This one is tricky because it requires that the properties both be  
passed to the type converter. Right now you can do this:

[@jc.form action="/my-action"]
   [@jc.text name="amount" _currencyCode="USD"/]

And the currencyCode attribute is passed to the type converter, but I  
haven't figured out a way to do the other case quite yet.

Anyways, thanks for the pointer to the accessor helper. I'll  
definitely add it and see if it shaves off some processing time.


On Jul 6, 2009, at 12:04 PM, Musachy Barroso wrote:

> 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:
> musachy
> On Mon, Jul 6, 2009 at 10:41 AM, Brian  
> Pontarelli<> 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< 
>>> >
>>> 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:

>>>>> ,
>>>>> 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:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -- 
> "Hey you! Would you help me to carry the stone?" Pink Floyd
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message