Hi,
first of all, are you sure property resolver is your bottleneck? I
really have hard time believing that.
PropertyResolver already caches the method instances based on target
object class.
Also your approach wouldn't work for things like "property1.property2"
where property 2 container type depends on result of property 1
evaluation.
-Matej
On Fri, Apr 4, 2008 at 9: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.
>
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
