[aerogear-dev] Client Paging Strawman
Summers Pittman
supittma at redhat.com
Mon Jan 14 14:36:30 EST 2013
On 01/14/2013 02:34 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma at redhat.com
> <mailto:supittma at redhat.com>> wrote:
>
>> 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.
>
> OK, but then this is where I don't see the value in adding
> next/prev/first/last methods if I have to pass parameters (that aren't
> already stored on the pipe) with every use. Then as a developer, I
> might as well just use the basic query option in JS's read method,
> specify my parameters and call it a day and have less stuff to sort
> through in the docs on how to do paging.
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient definitions of
any) bookkeeping on the developer.
>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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/c5d86cef/attachment.html
More information about the aerogear-dev
mailing list