|
»
« Return to Thread: [SUNDAY] Struts 2 and EL
Re: [SUNDAY] Struts 2 and EL
by Brian Pontarelli
::
Rate this Message:
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@...> 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@...
>>> >
>>> 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@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
- 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@...> 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@...
>>> >
>>> 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@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: [SUNDAY] Struts 2 and EL
| Free embeddable forum powered by Nabble | Forum Help |
