[aerogear-dev] Client Paging Strawman
Summers Pittman
supittma at redhat.com
Mon Jan 14 14:28:33 EST 2013
On 01/14/2013 02:21 PM, Matthias Wessendorf wrote:
>
>
> On Mon, Jan 14, 2013 at 8: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 <mailto: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).
>
>
> haven't thought about typing, but a subclass (in iOS / Java land)
> sounds reasonable.
I say it makes reusing the paging logic harder because the thing which
can page is a subclass of RestAdapter. If we could somehow composite
Paging into rest adapter it would work out better. Composition is a bit
more work to get "right" than inheritance. (I say "right" because if it
is done wrong the classes end up being too tightly coupled and you might
as well have used inheritance to begin with).
>
> Will post something 2morrow
>
>
> The biggest issue I see with a PagedPipe is it means a developer
> can't change his paging preferences without creating a new Pipe.
>
>
>
> oh, I could not update the settings? That's a -1
>
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> 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/7c43517f/attachment-0001.html
More information about the aerogear-dev
mailing list