chipping in really late, sorry.
There might be a way to at least alleviate the problem without any code
change...
You're right the filter spec does not say anything about non existent
properties, and the current behaviour is 'consistent' with xpath in
that X-Path will return an 'empty list' when a
I thought the performance issue was solved by caching property accessors...
and that was done way back. I did not notice that the patch would change
that but I will have to look it over again.
The issue i am more concerned with before Jody took this thread in a
different direction was the compatib
On 21/09/10 12:05, Jody Garnett wrote:
I understand the problem with using null to represent two cases; can
you check the filter and xpath specifications to see how they handle
this problem? Do they produce an error; or return an empty result? The
answer may inform what we do here; perhaps they
I understand the problem with using null to represent two cases; can you check
the filter and xpath specifications to see how they handle this problem? Do
they produce an error; or return an empty result? The answer may inform what we
do here; perhaps they have thought of a good way to be clear?
Please keep discussion on the list (you will need to repeat yourself)
On 21/09/2010, at 12:51 PM, Niels wrote:
>
> The problem with separating 'canExecute' from 'execute' is that it wouldn't
> solve the performance issue. To test whether a x-path can be evaluated, the
> only way is often to ac
The problem with separating 'canExecute' from 'execute' is that it
wouldn't solve the performance issue. To test whether a x-path can be
evaluated, the only way is often to actually try to evaluate it, which
would mean you would be doing the same thing twice if they are in
separate methods. The
What did you think of the idea of performing two tests (in order to maintain
performance).
So my performance question may be handled with an extra method:
1. short list property accessors that think they can handle the xpath
expresison using canHandle (this should be a test just to see if the x
I think it would be a good idea to make it optional and still throw a
null value when this particular option is selected "off", like I first
suggested. Question is only, at which point in time and in which manner
this option is selected. Is it something that should be left completely
to the use
Thanks for taking the discussion to the email list Justin; I did warn the patch
author that discussion needed to be public (and would have to wait until after
foss4g).
The one thing I like about the suggestion is not hard coding the jxpath case as
a fall back position.
The concerns I had were:
