commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: JXPath, beans and the count function
Date Fri, 28 Jul 2006 10:03:29 GMT
Hi Dmitri,
thanks for your answer.

We currently made a work around to check ourselves if the path is
actually pointing to a collection (invoking the getValue() ) before
invoking the evaluation of a count(path).

Amyway, we think this could be a bug in JXPath. In fact the count
function calls the expression.compute(context) which states in its
javadoc "Evaluates the expression. If the result is a node set, returns
the first element of the node set." .. so IIUC it will never actually
return a java.util.Collection.

Wouldn't it be better to try to retrieve the simple value before, check
if it is a Collection, and if it's not proceed with the rest of the
actual code? It's not a suggestion, is a real question :) I've been
using JXPath for long time inside cocoon, but never examined the code in
depth.

Regards,

Simone

Dmitri Plotnikov wrote:

> Simone,
>
> Perhaps a custom extension function could be used instead of
> "count(list)" to resolve the issue.
>
> - Dmitri
>
> ----- Original Message ----- From: "Simone Gianni" <simoneg@apache.org>
> To: <commons-dev@jakarta.apache.org>
> Sent: Thursday, July 27, 2006 1:47 PM
> Subject: JXPath, beans and the count function
>
>
>> Hi there,
>> we are developing paginated repeater for Cocoon. The cocoon repeaters
>> uses JXPath in their binding so that they can work on beans and XML
>> documents.
>>
>> The goal for us is to display a very long list of elements from a
>> collection not fetching the entire content of the collection. This is
>> expecially useful when the collection is backed by a persistence layer
>> like hibernate or similar, and you have a very big rowset (we are
>> testing on an application with a list with 11000 elements in it).
>>
>> Now, one key element for every pagination system is to retrieve the
>> total amount of items in the list. We tried to accomplish this with a
>> count(pathToList). Actually we have a bean having a getList method
>> returning a java.util.List instance, so we try count(list/*) ,
>> count(list), count(list/something), and we would expect JXPath to call
>> getList().size(). This is quite critical, because the list
>> implementation knows how to retrieve the number of rows without actually
>> fetching all the rows from the underlying dataset.
>>
>> Unfortunately, what hapens is different. The
>> CoreFunction.functionCount() method does not recognize it as a
>> Collection, but as a EvalContext instead, and iterates on all the lines
>> to count the items (actually is the EvalContext.hasNext() method that
>> iterates on the entire collection).
>>
>> What's strange is that there is a check in CoreFunction.functionCount()
>> to see if a Collection is in place and eventually call the
>> Collection.size() method, but this seems like it's never happening.
>>
>> Could you please help us? Is it a JXPath bug or are we completely
>> missing something?
>>
>> TIA, regards,
>> Simone Gianni,
>> Matthias Epheser
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
-- 
Simone Gianni

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message