[aerogear-dev] Client Paging Strawman

[Summers Pittman]

On 01/14/2013 02:27 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma at redhat.com 
> <mailto: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 list
>>> aerogear-dev at lists.jboss.org
>>> https://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).
>>
>> The biggest issue I see with a PagedPipe is it means a developer 
>> can't change his paging preferences without creating a new Pipe.
>
> If I add a setter for "paged" that would effectively fix that on the 
> JS side since offset and limit are already updatable. Does that work 
> for you?
No because I think fundamentally paging is part of the query and not 
part of the pipe.
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130114/b907d5fd/attachment.html