On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/14/2013 02:34 PM, Kris Borchers wrote:
>>
>> 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.
>
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.
This just feels like we're killing the dynamic nature of JS. :)
Well this is a
an description of a Java implementation.
Instead of a separate PageContext what if readWithFilter() returns a
PagedList which has next() and prev() as methods on it? In java this
can implement a list and be cast at runtime. The only question is does
next() return a new PagedList or return void and update the current
pagedlist?
>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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