like i said in my original email: PropertyResolver is optimized for our usecases, it delivers awesome performance - but only when used for those usecases.
you are never meant to use propertyresolver yourself. i will add that to the javadoc. i still dont understand how you use propertyresolver for "sorting". is it that the dynamic string here represents a method that returns the value you sort on? to get 800ms, how big is your dataset that you are sorting, and how are you sorting it? -igor On Mon, Apr 7, 2008 at 2:25 PM, Miguel Munoz <[EMAIL PROTECTED]> wrote: > > > igor.vaynberg wrote: > > > > PropertyResolver is not meant for your direct consumption. it is > > something we use for our own purposes inside wicket. > > > > This is a bit surprising, since the Javadocs provide a very friendly > explanation of how to use the class. If it's not intended for us, maybe the > Javadocs should say so. > > > > igor.vaynberg wrote: > > > > i am not sure we are willing to change how it works as it gives us no > > benefit, the class as is right now is optimized for our specific > > usecases. > > > > > > If you like, I will present more detailed performance data when I have it. > While I'm happy to switch to a different library, I would still like to know > that Wicket performs as fast as possible. > > > > igor.vaynberg wrote: > > > > you can use a library like mvel/ognl to perform dynamic evaluations > > that are for your needs. i hear mvel is pretty good. > > > > > > Are you saying here that PropertyResolver shouldn't be used for > performance-critical tasks like sorting? If so, you might want to say so, > again, in the javadocs. (You should also suggest mvel.) That said, I'm happy > to switch to mvel if that will give me the performance I want. > > > > > ----- > 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-tp16495644p16540848.html > > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
