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