Back contributions from integrations
(MGNLDAM-549)
|
|
| Status: | Closed |
| Project: | Magnolia DAM Module |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1 |
| Type: | Sub-task | Priority: | Neutral |
| Reporter: | Robert Šiška | Assignee: | Robert Šiška |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | api | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
The AssetQuery interface supports specifying the max results but doesn't support the offset, which makes it unusable for paging. Add AssetQuery#getOffset() and AssetQuery.Builder#withOffset(long offset) methods. Rationale: it is planned to create jcr-agnostic AssetContainer that serves as bridge between AssetProviders and UI. |
| Comments |
| Comment by Robert Šiška [ 05/Mar/15 ] |
|
Reopened to add pagination capability. |
| Comment by Magnolia International [ 20/Mar/15 ] |
|
Implementation is fine but lacks specification. Currently the behavior is undefined, so we pretty much let backends do whatever they want, and the client code can't know if different providers will behave differently. This is the comment I originally left on the concept page:
So what that means, really, is that you need to define very precisely the expected behaviors of the new params, in your interfaces. (e.g javadoc for getOffset; maxResults is self-descriptive, but offset can mean different things) It's good that you introduced AssetProviderCapability(ies) for this; I'd suggest they be named queryWithXXX like the previously existing ones, and placed neared the other query-related capabilities. |
| Comment by Robert Šiška [ 05/Jun/15 ] |
|
> They should also be checked.. |