PropertyResolver is not meant for your direct consumption. it is
something we use for our own purposes inside wicket.
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.
you can use a library like mvel/ognl to perform dynamic evaluations
that are for your needs. i hear mvel is pretty good.
of course, this is just my opinion, maybe other core devs have others.
-igor
On Fri, Apr 4, 2008 at 12:03 PM, Miguel Munoz
<[EMAIL PROTECTED]> wrote:
>
> Comrades,
>
> After looking at the code for PropertyResolver, I find myself wondering if
> there's a more efficent way to design it. It seems to me I could have more
> efficient code if I could instantiate a resolver object which extracts the
> getter and setter Methods on construction. Here's the situation I'm looking
> at:
>
> When displaying my data in a Repeating view, my sort code calls a Comparator
> which looks something like this:
>
> public int compare(Object o1, Object o2) {
> String property = ... ;
> Object val1 = PropertyResolver.getValue( property, o1 );
> Object val2 = PropertyResolver.getValue( property, o2 );
>
> return valueComparator.compare( val1, val2 );
> }
>
> For a given row, the sorter will call the getValue() method repeatedly, so I
> want it to run quickly, but I can already see a problem:
>
> The getValue() method needs to first extract a method from the property
> name, then call that method to retrieve a value. That second step will
> produce a different result for each row, but the first step, which extracts
> the Method object, doesn't change from row to row, so it would be much more
> efficent to do that part ahead of time. It seems to me that it shouldn't be
> hard to write a new property resolver that I can instantiate, so the
> extraction of the Method can be done ahead of time. In other words, I should
> be able to write something like this:
>
> PropertyResolver2 resolver = new PropertyResolver2("propertyName",
> MyBean.class);
>
> At this point, the resolver object will have a Method instance, or, for a
> series of properties, an array of Methods. Then my comparator would look
> like this:
>
> public int compare(Object o1, Object o2) { // o1 & o2 must be of class
> MyBean.
> String property = ... ;
> Object val1 = resolver.getValue( o1 );
> Object val2 = resolver.getValue( o2 );
>
> return valueComparator.compare( val1, val2 );
> }
>
> The PropertyResolver2 constructor would already have the Method extracted,
> so the comparator would execute much faster.
>
> So here's my question: Is there any reason why the Wicket code doesn't do it
> this way?
>
> --
> View this message in context:
> http://www.nabble.com/PropertyResolver-redesign-tp16495644p16495644.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
