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-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org