On Jan 14, 2013, at 1:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 02:45 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma(a)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>
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> 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?
My problem with that is I would expect read() and readWithFilter() (though I still
maintain JS only needs read()), to both return a Promise since the call to the server is
async. I guess I could return some object which also includes that Promise along with
other stuff but just doesn't feel right.
>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
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
>>>
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
>
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