[aerogear-dev] Client Paging Strawman
Summers Pittman
supittma at redhat.com
Mon Jan 14 14:48:03 EST 2013
On 01/14/2013 02:45 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma at redhat.com
> <mailto:supittma at redhat.com>> wrote:
>
>> 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.
>
> 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 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
>>
>> _______________________________________________
>> 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/ed5c038b/attachment-0001.html
More information about the aerogear-dev
mailing list