You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2009/07/06 00:13:59 UTC
[SUNDAY] Struts 2 and EL
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
Re: [SUNDAY] Struts 2 and EL
Posted by Brian Pontarelli <br...@pontarelli.com>.
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<br...@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
Re: [SUNDAY] Struts 2 and EL
Posted by Musachy Barroso <mu...@gmail.com>.
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<br...@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<br...@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
Re: [SUNDAY] Struts 2 and EL
Posted by Brian Pontarelli <br...@pontarelli.com>.
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<br...@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
Re: [SUNDAY] Struts 2 and EL
Posted by Musachy Barroso <mu...@gmail.com>.
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<br...@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
Re: [SUNDAY] Struts 2 and EL
Posted by Brian Pontarelli <br...@pontarelli.com>.
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