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
