You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Gianni <si...@apache.org> on 2006/07/27 19:47:05 UTC
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
Re: JXPath, beans and the count function
Posted by Simone Gianni <si...@apache.org>.
Hi Dmitri,
will open the bug, try to solve it and commit the patch if i manage to :)
Simone
Dmitri Plotnikov wrote:
>Simone,
>
>Feel free to try out the proposed change. If it works (and does not break anything else), let me know and I will be happy to incorporate it in the JXPath codebase.
>
>Unfortunately, I am currently very busy on several other projects and don't have time to investigate the issue myself.
>
>Thank you very much for your help.
>
>- Dmitri
>
>----- Original Message ----
>From: Simone Gianni <si...@apache.org>
>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>Sent: Friday, July 28, 2006 6:03:29 AM
>Subject: Re: JXPath, beans and the count function
>
>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" <si...@apache.org>
>>To: <co...@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
Re: JXPath, beans and the count function
Posted by Dmitri Plotnikov <dm...@apache.org>.
Simone,
Feel free to try out the proposed change. If it works (and does not break anything else), let me know and I will be happy to incorporate it in the JXPath codebase.
Unfortunately, I am currently very busy on several other projects and don't have time to investigate the issue myself.
Thank you very much for your help.
- Dmitri
----- Original Message ----
From: Simone Gianni <si...@apache.org>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Sent: Friday, July 28, 2006 6:03:29 AM
Subject: Re: JXPath, beans and the count function
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" <si...@apache.org>
> To: <co...@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
Re: JXPath, beans and the count function
Posted by Simone Gianni <si...@apache.org>.
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" <si...@apache.org>
> To: <co...@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
Re: JXPath, beans and the count function
Posted by Dmitri Plotnikov <dm...@apache.org>.
Simone,
Perhaps a custom extension function could be used instead of "count(list)"
to resolve the issue.
- Dmitri
----- Original Message -----
From: "Simone Gianni" <si...@apache.org>
To: <co...@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