struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
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  
property:

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"/]
   [@jc.select items=currencies name="amount.currencyCode"/]
[/@jc.form]

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"/]
[/@jc.form]

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.

-bp


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:
>
> 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
>


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


Mime
View raw message