if property is just one property (not a dot.dot.dot thing)
then i cant believe that the property resolver is a big factor because it
very fast resolves to the right cached invoker.
It is not easy to open this up because of the dot.dot.dot thing because for
that it is a recursive call on itself that
does the object resolving on its way,.
johan
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.
>
>
