Ah yes, I forgot about that method. Great, so it has the capability to handle
offset and limit.
But it still doesn't solve the problem I have, which is simply that it's very
cumbersome to use this in conjunction with findEntityListIterator. In fact, it
makes things worse.
1) That this method considers 1 to be the index of the first element of the
list is guaranteed to throw developers off.
2) My idea was to create convenience methods in GenericDelegator which
basically wraps a call to findListIteratorByCondition and then does the
getPartialList for you so you don't have to worry about issue #1 and helps
satisfy the Don't Repeat Yourself (DRY) principle.
List whatINeed = delegator.findByAnd(entityName, fields, start, end);
List alsoWhatINeed = delegator.findByCondition(entityName, fields, conditions,
orderBy, start, end);
Start and end would use the traditional notion of 0 being the start index.
Does my idea make sense now? It's for convenience and to hide some of the
complexity.
- Leon
David E. Jones wrote:
Could you explain how that would be different and better than using the
EntityListIterator.getPartialList method?
-David
On Jan 31, 2007, at 11:21 AM, Leon Torres wrote:
Hi David,
Sorry, maybe I should have expressed this in the form of two questions.
Is there a way to do a query with OFFSET and LIMIT using EntityCondition?
If not, then is there a way to do these offset and limit operations
with findEntityListIteratorByCondition?
- Leon
David E. Jones wrote:
What's wrong with the stuff that's been there for years on the
EntityListIterator?
-David
On Jan 30, 2007, at 4:52 PM, Leon Torres wrote:
Hi folks,
I think we really need to be able to specify the size of the list we
want and the index to start at for the GenericDelegator.findByAnd
and findByCondition methods.
The idea is to support pagination in the form widgets and similar
systems for lists of data that cannot be supported by
<view-entity>. For example, if the inventory QOH and ATP are
required for a form-widget list, we need to call the
getInventoryAvailableByFacility service and add the results to each
list row. Another example would be a union of various entities
together, some of which need heuristics to select the data.
It should be relatively simple: Create a method that wraps a call to
findListIteratorByCondition, then grab the desired range of
results. It should also return the size of the table.
Then, as an example, we can call these methods with our viewSize and
viewIndex parameters, build our complex list of data based on the
results, and use the form-widget's override-list-size to make
pagination work with it.
Thoughts?
- Leon
