I have code that "records" a property invocation chain and bundles it up into an object that can be "replayed" on a root object again (using Commons Proxy's invocation recorder feature, not yet released). It has bindings for MVEL (which is the fastest currently), OGNL, Java reflection, etc. I don't think it's quite ready for "prime time" yet, but you're more than welcome to it if you want it.
I would suggest you look into a simple MVEL-based implementation of what you want. MVEL is very fast and basically does what you're looking for and it uses simple string expressions like Wicket does. On Thu, May 8, 2008 at 11:10 PM, Miguel Munoz <[EMAIL PROTECTED]> wrote: > > > Eelco Hillenius wrote: >> >> One thing I'm wondering though is whether your more efficient version >> still uses introspection? If that is the case, we would love to learn >> what you did to make it run more efficiently. And - if you use >> introspection - ... why use introspection when you need it to run very >> efficiently (just write it out directly will run much faster). >> >> Eelco >> >> > > I am still using introspection because the current implementation uses > property names specified in configuration files, although I may look into > bypassing this. Here's how I suspect I get better efficiency: I instantiate > distinct resolver objects for each property chain. When I instantiate one, I > extract the getter's and setter's Method instances in the constructor. This > means that when I set or retrieve the property, all I need to do is call > Method.invoke(...). Since I'm sorting, I'm using the resolver for many > different objects, so I don't have to retrieve the Method instance from the > cache each time. (I suspect that's where I get most of the gains. HashMaps > are generally pretty fast, but to improve sorting efficiency, I've found the > best thing to do is speed up the individual comparisons.) > > (Also, since properties can be chained, I actually save an array of Getters. > The longer the chain, the bigger the savings.) > > Earlier in this thread, Matej explained why this won't work for Wicket -- I > guess your requirements are different from mine. I assume that a direct call > to the property (e.g. item.getThing().getWidget().getVolume()) doesn't > require anything to get cast to something else. I don't think my system > would work if casting was needed, but I haven't tested that assumption. > > ----- > There are 10 kinds of people: Those who know binary and those who don't. > -- > View this message in context: > http://www.nabble.com/PropertyResolver-redesign-tp16495644p17140674.html > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
