On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/14/2013 02:27 PM, Kris Borchers wrote:
>>
>> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com
>> <mailto:supittma@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(a)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.
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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev