[aerogear-dev] Client Paging Strawman
Matthias Wessendorf
matzew at apache.org
Tue Jan 15 04:23:48 EST 2013
On Mon, Jan 14, 2013 at 8:28 PM, Summers Pittman <supittma at redhat.com>wrote:
> On 01/14/2013 02:21 PM, Matthias Wessendorf wrote:
>
>
>
> On Mon, Jan 14, 2013 at 8:17 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>
>> OK folks, below is the contents of this gist
>> https://gist.github.com/4531575. I may have missed a number of things,
>> gotten too specific in places or not specific enough in others. This should
>> hopefully get a good discussion going on how we want to handle paging
>> across all of the client libraries. Let's keep all comments on the list and
>> not the gist as much as possible to avoid breaking up the conversation.
>>
>> Below is a pipe configuration showing the different paging options.
>> Defaults are just suggestions and are up for discussion as much as the rest
>> of it
>>
>> var pagedPipe = AeroGear.Pipeline({
>> name: "pager",
>> settings: {
>> paged: {String}, // Default is "headers", can also be
>> "content", or undefined for no paging
>> pageConfig: { // Only required if paged is not undefined
>> // which page, header default is "AG-Paging-Offset",
>> content default is "paging.offset"
>> offset: {String},
>> offsetVal: {Number}, // Default 0 for first page
>>
>> // items per page, header default is "AG-Paging-Limit",
>> content default is "paging.limit"
>> limit: {String},
>> limitVal: {Number}, // Default 5 items per page
>>
>> // total number of items, header default is
>> "AG-Paging-Total", content default is "paging.total"
>> total: {String},
>>
>> // link to next page, default in both cases is undefined
>> next: {String},
>>
>> // link to previous page, default in both cases is
>> undefined
>> prev: {String}
>> }
>> }
>> }).pipes.pager;
>>
>> Getter/Setter methods should be provided for getting and updating the
>> offsetVal and limitVal defaults
>>
>> var defaultOffset = pagedPipe.getOffsetVal();
>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
>> page would be returned
>>
>> var defaultLimit = pagedPipe.getLimitVal();
>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
>> would be returned per page
>>
>> ## read()
>> By default, a read() against a paged pipe will return the first page
>> based on the default offsetVal and limitVal. We could possible add an
>> option that doesn't effect unpaged pipes but on a paged pipe, it can be
>> used to turn off paging for that read() and get all data
>>
>> // Get first page
>> pagedPipe.read({success callback handles data});
>>
>> // Get all data from paged pipe
>> pagedPipe.read({
>> page: false,
>> success: handle the data
>> });
>>
>> To avoid code duplication, **next**, **prev**, **first** and **last**
>> pages can be retrieved by passing an option to the read method of a paged
>> pipe since other than some paging housekeeping, the code would be the same.
>> We can also use that same option as above that was used to get all data
>> from a paged pipe. One question, when requesting prev from first page or
>> next from last page, should it throw an error that needs to be handled or
>> just return and empty data set? I see advantages and disadvantages of both.
>>
>> // Get next page
>> pagedPipe.read({
>> page: "next",
>> success: handle the data
>> });
>>
>> // Get previous page
>> pagedPipe.read({
>> page: "prev",
>> success: handle the data
>> });
>>
>> // Get first page
>> pagedPipe.read({
>> page: "first",
>> success: handle the data
>> });
>>
>> // Get last page
>> pagedPipe.read({
>> page: "last",
>> success: handle the data
>> });
>>
>>
>> _______________________________________________
>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> At first glance I don't like having the distinction between a "Pipe"
>> and a "PagedPipe". In Java land PagedPipe will be an interface which
>> extends Pipe (this is no big deal) and PagedRestAdatper would extend
>> RestAdapted and implement PagedPipe. This isn't too bad but it makes
>> reusing paging logic a bit harder. (And also this is at first glance).
>>
>
> haven't thought about typing, but a subclass (in iOS / Java land) sounds
> reasonable.
>
> I say it makes reusing the paging logic harder because the thing which can
> page is a subclass of RestAdapter. If we could somehow composite Paging
> into rest adapter it would work out better. Composition is a bit more work
> to get "right" than inheritance. (I say "right" because if it is done
> wrong the classes end up being too tightly coupled and you might as well
> have used inheritance to begin with).
>
+1 on composition
Also, "previous" name "PagedPipe" would be wrong, as the composition could
be handy for other query requests, instead of just plain paging
>
>
>
> Will post something 2morrow
>
>
>
>>
>> The biggest issue I see with a PagedPipe is it means a developer can't
>> change his paging preferences without creating a new Pipe.
>>
>
>
> oh, I could not update the settings? That's a -1
>
>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130115/5ccbe1d5/attachment-0001.html
More information about the aerogear-dev
mailing list