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

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

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 listaerogear-dev@lists.jboss.orghttps://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.

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/14/2013 02:21 PM, Matthias Wessendorf wrote: On Mon, Jan 14, 2013 at 8:17 PM, Summers Pittman <supittma(a)redhat.com&gt;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 listaerogear-dev@lists.jboss.orghttps://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(a)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 listaerogear-dev@lists.jboss.orghttps://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

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?

> > _______________________________________________ > 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

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.

>>> >>> _______________________________________________ >>> 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

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. :)

>> >>>>> >>>>> _______________________________________________ >>>>> 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

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.

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.

Hi, Some aditional remarks on Summers gist : Instead of : Pipe.readWithFilter(ReadFilter) Couldn't we just overload the read() method ? i.e : read(ReadFilter filter)

About the where property in ReadFilter class : Do we really want to mix paging and querying ? About Pipe.getPageContext(List result): Same remarks as Matthias, not sure to understand how it works (even if I think I've understand ...) General remarks about Paging: Even if it's not in scope for 1.0, I think we have to keep in mind that we will also be able to do pagination "offline" / "only client side" (maybe we would do some paging on a Store element ?) , so we have to consider this when designing our API. Seb On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > https://gist.github.com/4532661 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/15/2013 06:17 AM, Sebastien Blanc wrote: Hi, Some aditional remarks on Summers gist : Instead of : Pipe.readWithFilter(ReadFilter) Couldn't we just overload the read() method ? i.e : read(ReadFilter filter) We can depending on how it interacts with the other implementations of the library.

About the where property in ReadFilter class : Do we really want to mix paging and querying ? We do and we don't. The request itself requires both of these properties so it makes technical sense to pass them in a single wrapper. I agree it makes more logical sense to keep them as two separate object which you can pass independently. About Pipe.getPageContext(List result): Same remarks as Matthias, not sure to understand how it works (even if I think I've understand ...) In Java it's back by a WeakHashMap. Lots of Java specific implementation magic makes it very easy. As I've said otherwise I'm not in love with the method but it scratches an itch. General remarks about Paging: Even if it's not in scope for 1.0, I think we have to keep in mind that we will also be able to do pagination "offline" / "only client side" (maybe we would do some paging on a Store element ?) , so we have to consider this when designing our API. I've been thinking about that as well. The Stores we have right now don't lend themselves to paging very well because they don't have a concept of order built in. Seb On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > https://gist.github.com/4532661 _______________________________________________ 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

Hi Summers, 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. from your Andorid gist: A) Once the response has been received, the Pipe implementation will return a List of objects. If this List instance is passed to Pipe.getPageContext the appropriate PageContext will be returned Note: There is no 'return' - the readWithFilter is void, instead a Callback is invoked (onSuccess(list)), see Pipe.java B) The developer will receive from readWithFilter() a List of object. If she passes this list into Pipe.getPageContext(List result) she will receive the PageContext associated with this result. Do you mean like: ... myPipe.readWithFilter(filter, new Callback<List<Data>>() { @Override public void onSuccess(List<Data> data) { // get the PageContext: PageContext ctx = myPipe.getPageContext(data); ... } @Override public void onFailure(Exception e) { } }); Not sure about that..... But for iOS I am thinking about passing in the PageContext into the closure/block of the readWithFilter, like: -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config success:(void (^)(id listOfObjects, id pageContext))success failure:(void (^)(NSError *error))failure; A usage would look like: [pipe readWithFilter:^(id<AGFilterConfig> config) { // set the filter args and override the given defaults } success:^(id listOfObjects, id pageContext) { // work with the listOfObjects reponse. // for paging/query info, access the given pagecontext, // of the CURRENT request ... } failure:^(NSError *error) { // handle errorz }]; Any thoughts ? Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current mindset is that thePageContext just (and only) belongs to the previous (executed) request... Not sure I want to support something like // first call: List<SomeType> first; myPipe.readWithFilter(.....) // set first inside of callback ... // second call: List<SomeType> second; myPipe.readWithFilter(.....) // set second inside of callback ... // third call: List<SomeType> third; myPipe.readWithFilter(.....) // set third inside of callback ... /// A BIT LATER ....: myPipe.getPageContext(first); I am not sure if that (myPipe.getPageContext(first);) is really desired (or would even easily work, as it would need to store the "metadata")..... Perhaps I am just wrong. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

the pageResult.next() (and the asyncResult.next(someCallback)) would invoke the "read(readFilter)" on the previously used pipe object, right ?

the pageResult.next() (and the asyncResult.next(someCallback)) would invoke the "read(readFilter)" on the previously used pipe object, right ? -M On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > I'm not a fan of those PageContext objects (remembers me of some wild-ass ThreadLocals leaking all over) > > My proposal for the paging aware APIs would be something like this: > > public interface PagedResult<T> { > > List<T> next(); > > List<T> prev(); > > List<T> page(int offset, int limit); > > } > > and the Async counterpart > > public interface AsyncPagedResult<T> { > > void next(Callback<List<T>> callback); > > void prev(Callback<List<T>> callback); > > void page(int offset, int limit, Callback<List<T>> callback); > > public static interface Callback<U> { > public void onResult(U result); > } > } > > I don't like the idea of having a companion object for holding the pagination state. > > Thoughts? > > -- qmx > > On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> Hi Summers, >> >> >> 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. >> >> >> from your Andorid gist: >> >> A) Once the response has been received, the Pipe implementation will return a List of objects. If this List instance is passed to Pipe.getPageContext the appropriate PageContext will be returned >> >> Note: There is no 'return' - the readWithFilter is void, instead a Callback is invoked (onSuccess(list)), see Pipe.java >> >> B) The developer will receive from readWithFilter() a List of object. If she passes this list into Pipe.getPageContext(List result) she will receive the PageContext associated with this result. >> >> Do you mean like: >> >> ... >> myPipe.readWithFilter(filter, new Callback<List<Data>>() { >> >> >> @Override >> >> >> public void onSuccess(List<Data> data) { >> >> >> >> // get the PageContext: >> >> >> PageContext ctx = myPipe.getPageContext(data); >> >> >> ... >> >> >> } >> >> >> >> @Override >> >> >> public void onFailure(Exception e) { >> >> >> } >> }); >> Not sure about that..... >> >> But for iOS I am thinking about passing in the PageContext into the closure/block of the readWithFilter, like: >> >> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >> >> >> success:(void (^)(id listOfObjects, id pageContext))success >> >> >> failure:(void (^)(NSError *error))failure; >> A usage would look like: >> >> [pipe readWithFilter:^(id<AGFilterConfig> config) { >> >> >> // set the filter args and override the given defaults >> >> >> } success:^(id listOfObjects, id pageContext) { >> >> >> // work with the listOfObjects reponse. >> >> >> // for paging/query info, access the given pagecontext, >> >> >> // of the CURRENT request >> >> >> ... >> >> >> } failure:^(NSError *error) { >> >> >> // handle errorz >> >> >> }]; >> Any thoughts ? >> >> Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current mindset is that thePageContext just (and only) belongs to the previous (executed) request... Not sure I want to support something like >> >> // first call: >> List<SomeType> first; >> myPipe.readWithFilter(.....) // set first inside of callback >> ... >> // second call: >> List<SomeType> second; >> myPipe.readWithFilter(.....) // set second inside of callback >> ... >> // third call: >> List<SomeType> third; >> myPipe.readWithFilter(.....) // set third inside of callback >> ... >> >> >> >> >> /// A BIT LATER ....: >> myPipe.getPageContext(first); >> >> >> I am not sure if that (myPipe.getPageContext(first);) is really desired (or would even easily work, as it would need to store the "metadata")..... >> >> >> Perhaps I am just wrong. >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf _______________________________________________ >> 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

In the same spirit (inspired from http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) : public interface PagedResult<T> { PagedResult<T> next(); PagedResult<T> prev(); PagedResult<T> withOffset(int offset); PagedResult<T> withLimit(int limit); List<T> result(); } On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > > I'm not a fan of those PageContext objects (remembers me of some wild-ass > ThreadLocals leaking all over) > > My proposal for the paging aware APIs would be something like this: > > public interface PagedResult<T> { > > List<T> next(); > > List<T> prev(); > > List<T> page(int offset, int limit); > > } > > and the Async counterpart > > public interface AsyncPagedResult<T> { > > void next(Callback<List<T>> callback); > > void prev(Callback<List<T>> callback); > > void page(int offset, int limit, Callback<List<T>> callback); > > public static interface Callback<U> { > public void onResult(U result); > } > } > > I don't like the idea of having a companion object for holding the > pagination state. > > Thoughts? > > -- qmx > > On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > Hi Summers, > > > > > > 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. > > > > > > from your Andorid gist: > > > > A) Once the response has been received, the Pipe implementation will > > return a List of objects. If this List instance is passed to > > Pipe.getPageContext the appropriate PageContext will be returned > > > > Note: There is no 'return' - the readWithFilter is void, instead a > > Callback is invoked (onSuccess(list)), see Pipe.java > > > > B) The developer will receive from readWithFilter() a List of object. If > > she passes this list into Pipe.getPageContext(List result) she will receive > > the PageContext associated with this result. > > > > Do you mean like: > > > > ... > > myPipe.readWithFilter(filter, new Callback<List<Data>>() { > > > > > > @Override > > > > > > public void onSuccess(List<Data> data) { > > > > > > > > // get the PageContext: > > > > > > PageContext ctx = myPipe.getPageContext(data); > > > > > > ... > > > > > > } > > > > > > > > @Override > > > > > > public void onFailure(Exception e) { > > > > > > } > > }); > > Not sure about that..... > > > > But for iOS I am thinking about passing in the PageContext into the > > closure/block of the readWithFilter, like: > > > > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config > > > > > > success:(void (^)(id listOfObjects, id pageContext))success > > > > > > failure:(void (^)(NSError *error))failure; > > A usage would look like: > > > > [pipe readWithFilter:^(id<AGFilterConfig> config) { > > > > > > // set the filter args and override the given defaults > > > > > > } success:^(id listOfObjects, id pageContext) { > > > > > > // work with the listOfObjects reponse. > > > > > > // for paging/query info, access the given pagecontext, > > > > > > // of the CURRENT request > > > > > > ... > > > > > > } failure:^(NSError *error) { > > > > > > // handle errorz > > > > > > }]; > > Any thoughts ? > > > > Not sure I like (or understand) the Pipe.getPageContext(List result) > > call. Current mindset is that thePageContext just (and only) belongs to the > > previous (executed) request... Not sure I want to support something like > > > > // first call: > > List<SomeType> first; > > myPipe.readWithFilter(.....) // set first inside of callback > > ... > > // second call: > > List<SomeType> second; > > myPipe.readWithFilter(.....) // set second inside of callback > > ... > > // third call: > > List<SomeType> third; > > myPipe.readWithFilter(.....) // set third inside of callback > > ... > > > > > > > > > > /// A BIT LATER ....: > > myPipe.getPageContext(first); > > > > > > I am not sure if that (myPipe.getPageContext(first);) is really desired > > (or would even easily work, as it would need to store the "metadata")..... > > > > > > Perhaps I am just wrong. > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > 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

On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > I was wondering, if the result should be received on every rquest, ideally on the callback..., to not block (at least in iOS land, I would pass that "result set" on to the "success" block) -M > > thx > > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> In the same spirit (inspired from >> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin... ) >> : >> >> >> public interface PagedResult<T> { >> >> PagedResult<T> next(); >> >> PagedResult<T> prev(); >> >> PagedResult<T> withOffset(int offset); >> >> PagedResult<T> withLimit(int limit); >> >> List<T> result(); >> >> } >> >> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> >>> I'm not a fan of those PageContext objects (remembers me of some wild-ass >>> ThreadLocals leaking all over) >>> >>> My proposal for the paging aware APIs would be something like this: >>> >>> public interface PagedResult<T> { >>> >>> List<T> next(); >>> >>> List<T> prev(); >>> >>> List<T> page(int offset, int limit); >>> >>> } >>> >>> and the Async counterpart >>> >>> public interface AsyncPagedResult<T> { >>> >>> void next(Callback<List<T>> callback); >>> >>> void prev(Callback<List<T>> callback); >>> >>> void page(int offset, int limit, Callback<List<T>> callback); >>> >>> public static interface Callback<U> { >>> public void onResult(U result); >>> } >>> } >>> >>> I don't like the idea of having a companion object for holding the >>> pagination state. >>> >>> Thoughts? >>> >>> -- qmx >>> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> > Hi Summers, >>> > >>> > >>> > 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. >>> > >>> > >>> > from your Andorid gist: >>> > >>> > A) Once the response has been received, the Pipe implementation will >>> > return a List of objects. If this List instance is passed to >>> > Pipe.getPageContext the appropriate PageContext will be returned >>> > >>> > Note: There is no 'return' - the readWithFilter is void, instead a >>> > Callback is invoked (onSuccess(list)), see Pipe.java >>> > >>> > B) The developer will receive from readWithFilter() a List of object. If >>> > she passes this list into Pipe.getPageContext(List result) she will receive >>> > the PageContext associated with this result. >>> > >>> > Do you mean like: >>> > >>> > ... >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onSuccess(List<Data> data) { >>> > >>> > >>> > >>> > // get the PageContext: >>> > >>> > >>> > PageContext ctx = myPipe.getPageContext(data); >>> > >>> > >>> > ... >>> > >>> > >>> > } >>> > >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onFailure(Exception e) { >>> > >>> > >>> > } >>> > }); >>> > Not sure about that..... >>> > >>> > But for iOS I am thinking about passing in the PageContext into the >>> > closure/block of the readWithFilter, like: >>> > >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >>> > >>> > >>> > success:(void (^)(id listOfObjects, id pageContext))success >>> > >>> > >>> > failure:(void (^)(NSError *error))failure; >>> > A usage would look like: >>> > >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { >>> > >>> > >>> > // set the filter args and override the given defaults >>> > >>> > >>> > } success:^(id listOfObjects, id pageContext) { >>> > >>> > >>> > // work with the listOfObjects reponse. >>> > >>> > >>> > // for paging/query info, access the given pagecontext, >>> > >>> > >>> > // of the CURRENT request >>> > >>> > >>> > ... >>> > >>> > >>> > } failure:^(NSError *error) { >>> > >>> > >>> > // handle errorz >>> > >>> > >>> > }]; >>> > Any thoughts ? >>> > >>> > Not sure I like (or understand) the Pipe.getPageContext(List result) >>> > call. Current mindset is that thePageContext just (and only) belongs to the >>> > previous (executed) request... Not sure I want to support something like >>> > >>> > // first call: >>> > List<SomeType> first; >>> > myPipe.readWithFilter(.....) // set first inside of callback >>> > ... >>> > // second call: >>> > List<SomeType> second; >>> > myPipe.readWithFilter(.....) // set second inside of callback >>> > ... >>> > // third call: >>> > List<SomeType> third; >>> > myPipe.readWithFilter(.....) // set third inside of callback >>> > ... >>> > >>> > >>> > >>> > >>> > /// A BIT LATER ....: >>> > myPipe.getPageContext(first); >>> > >>> > >>> > I am not sure if that (myPipe.getPageContext(first);) is really desired >>> > (or would even easily work, as it would need to store the "metadata")..... >>> > >>> > >>> > Perhaps I am just wrong. >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > _______________________________________________ >>> > 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Just to summarize what have until now : 1. Kris's proposition: https://gist.github.com/4531575 2. Summers's proposition: https://gist.github.com/4532661 3. qmx's propositon: https://gist.github.com/4538709 4. Sebi's propositionhttps://gist.github.com/4538725 On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > I was wondering, if the result should be received on every rquest, ideally on the callback..., to not block (at least in iOS land, I would pass that "result set" on to the "success" block) -M > > thx > > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> In the same spirit (inspired from >> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) >> : >> >> >> public interface PagedResult<T> { >> >> PagedResult<T> next(); >> >> PagedResult<T> prev(); >> >> PagedResult<T> withOffset(int offset); >> >> PagedResult<T> withLimit(int limit); >> >> List<T> result(); >> >> } >> >> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> >>> I'm not a fan of those PageContext objects (remembers me of some wild-ass >>> ThreadLocals leaking all over) >>> >>> My proposal for the paging aware APIs would be something like this: >>> >>> public interface PagedResult<T> { >>> >>> List<T> next(); >>> >>> List<T> prev(); >>> >>> List<T> page(int offset, int limit); >>> >>> } >>> >>> and the Async counterpart >>> >>> public interface AsyncPagedResult<T> { >>> >>> void next(Callback<List<T>> callback); >>> >>> void prev(Callback<List<T>> callback); >>> >>> void page(int offset, int limit, Callback<List<T>> callback); >>> >>> public static interface Callback<U> { >>> public void onResult(U result); >>> } >>> } >>> >>> I don't like the idea of having a companion object for holding the >>> pagination state. >>> >>> Thoughts? >>> >>> -- qmx >>> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> > Hi Summers, >>> > >>> > >>> > 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. >>> > >>> > >>> > from your Andorid gist: >>> > >>> > A) Once the response has been received, the Pipe implementation will >>> > return a List of objects. If this List instance is passed to >>> > Pipe.getPageContext the appropriate PageContext will be returned >>> > >>> > Note: There is no 'return' - the readWithFilter is void, instead a >>> > Callback is invoked (onSuccess(list)), see Pipe.java >>> > >>> > B) The developer will receive from readWithFilter() a List of object. If >>> > she passes this list into Pipe.getPageContext(List result) she will receive >>> > the PageContext associated with this result. >>> > >>> > Do you mean like: >>> > >>> > ... >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onSuccess(List<Data> data) { >>> > >>> > >>> > >>> > // get the PageContext: >>> > >>> > >>> > PageContext ctx = myPipe.getPageContext(data); >>> > >>> > >>> > ... >>> > >>> > >>> > } >>> > >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onFailure(Exception e) { >>> > >>> > >>> > } >>> > }); >>> > Not sure about that..... >>> > >>> > But for iOS I am thinking about passing in the PageContext into the >>> > closure/block of the readWithFilter, like: >>> > >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >>> > >>> > >>> > success:(void (^)(id listOfObjects, id pageContext))success >>> > >>> > >>> > failure:(void (^)(NSError *error))failure; >>> > A usage would look like: >>> > >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { >>> > >>> > >>> > // set the filter args and override the given defaults >>> > >>> > >>> > } success:^(id listOfObjects, id pageContext) { >>> > >>> > >>> > // work with the listOfObjects reponse. >>> > >>> > >>> > // for paging/query info, access the given pagecontext, >>> > >>> > >>> > // of the CURRENT request >>> > >>> > >>> > ... >>> > >>> > >>> > } failure:^(NSError *error) { >>> > >>> > >>> > // handle errorz >>> > >>> > >>> > }]; >>> > Any thoughts ? >>> > >>> > Not sure I like (or understand) the Pipe.getPageContext(List result) >>> > call. Current mindset is that thePageContext just (and only) belongs to the >>> > previous (executed) request... Not sure I want to support something like >>> > >>> > // first call: >>> > List<SomeType> first; >>> > myPipe.readWithFilter(.....) // set first inside of callback >>> > ... >>> > // second call: >>> > List<SomeType> second; >>> > myPipe.readWithFilter(.....) // set second inside of callback >>> > ... >>> > // third call: >>> > List<SomeType> third; >>> > myPipe.readWithFilter(.....) // set third inside of callback >>> > ... >>> > >>> > >>> > >>> > >>> > /// A BIT LATER ....: >>> > myPipe.getPageContext(first); >>> > >>> > >>> > I am not sure if that (myPipe.getPageContext(first);) is really desired >>> > (or would even easily work, as it would need to store the "metadata")..... >>> > >>> > >>> > Perhaps I am just wrong. >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > _______________________________________________ >>> > 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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

On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Though this discussion has been great, I feel like it has headed "down a > path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;) > > When doing a read() (or next() or prev()…), I would expect the exact same > type of response, which is a list of objects. This is easily accomplished in > JS, we overload the read method to accept a parameter that tells it to use > paging and which page to grab and then return only the results that were > requested. This can then be made easier with helper functions like next(), > prev(), etc. that use the overloaded read() method so the dev doesn't even > need to know it exists of they don't want. This would be accomplished by > maintaining the current paging state on the pipe so a call to next() just > knows what to do. Also, via a couple of setter methods on the pipe instance, > we can adjust the offset and limit at any time. > > I honestly feel like this is going to be the best developer experience on > JS, I just don't know how or if it even makes sense for iOS and Java to try > to get there but for JS I just can't get myself onboard with this idea of > returning an object that contains next(), prev(), etc. methods instead of > just the data that the user wants. on next() a callback would be invoked, which delivers: - the payload (like it does on read) - the "paged result set" does that make sense ?

> > On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > Just to summarize what have until now : > > 1. Kris's proposition: https://gist.github.com/4531575 > > 2. Summers's proposition: https://gist.github.com/4532661 > > 3. qmx's propositon: https://gist.github.com/4538709 > > 4. Sebi's propositionhttps://gist.github.com/4538725 > > > > > On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: >> >> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >>> I was wondering, if the result should be received on every rquest, >> >> >> ideally on the callback..., to not block (at least in iOS land, I >> would pass that "result set" on to the "success" block) >> >> -M >> >>> >>> thx >>> >>> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>>> In the same spirit (inspired from >>>> >>>> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) >>>> : >>>> >>>> >>>> public interface PagedResult<T> { >>>> >>>> PagedResult<T> next(); >>>> >>>> PagedResult<T> prev(); >>>> >>>> PagedResult<T> withOffset(int offset); >>>> >>>> PagedResult<T> withLimit(int limit); >>>> >>>> List<T> result(); >>>> >>>> } >>>> >>>> >>>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>>>> >>>>> I'm not a fan of those PageContext objects (remembers me of some >>>>> wild-ass >>>>> ThreadLocals leaking all over) >>>>> >>>>> My proposal for the paging aware APIs would be something like this: >>>>> >>>>> public interface PagedResult<T> { >>>>> >>>>> List<T> next(); >>>>> >>>>> List<T> prev(); >>>>> >>>>> List<T> page(int offset, int limit); >>>>> >>>>> } >>>>> >>>>> and the Async counterpart >>>>> >>>>> public interface AsyncPagedResult<T> { >>>>> >>>>> void next(Callback<List<T>> callback); >>>>> >>>>> void prev(Callback<List<T>> callback); >>>>> >>>>> void page(int offset, int limit, Callback<List<T>> callback); >>>>> >>>>> public static interface Callback<U> { >>>>> public void onResult(U result); >>>>> } >>>>> } >>>>> >>>>> I don't like the idea of having a companion object for holding the >>>>> pagination state. >>>>> >>>>> Thoughts? >>>>> >>>>> -- qmx >>>>> >>>>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>> wrote: >>>>> >>>>>> Hi Summers, >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> from your Andorid gist: >>>>>> >>>>>> A) Once the response has been received, the Pipe implementation will >>>>>> return a List of objects. If this List instance is passed to >>>>>> Pipe.getPageContext the appropriate PageContext will be returned >>>>>> >>>>>> Note: There is no 'return' - the readWithFilter is void, instead a >>>>>> Callback is invoked (onSuccess(list)), see Pipe.java >>>>>> >>>>>> B) The developer will receive from readWithFilter() a List of >>>>>> object. If >>>>>> she passes this list into Pipe.getPageContext(List result) she will >>>>>> receive >>>>>> the PageContext associated with this result. >>>>>> >>>>>> Do you mean like: >>>>>> >>>>>> ... >>>>>> myPipe.readWithFilter(filter, new Callback<List<Data>>() { >>>>>> >>>>>> >>>>>> @Override >>>>>> >>>>>> >>>>>> public void onSuccess(List<Data> data) { >>>>>> >>>>>> >>>>>> >>>>>> // get the PageContext: >>>>>> >>>>>> >>>>>> PageContext ctx = myPipe.getPageContext(data); >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> @Override >>>>>> >>>>>> >>>>>> public void onFailure(Exception e) { >>>>>> >>>>>> >>>>>> } >>>>>> }); >>>>>> Not sure about that..... >>>>>> >>>>>> But for iOS I am thinking about passing in the PageContext into the >>>>>> closure/block of the readWithFilter, like: >>>>>> >>>>>> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >>>>>> >>>>>> >>>>>> success:(void (^)(id listOfObjects, id pageContext))success >>>>>> >>>>>> >>>>>> failure:(void (^)(NSError *error))failure; >>>>>> A usage would look like: >>>>>> >>>>>> [pipe readWithFilter:^(id<AGFilterConfig> config) { >>>>>> >>>>>> >>>>>> // set the filter args and override the given defaults >>>>>> >>>>>> >>>>>> } success:^(id listOfObjects, id pageContext) { >>>>>> >>>>>> >>>>>> // work with the listOfObjects reponse. >>>>>> >>>>>> >>>>>> // for paging/query info, access the given pagecontext, >>>>>> >>>>>> >>>>>> // of the CURRENT request >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> } failure:^(NSError *error) { >>>>>> >>>>>> >>>>>> // handle errorz >>>>>> >>>>>> >>>>>> }]; >>>>>> Any thoughts ? >>>>>> >>>>>> Not sure I like (or understand) the Pipe.getPageContext(List result) >>>>>> call. Current mindset is that thePageContext just (and only) belongs >>>>>> to the >>>>>> previous (executed) request... Not sure I want to support something >>>>>> like >>>>>> >>>>>> // first call: >>>>>> List<SomeType> first; >>>>>> myPipe.readWithFilter(.....) // set first inside of callback >>>>>> ... >>>>>> // second call: >>>>>> List<SomeType> second; >>>>>> myPipe.readWithFilter(.....) // set second inside of callback >>>>>> ... >>>>>> // third call: >>>>>> List<SomeType> third; >>>>>> myPipe.readWithFilter(.....) // set third inside of callback >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> /// A BIT LATER ....: >>>>>> myPipe.getPageContext(first); >>>>>> >>>>>> >>>>>> I am not sure if that (myPipe.getPageContext(first);) is really >>>>>> desired >>>>>> (or would even easily work, as it would need to store the >>>>>> "metadata")..... >>>>>> >>>>>> >>>>>> Perhaps I am just wrong. >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jan 15, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jan 15, 2013, at 7:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> Though this discussion has been great, I feel like it has headed "down a >>> path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;) >>> >>> When doing a read() (or next() or prev()…), I would expect the exact same >>> type of response, which is a list of objects. This is easily accomplished in >>> JS, we overload the read method to accept a parameter that tells it to use >>> paging and which page to grab and then return only the results that were >>> requested. This can then be made easier with helper functions like next(), >>> prev(), etc. that use the overloaded read() method so the dev doesn't even >>> need to know it exists of they don't want. This would be accomplished by >>> maintaining the current paging state on the pipe so a call to next() just >>> knows what to do. Also, via a couple of setter methods on the pipe instance, >>> we can adjust the offset and limit at any time. >>> >>> I honestly feel like this is going to be the best developer experience on >>> JS, I just don't know how or if it even makes sense for iOS and Java to try >>> to get there but for JS I just can't get myself onboard with this idea of >>> returning an object that contains next(), prev(), etc. methods instead of >>> just the data that the user wants. >> >> >> on next() a callback would be invoked, which delivers: >> - the payload (like it does on read) >> - the "paged result set" >> >> does that make sense ? > > Not really. All I would want returned from next() is the array of objects (payload) just as read() works. yes > If that changes, then I have to interact with next() differently than I would read() and that doesn't seem like a good developer experience because how would you change the paging params? Like from "3rd next invoke, I want to show 20, instead of 5". Hrm...Perhaps that would mean a new "pipe" needs to be set up ?

-M > I can just dump the result of read() into my templates for example, but I have to hang on to and further process the result from next() in your suggestion. I'm not a fan. >> >> >> >>> >>> On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>> Just to summarize what have until now : >>> >>> 1. Kris's proposition: https://gist.github.com/4531575 >>> >>> 2. Summers's proposition: https://gist.github.com/4532661 >>> >>> 3. qmx's propositon: https://gist.github.com/4538709 >>> >>> 4. Sebi's propositionhttps://gist.github.com/4538725 >>> >>> >>> >>> >>> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>>> >>>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>>> I was wondering, if the result should be received on every rquest, >>>> >>>> >>>> ideally on the callback..., to not block (at least in iOS land, I >>>> would pass that "result set" on to the "success" block) >>>> >>>> -M >>>> >>>>> >>>>> thx >>>>> >>>>> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>> wrote: >>>>>> In the same spirit (inspired from >>>>>> >>>>>> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) >>>>>> : >>>>>> >>>>>> >>>>>> public interface PagedResult<T> { >>>>>> >>>>>> PagedResult<T> next(); >>>>>> >>>>>> PagedResult<T> prev(); >>>>>> >>>>>> PagedResult<T> withOffset(int offset); >>>>>> >>>>>> PagedResult<T> withLimit(int limit); >>>>>> >>>>>> List<T> result(); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>>>>>> >>>>>>> I'm not a fan of those PageContext objects (remembers me of some >>>>>>> wild-ass >>>>>>> ThreadLocals leaking all over) >>>>>>> >>>>>>> My proposal for the paging aware APIs would be something like this: >>>>>>> >>>>>>> public interface PagedResult<T> { >>>>>>> >>>>>>> List<T> next(); >>>>>>> >>>>>>> List<T> prev(); >>>>>>> >>>>>>> List<T> page(int offset, int limit); >>>>>>> >>>>>>> } >>>>>>> >>>>>>> and the Async counterpart >>>>>>> >>>>>>> public interface AsyncPagedResult<T> { >>>>>>> >>>>>>> void next(Callback<List<T>> callback); >>>>>>> >>>>>>> void prev(Callback<List<T>> callback); >>>>>>> >>>>>>> void page(int offset, int limit, Callback<List<T>> callback); >>>>>>> >>>>>>> public static interface Callback<U> { >>>>>>> public void onResult(U result); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> I don't like the idea of having a companion object for holding the >>>>>>> pagination state. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> -- qmx >>>>>>> >>>>>>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Summers, >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> from your Andorid gist: >>>>>>>> >>>>>>>> A) Once the response has been received, the Pipe implementation will >>>>>>>> return a List of objects. If this List instance is passed to >>>>>>>> Pipe.getPageContext the appropriate PageContext will be returned >>>>>>>> >>>>>>>> Note: There is no 'return' - the readWithFilter is void, instead a >>>>>>>> Callback is invoked (onSuccess(list)), see Pipe.java >>>>>>>> >>>>>>>> B) The developer will receive from readWithFilter() a List of >>>>>>>> object. If >>>>>>>> she passes this list into Pipe.getPageContext(List result) she will >>>>>>>> receive >>>>>>>> the PageContext associated with this result. >>>>>>>> >>>>>>>> Do you mean like: >>>>>>>> >>>>>>>> ... >>>>>>>> myPipe.readWithFilter(filter, new Callback<List<Data>>() { >>>>>>>> >>>>>>>> >>>>>>>> @Override >>>>>>>> >>>>>>>> >>>>>>>> public void onSuccess(List<Data> data) { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> // get the PageContext: >>>>>>>> >>>>>>>> >>>>>>>> PageContext ctx = myPipe.getPageContext(data); >>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> @Override >>>>>>>> >>>>>>>> >>>>>>>> public void onFailure(Exception e) { >>>>>>>> >>>>>>>> >>>>>>>> } >>>>>>>> }); >>>>>>>> Not sure about that..... >>>>>>>> >>>>>>>> But for iOS I am thinking about passing in the PageContext into the >>>>>>>> closure/block of the readWithFilter, like: >>>>>>>> >>>>>>>> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >>>>>>>> >>>>>>>> >>>>>>>> success:(void (^)(id listOfObjects, id pageContext))success >>>>>>>> >>>>>>>> >>>>>>>> failure:(void (^)(NSError *error))failure; >>>>>>>> A usage would look like: >>>>>>>> >>>>>>>> [pipe readWithFilter:^(id<AGFilterConfig> config) { >>>>>>>> >>>>>>>> >>>>>>>> // set the filter args and override the given defaults >>>>>>>> >>>>>>>> >>>>>>>> } success:^(id listOfObjects, id pageContext) { >>>>>>>> >>>>>>>> >>>>>>>> // work with the listOfObjects reponse. >>>>>>>> >>>>>>>> >>>>>>>> // for paging/query info, access the given pagecontext, >>>>>>>> >>>>>>>> >>>>>>>> // of the CURRENT request >>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> } failure:^(NSError *error) { >>>>>>>> >>>>>>>> >>>>>>>> // handle errorz >>>>>>>> >>>>>>>> >>>>>>>> }]; >>>>>>>> Any thoughts ? >>>>>>>> >>>>>>>> Not sure I like (or understand) the Pipe.getPageContext(List result) >>>>>>>> call. Current mindset is that thePageContext just (and only) belongs >>>>>>>> to the >>>>>>>> previous (executed) request... Not sure I want to support something >>>>>>>> like >>>>>>>> >>>>>>>> // first call: >>>>>>>> List<SomeType> first; >>>>>>>> myPipe.readWithFilter(.....) // set first inside of callback >>>>>>>> ... >>>>>>>> // second call: >>>>>>>> List<SomeType> second; >>>>>>>> myPipe.readWithFilter(.....) // set second inside of callback >>>>>>>> ... >>>>>>>> // third call: >>>>>>>> List<SomeType> third; >>>>>>>> myPipe.readWithFilter(.....) // set third inside of callback >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /// A BIT LATER ....: >>>>>>>> myPipe.getPageContext(first); >>>>>>>> >>>>>>>> >>>>>>>> I am not sure if that (myPipe.getPageContext(first);) is really >>>>>>>> desired >>>>>>>> (or would even easily work, as it would need to store the >>>>>>>> "metadata")..... >>>>>>>> >>>>>>>> >>>>>>>> Perhaps I am just wrong. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jan 15, 2013 at 3:12 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Nope, as I've said before, there would be a setter for offset and limit so that the initial values that were used when the pipe was set up can be modified at any time. ok, that's a detail - but on a "context" (or what ever) this could be done.. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

Just to summarize what have until now : 1. Kris's proposition: https://gist.github.com/4531575 2. Summers's proposition: https://gist.github.com/4532661 3. qmx's propositon: https://gist.github.com/4538709 4. Sebi's propositionhttps://gist.github.com/4538725

On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > I was wondering, if the result should be received on every rquest, ideally on the callback..., to not block (at least in iOS land, I would pass that "result set" on to the "success" block) -M > > thx > > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >> In the same spirit (inspired from >> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) >> : >> >> >> public interface PagedResult<T> { >> >> PagedResult<T> next(); >> >> PagedResult<T> prev(); >> >> PagedResult<T> withOffset(int offset); >> >> PagedResult<T> withLimit(int limit); >> >> List<T> result(); >> >> } >> >> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me <mailto:qmx@qmx.me>> wrote: >>> >>> I'm not a fan of those PageContext objects (remembers me of some wild-ass >>> ThreadLocals leaking all over) >>> >>> My proposal for the paging aware APIs would be something like this: >>> >>> public interface PagedResult<T> { >>> >>> List<T> next(); >>> >>> List<T> prev(); >>> >>> List<T> page(int offset, int limit); >>> >>> } >>> >>> and the Async counterpart >>> >>> public interface AsyncPagedResult<T> { >>> >>> void next(Callback<List<T>> callback); >>> >>> void prev(Callback<List<T>> callback); >>> >>> void page(int offset, int limit, Callback<List<T>> callback); >>> >>> public static interface Callback<U> { >>> public void onResult(U result); >>> } >>> } >>> >>> I don't like the idea of having a companion object for holding the >>> pagination state. >>> >>> Thoughts? >>> >>> -- qmx >>> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>> >>> > Hi Summers, >>> > >>> > >>> > 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. >>> > >>> > >>> > from your Andorid gist: >>> > >>> > A) Once the response has been received, the Pipe implementation will >>> > return a List of objects. If this List instance is passed to >>> > Pipe.getPageContext the appropriate PageContext will be returned >>> > >>> > Note: There is no 'return' - the readWithFilter is void, instead a >>> > Callback is invoked (onSuccess(list)), see Pipe.java >>> > >>> > B) The developer will receive from readWithFilter() a List of object. If >>> > she passes this list into Pipe.getPageContext(List result) she will receive >>> > the PageContext associated with this result. >>> > >>> > Do you mean like: >>> > >>> > ... >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onSuccess(List<Data> data) { >>> > >>> > >>> > >>> > // get the PageContext: >>> > >>> > >>> > PageContext ctx = myPipe.getPageContext(data); >>> > >>> > >>> > ... >>> > >>> > >>> > } >>> > >>> > >>> > >>> > @Override >>> > >>> > >>> > public void onFailure(Exception e) { >>> > >>> > >>> > } >>> > }); >>> > Not sure about that..... >>> > >>> > But for iOS I am thinking about passing in the PageContext into the >>> > closure/block of the readWithFilter, like: >>> > >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config >>> > >>> > >>> > success:(void (^)(id listOfObjects, id pageContext))success >>> > >>> > >>> > failure:(void (^)(NSError *error))failure; >>> > A usage would look like: >>> > >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { >>> > >>> > >>> > // set the filter args and override the given defaults >>> > >>> > >>> > } success:^(id listOfObjects, id pageContext) { >>> > >>> > >>> > // work with the listOfObjects reponse. >>> > >>> > >>> > // for paging/query info, access the given pagecontext, >>> > >>> > >>> > // of the CURRENT request >>> > >>> > >>> > ... >>> > >>> > >>> > } failure:^(NSError *error) { >>> > >>> > >>> > // handle errorz >>> > >>> > >>> > }]; >>> > Any thoughts ? >>> > >>> > Not sure I like (or understand) the Pipe.getPageContext(List result) >>> > call. Current mindset is that thePageContext just (and only) belongs to the >>> > previous (executed) request... Not sure I want to support something like >>> > >>> > // first call: >>> > List<SomeType> first; >>> > myPipe.readWithFilter(.....) // set first inside of callback >>> > ... >>> > // second call: >>> > List<SomeType> second; >>> > myPipe.readWithFilter(.....) // set second inside of callback >>> > ... >>> > // third call: >>> > List<SomeType> third; >>> > myPipe.readWithFilter(.....) // set third inside of callback >>> > ... >>> > >>> > >>> > >>> > >>> > /// A BIT LATER ....: >>> > myPipe.getPageContext(first); >>> > >>> > >>> > I am not sure if that (myPipe.getPageContext(first);) is really desired >>> > (or would even easily work, as it would need to store the "metadata")..... >>> > >>> > >>> > Perhaps I am just wrong. >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > _______________________________________________ >>> > 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 <mailto:aerogear-dev@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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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

OK, so here is where I stand. I don't think there is any way to have the API's match identically between JS and the others. It sounds like Android and iOS are getting closer to agreement but as they get closer, it seems they get further away from what makes sense for JS. Basically, anything that involves creating a new object to maintain paged pipes rather than just using any other pipe and overloading the read method to do paging doesn't make sense to me. IMO, JS should move forward with basically what was written up in the strawman as that feels like the best solution for JS.

As we wrap the day one of API design discussions, what about summarize the API proposals with usage? JS/iOS/Android: 1) usage example, covering some mentioned usecases like changing the paging "midflight" - something really straight to the point (no fluff, just stuff) 2) API definition I think this will give the orthogonal view we need to come to a decision. kris: What about you providing a snippet of the API you hate too? just for comparison sake :P -- qmx

On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > As we wrap the day one of API design discussions, what about summarize the API proposals with usage? > > JS/iOS/Android: > > 1) usage example, covering some mentioned usecases like changing the paging "midflight" - something really straight to the point (no fluff, just stuff) OK, hopefully this can get us going on #1 https://gist.github.com/4541788 > > 2) API definition > > I think this will give the orthogonal view we need to come to a decision. > > kris: What about you providing a snippet of the API you hate too? just for comparison sake :P > > -- qmx > _______________________________________________ > 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

On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me <mailto:qmx@qmx.me>> wrote: > As we wrap the day one of API design discussions, what about > summarize the API proposals with usage? > > JS/iOS/Android: > > 1) usage example, covering some mentioned usecases like changing the > paging "midflight" - something really straight to the point (no > fluff, just stuff) OK, hopefully this can get us going on #1 https://gist.github.com/4541788

> > 2) API definition > > I think this will give the orthogonal view we need to come to a decision. > > kris: What about you providing a snippet of the API you hate too? > just for comparison sake :P > > -- qmx > _______________________________________________ > 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

On 15/01/2013, at 20:25, Summers Pittman <supittma(a)redhat.com&gt; wrote: > I've forked and added mine (Android proposal sans blocking methods) > https://gist.github.com/4542125 > > I went for pedantic in a couple of examples… The pedantic part is making this code unreadable - can you get rid of all the latches and atomic stuff? (no fluff, just stuff)

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/15/2013 02:51 PM, Douglas Campos wrote: As we wrap the day one of API design discussions, what about summarize the API proposals with usage? JS/iOS/Android: 1) usage example, covering some mentioned usecases like changing the paging "midflight" - something really straight to the point (no fluff, just stuff) I forked Kris's gist and added android stuff using my proposal (sans blocking methods) https://gist.github.com/4542125 I went for pedantic in a couple of examples... 2) API definition I think this will give the orthogonal view we need to come to a decision. kris: What about you providing a snippet of the API you hate too? just for comparison sake :P -- qmx _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

Hello, a few quick/simple q's: JavaScript One question on the two gists... Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist uses pipe.read(page:"next") for the JS. I think I do like the 'plain' read overload in JS... - but having a more explicit next() (and others) is not that bad; but (currently) my vote would be pipe.read(page:"prev"...... Oh... What happens when I have a regular pipe, object (where the paged setting is NOT specified on its ctor), and I invoke pipe.read(page:"next") ? I hope it does not issue a JS/type error :-) but I'd expect to have a straight read of ALL the "objects" (or "entities")... Android You have the following: cars.readWithFilter(filter, new Callback<Car>() { @Override void onSuccess(List<Car> data) { firstPage = data; } @Override void onError(Exception ex) { //handle error } }); firstPage.next(.......); I am wondering what is the fristPage here (since the data on the onSuccess has been assigned to it) Change Offset and Limit I like both (JS and Android) :) The Android solution is similar to what I had in mind for iOS... I will update the comparison gist soon ! -Matthias On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > > On 01/15/2013 02:51 PM, Douglas Campos wrote: > > As we wrap the day one of API design discussions, what about summarize the > API proposals with usage? > > JS/iOS/Android: > > 1) usage example, covering some mentioned usecases like changing the > paging "midflight" - something really straight to the point (no fluff, just > stuff) > > I forked Kris's gist and added android stuff using my proposal (sans > blocking methods) > https://gist.github.com/4542125 > > I went for pedantic in a couple of examples... > > > 2) API definition > > I think this will give the orthogonal view we need to come to a decision. > > kris: What about you providing a snippet of the API you hate too? just for > comparison sake :P > > -- qmx > _______________________________________________ > 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

a "action" attribute inside a "paging" block ? If paging block isn't present we implicitly know we don't want paging : cars.read({ paging: { action: "prev", //can be "next" offset: 2, //optional limit: 10 //optional }, success: function( data ) { // do something }, error: function() { // handle it }});

*General remark * Do we want to describe in the specs the following use cases ? - Calling previous on the first page - Calling next on the last page - Setting an offset > total number of pages

On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Howdy! > > I have forked the gist and added the (current) iOS proposal to it: > https://gist.github.com/4546737 > > -M > > On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hello, > > > > a few quick/simple q's: > > > > JavaScript > > > > One question on the two gists... > > > > Kris' gist uses pipe.next() of scrolling forward, Summer's comparison > gist > > uses pipe.read(page:"next") for the JS. > > > > I think I do like the 'plain' read overload in JS... - but having a more > > explicit next() (and others) is not that bad; but (currently) my vote > would > > be pipe.read(page:"prev"...... > > > > Oh... What happens when I have a regular pipe, object (where the paged > > setting is NOT specified on its ctor), and I invoke > pipe.read(page:"next") ? > > I hope it does not issue a JS/type error :-) but I'd expect to have a > > straight read of ALL the "objects" (or "entities")... > > > > Android > > > > You have the following: > > > > cars.readWithFilter(filter, new Callback<Car>() { > > @Override > > void onSuccess(List<Car> data) { > > firstPage = data; > > } > > > > @Override > > void onError(Exception ex) { > > //handle error > > } > > }); > > > > > > firstPage.next(.......); > > > > I am wondering what is the fristPage here (since the data on the > onSuccess > > has been assigned to it) > > > > Change Offset and Limit > > > > I like both (JS and Android) :) The Android solution is similar to what > I > > had in mind for iOS... > > > > I will update the comparison gist soon ! > > > > -Matthias > > > > > > > > > > > > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com&gt; > > wrote: > >> > >> On 01/15/2013 02:51 PM, Douglas Campos wrote: > >> > >> As we wrap the day one of API design discussions, what about summarize > the > >> API proposals with usage? > >> > >> JS/iOS/Android: > >> > >> 1) usage example, covering some mentioned usecases like changing the > >> paging "midflight" - something really straight to the point (no fluff, > just > >> stuff) > >> > >> I forked Kris's gist and added android stuff using my proposal (sans > >> blocking methods) > >> https://gist.github.com/4542125 > >> > >> I went for pedantic in a couple of examples... > >> > >> > >> 2) API definition > >> > >> I think this will give the orthogonal view we need to come to a > decision. > >> > >> kris: What about you providing a snippet of the API you hate too? just > for > >> comparison sake :P > >> > >> -- qmx > >> _______________________________________________ > >> 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 > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Another alternative : What about removing the "page" attribute and include > a "action" attribute inside a "paging" block ? If paging block isn't > present we implicitly know we don't want paging : > > cars.read({ > paging: { > action: "prev", //can be "next" > offset: 2, //optional > limit: 10 //optional > > }, > success: function( data ) { > // do something > }, > error: function() { > // handle it > }}); > > > But the 'updatePageConfig' would be still around ? If I "touch" (update) the limit/offset, it is globally stored, and reused, right ? I always have to provide a paging block, at least like this, right ? ==> cars.read({ paging: { action: "prev", //can be "next" },...........; BTW. action sounds Struts :) > *General remark * > Do we want to describe in the specs the following use cases ? > > - Calling previous on the first page > - Calling next on the last page > - Setting an offset > total number of pages > yeah - would be (more than) nice if that behavior is specified…. +1 Anyone want to start putting together a specs doc?

> > > On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> Howdy! >> >> I have forked the gist and added the (current) iOS proposal to it: >> https://gist.github.com/4546737 >> >> -M >> >> On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> > Hello, >> > >> > a few quick/simple q's: >> > >> > JavaScript >> > >> > One question on the two gists... >> > >> > Kris' gist uses pipe.next() of scrolling forward, Summer's comparison >> gist >> > uses pipe.read(page:"next") for the JS. >> > >> > I think I do like the 'plain' read overload in JS... - but having a >> more >> > explicit next() (and others) is not that bad; but (currently) my vote >> would >> > be pipe.read(page:"prev"...... >> > >> > Oh... What happens when I have a regular pipe, object (where the paged >> > setting is NOT specified on its ctor), and I invoke >> pipe.read(page:"next") ? >> > I hope it does not issue a JS/type error :-) but I'd expect to have a >> > straight read of ALL the "objects" (or "entities")... >> > >> > Android >> > >> > You have the following: >> > >> > cars.readWithFilter(filter, new Callback<Car>() { >> > @Override >> > void onSuccess(List<Car> data) { >> > firstPage = data; >> > } >> > >> > @Override >> > void onError(Exception ex) { >> > //handle error >> > } >> > }); >> > >> > >> > firstPage.next(.......); >> > >> > I am wondering what is the fristPage here (since the data on the >> onSuccess >> > has been assigned to it) >> > >> > Change Offset and Limit >> > >> > I like both (JS and Android) :) The Android solution is similar to >> what I >> > had in mind for iOS... >> > >> > I will update the comparison gist soon ! >> > >> > -Matthias >> > >> > >> > >> > >> > >> > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com >> > >> > wrote: >> >> >> >> On 01/15/2013 02:51 PM, Douglas Campos wrote: >> >> >> >> As we wrap the day one of API design discussions, what about >> summarize the >> >> API proposals with usage? >> >> >> >> JS/iOS/Android: >> >> >> >> 1) usage example, covering some mentioned usecases like changing the >> >> paging "midflight" - something really straight to the point (no >> fluff, just >> >> stuff) >> >> >> >> I forked Kris's gist and added android stuff using my proposal (sans >> >> blocking methods) >> >> https://gist.github.com/4542125 >> >> >> >> I went for pedantic in a couple of examples... >> >> >> >> >> >> 2) API definition >> >> >> >> I think this will give the orthogonal view we need to come to a >> decision. >> >> >> >> kris: What about you providing a snippet of the API you hate too? >> just for >> >> comparison sake :P >> >> >> >> -- qmx >> >> _______________________________________________ >> >> 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 >> >> >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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 > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf___________________________________________... 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

I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both. For offset > totalNbPages : - throwing an exception ? - returning null ? - returning last page ? I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception.

If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we need to interrupt the app workflow, because the data doesn't exist.

-- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote: > > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto:kris@redhat.com)> wrote: >> I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both. >> >>> >>> For offset > totalNbPages : >>> - throwing an exception ? >>> - returning null ? >>> - returning last page ? >> >> >> >> I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception. > > > +1 on an exception > > -M > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we need to interrupt the app workflow, because the data doesn't exist. I would prefer that an exception is thrown client side before a request is ever sent to the server. That way we save the http request which is important on mobile. Ah! yeah - good point -> since the "paging API" knows there is no "next" (for instance) That being said, then the issue becomes what if that page does exist but we don't allow the request because the data was updated since our last read? Then we wouldn't know without another read happening. yeah - here could the 2.x targeted feature of 'sync' come in…

Hmmm, interested in other opinions since relying on a 204 or any status from the server couples the client to the server impl but if we don't allow the request, that could also cause issues. true :) > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote: > >> >> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto:kris@redhat.com)> wrote: >>> I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both. >>> >>>> >>>> For offset > totalNbPages : >>>> - throwing an exception ? >>>> - returning null ? >>>> - returning last page ? >>> >>> >>> >>> I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception. >> >> >> +1 on an exception >> >> -M >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > "sync" is probably going to be the option here but , > what about a setting to say don't go to the server if there is no next/prev, > defaults to always "refresh" > > If they are using our data manager stuff also, the paging could be based > off that, probably a whole other discussion(offline?). I guess i'm > thinking of an app where the data doesn't change often and the user gets it > all up front first. I don't see this being part of 1.0.0. BUT the general paging APIs (e.g. 'next', previous etc) would work on a data store as well, right ?

-M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jan 17, 2013, at 8:41 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> "sync" is probably going to be the option here but , >> what about a setting to say don't go to the server if there is no next/prev, >> defaults to always "refresh" >> >> If they are using our data manager stuff also, the paging could be based >> off that, probably a whole other discussion(offline?). I guess i'm >> thinking of an app where the data doesn't change often and the user gets it >> all up front first. > > > I don't see this being part of 1.0.0. BUT the general paging APIs > (e.g. 'next', previous etc) would work on a data store as well, right > ? This will have to be a bigger discussion as keeping things in a particular order in conjunction with things like localStorage or JS objects in general is not trivial.

> > -M > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we need to interrupt the app workflow, because the data doesn't exist. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote: > > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto: kris(a)redhat.com)&gt; wrote: > > I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both. > > > > > > > > For offset > totalNbPages : > > > - throwing an exception ? > > > - returning null ? > > > - returning last page ? > > > > > > > > I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception. > > > +1 on an exception > > -M > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

I agreed on not interrupt the workflow (although if exception are meant to be handelt in order to maintain the flow under some conditions). HTTP 204 is a good option but is maybe more an impl details ? Because, in the future, when we will have offline/native paging, http status won't make a lot of sense, no ?

On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > If the data doesn't exist HTTP 204 is a good fit. Just don't understand > why we need to interrupt the app workflow, because the data doesn't exist. > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote: > > > > > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com(mailto: > kris(a)redhat.com)&gt; wrote: > > > I would say returning the current page would be confusing. I would be > fine with an exception or returning null as both can be handled pretty > easily by a dev. I would say an exception may be more useful since it will > tell the dev exactly what was wrong instead of their app choking in a null > return but I am open to both. > > > > > > > > > > > For offset > totalNbPages : > > > > - throwing an exception ? > > > > - returning null ? > > > > - returning last page ? > > > > > > > > > > > > I would say same as above. Returning last page may be confusing but > others are acceptable with a preference toward an exception. > > > > > > +1 on an exception > > > > -M > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > 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 https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org (mailto:bruno@abstractj.org)> wrote: > If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we need to interrupt the app workflow, because the data doesn't exist. Interesting idea, but I am not sure… if we want to "expose" the 204… since the idea of a pipe was/is to encapsulate some of the underlying bits. > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote: > > > > > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto:kris@redhat.com) (mailto:kris@redhat.com)> wrote: > > > I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both. > > > > > > > > > > > For offset > totalNbPages : > > > > - throwing an exception ? > > > > - returning null ? > > > > - returning last page ? > > > > > > > > > > > > > > > I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception. > > > > > > +1 on an exception > > > > -M > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@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 (mailto:aerogear-dev@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(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev

But this way the application won't know there is something amiss until the http request returns which could be a long time.

good point! I think we forgot about that. nice catch ! On Wed, Jan 16, 2013 at 4:23 PM, Bruno Oliveira <bruno@abstractj.org<javascript:_e({}, 'cvml', &#39;bruno(a)abstractj.org&#39;);&gt; > wrote: > Good point Summers. Might be an obvious question, but there we go. Are we > planning to include timeout as parameter? For example: I want to retrieve a > list of a bazilion users, and I want to specify the timeout acceptable to > wait. > > I didn't get the chance to look at each API, just double checking here. > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 16, 2013 at 1:11 PM, Summers Pittman wrote: > > > But this way the application won't know there is something amiss until > > the http request returns which could be a long time. > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <javascript:_e({}, 'cvml', > &#39;aerogear-dev(a)lists.jboss.org&#39;);&gt; > 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

On 01/16/2013 10:23 AM, Bruno Oliveira wrote: > Good point Summers. Might be an obvious question, but there we go. Are we planning to include timeout as parameter? For example: I want to retrieve a list of a bazilion users, and I want to specify the timeout acceptable to wait. > > I didn't get the chance to look at each API, just double checking here. > +1 I was thinking about this yesterday. I want to but was hoping we could get the "shape" of the API nailed down first before we started hammering on specifics. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

pipe level. POST can timeout too ;-)

On Wednesday, January 16, 2013, Sebastien Blanc wrote: the timeout parameter would be a general property of read() and not related to Paging ? On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com <javascript:_e({}, 'cvml', &#39;supittma(a)redhat.com&#39;);&gt;&gt; wrote: On 01/16/2013 10:23 AM, Bruno Oliveira wrote: > Good point Summers. Might be an obvious question, but there we go. Are we planning to include timeout as parameter? For example: I want to retrieve a list of a bazilion users, and I want to specify the timeout acceptable to wait. > > I didn't get the chance to look at each API, just double checking here. > +1 I was thinking about this yesterday. I want to but was hoping we could get the "shape" of the API nailed down first before we started hammering on specifics. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <javascript:_e({}, 'cvml', &#39;aerogear-dev(a)lists.jboss.org&#39;);&gt; https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Sent from Gmail Mobile _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

But maybe we don't want the same timeout for a GET than for a POST ?

On Wed, Jan 16, 2013 at 4:30 PM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: pipe level. POST can timeout too ;-) On Wednesday, January 16, 2013, Sebastien Blanc wrote: the timeout parameter would be a general property of read() and not related to Paging ? On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: On 01/16/2013 10:23 AM, Bruno Oliveira wrote: > Good point Summers. Might be an obvious question, but there we go. Are we planning to include timeout as parameter? For example: I want to retrieve a list of a bazilion users, and I want to specify the timeout acceptable to wait. > > I didn't get the chance to look at each API, just double checking here. > +1 I was thinking about this yesterday. I want to but was hoping we could get the "shape" of the API nailed down first before we started hammering on specifics. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Sent from Gmail Mobile _______________________________________________ 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

But maybe we don't want the same timeout for a GET than for a POST ?

I tweaked the iOS API a bit more: https://gist.github.com/cbff741b3b21a50c3b67

I also updated the "comparison" gist: https://gist.github.com/4546737 Feedback welcome.... On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > the timeout parameter would be a general property of read() and not related > to Paging ? > > > On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com&gt; > wrote: >> On 01/16/2013 10:23 AM, Bruno Oliveira wrote: >>> Good point Summers. Might be an obvious question, but there we go. Are >>> we planning to include timeout as parameter? For example: I want to retrieve >>> a list of a bazilion users, and I want to specify the timeout acceptable to >>> wait. >>> >>> I didn't get the chance to look at each API, just double checking here. >>> >> +1 >> >> I was thinking about this yesterday. I want to but was hoping we could >> get the "shape" of the API nailed down first before we started hammering >> on specifics. >> _______________________________________________ >> 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 >

Maybe this is a server implementation thing or maybe a non-issue and I'm just being dense but how would I get the last page as soon as my app loads without doing two read() requests? I can get the first page by just adding a firstPage (just and example name) config param to my paged pipe but I have no idea what the last page would be at that point. Thoughts?

On the one hand, -1 is often used for the last element in many APIs.

On the other hand, to qmx's point, What happens if we are paging digits of PI?

On 01/16/2013 12:44 PM, Matthias Wessendorf wrote: > I tweaked the iOS API a bit more: > https://gist.github.com/cbff741b3b21a50c3b67 Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like encoding or authentication) instead of a request level thing? I don't imagine it changing during the lifetime of a Pipe? Otherwise looks really good! > I also updated the "comparison" gist: > https://gist.github.com/4546737 > > Feedback welcome.... > > On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> the timeout parameter would be a general property of read() and not related >> to Paging ? >> >> >> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com&gt; >> wrote: >>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote: >>>> Good point Summers. Might be an obvious question, but there we go. Are >>>> we planning to include timeout as parameter? For example: I want to retrieve >>>> a list of a bazilion users, and I want to specify the timeout acceptable to >>>> wait. >>>> >>>> I didn't get the chance to look at each API, just double checking here. >>>> >>> +1 >>> >>> I was thinking about this yesterday. I want to but was hoping we could >>> get the "shape" of the API nailed down first before we started hammering >>> on specifics. >>> _______________________________________________ >>> 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

On 01/16/2013 10:23 AM, Bruno Oliveira wrote: > Good point Summers. Might be an obvious question, but there we go. Are we planning to include timeout as parameter? For example: I want to retrieve a list of a bazilion users, and I want to specify the timeout acceptable to wait. > > I didn't get the chance to look at each API, just double checking here. > +1 I was thinking about this yesterday. I want to but was hoping we could get the "shape" of the API nailed down first before we started hammering on specifics.

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com <mailto:kris@redhat.com>> wrote: On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > Another alternative : What about removing the "page" > attribute and include a "action" attribute inside a "paging" > block ? If paging block isn't present we implicitly know we > don't want paging : > > cars.read({ > paging: { > action: "prev", //can be "next" > offset: 2, //optional > limit: 10 //optional > }, success: function( data ) { // do something }, error: > function() { // handle it } }); > > > > > But the 'updatePageConfig' would be still around ? > > If I "touch" (update) the limit/offset, it is globally stored, > and reused, right ? > > I always have to provide a paging block, at least like this, right ? > ==> cars.read({ > paging: { > action: "prev", //can be "next" > },...........; > > > BTW. action sounds Struts :) > > > *General remark * > Do we want to describe in the specs the following use cases ? > > - Calling previous on the first page > - Calling next on the last page > - Setting an offset > total number of pages > > > > yeah - would be (more than) nice if that behavior is specified.... +1 Anyone want to start putting together a specs doc? Before starting the specs doc, let's first discuss here what for behaviour we want for these specific use cases : When prev / next does not exist : - throwing an exception ?

- returning null ?

- returning the current page ?

For offset > totalNbPages : - throwing an exception ?

- returning null ?

- returning last page ?

> > > > On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > Howdy! > > I have forked the gist and added the (current) iOS > proposal to it: > https://gist.github.com/4546737 > > -M > > On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > Hello, > > > > a few quick/simple q's: > > > > JavaScript > > > > One question on the two gists... > > > > Kris' gist uses pipe.next() of scrolling forward, > Summer's comparison gist > > uses pipe.read(page:"next") for the JS. > > > > I think I do like the 'plain' read overload in JS... - > but having a more > > explicit next() (and others) is not that bad; but > (currently) my vote would > > be pipe.read(page:"prev"...... > > > > Oh... What happens when I have a regular pipe, object > (where the paged > > setting is NOT specified on its ctor), and I invoke > pipe.read(page:"next") ? > > I hope it does not issue a JS/type error :-) but I'd > expect to have a > > straight read of ALL the "objects" (or "entities")... > > > > Android > > > > You have the following: > > > > cars.readWithFilter(filter, new Callback<Car>() { > > @Override > > void onSuccess(List<Car> data) { > > firstPage = data; > > } > > > > @Override > > void onError(Exception ex) { > > //handle error > > } > > }); > > > > > > firstPage.next(.......); > > > > I am wondering what is the fristPage here (since the > data on the onSuccess > > has been assigned to it) > > > > Change Offset and Limit > > > > I like both (JS and Android) :) The Android solution is > similar to what I > > had in mind for iOS... > > > > I will update the comparison gist soon ! > > > > -Matthias > > > > > > > > > > > > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> > > wrote: > >> > >> On 01/15/2013 02:51 PM, Douglas Campos wrote: > >> > >> As we wrap the day one of API design discussions, what > about summarize the > >> API proposals with usage? > >> > >> JS/iOS/Android: > >> > >> 1) usage example, covering some mentioned usecases > like changing the > >> paging "midflight" - something really straight to the > point (no fluff, just > >> stuff) > >> > >> I forked Kris's gist and added android stuff using my > proposal (sans > >> blocking methods) > >> https://gist.github.com/4542125 > >> > >> I went for pedantic in a couple of examples... > >> > >> > >> 2) API definition > >> > >> I think this will give the orthogonal view we need to > come to a decision. > >> > >> kris: What about you providing a snippet of the API > you hate too? just for > >> comparison sake :P > >> > >> -- qmx > >> _______________________________________________ > >> 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 > <mailto:aerogear-dev@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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 > <mailto:aerogear-dev@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(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 <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

Hello, a few quick/simple q's: JavaScript One question on the two gists... Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist uses pipe.read(page:"next") for the JS.

I think I do like the 'plain' read overload in JS... - but having a more explicit next() (and others) is not that bad; but (currently) my vote would be pipe.read(page:"prev"......

Oh... What happens when I have a regular pipe, object (where the paged setting is NOT specified on its ctor), and I invoke pipe.read(page:"next") ? I hope it does not issue a JS/type error :-) but I'd expect to have a straight read of ALL the "objects" (or "entities")...

Android You have the following: cars.readWithFilter(filter, new Callback<Car>() { @Override void onSuccess(List<Car> data) { firstPage = data; } @Override void onError(Exception ex) { //handle error } }); firstPage.next(.......); I am wondering what is the fristPage here (since the data on the onSuccess has been assigned to it) Change Offset and Limit I like both (JS and Android) :) The Android solution is similar to what I had in mind for iOS... I will update the comparison gist soon ! -Matthias On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: On 01/15/2013 02:51 PM, Douglas Campos wrote: > As we wrap the day one of API design discussions, what about summarize the API proposals with usage? > > JS/iOS/Android: > > 1) usage example, covering some mentioned usecases like changing the paging "midflight" - something really straight to the point (no fluff, just stuff) I forked Kris's gist and added android stuff using my proposal (sans blocking methods) https://gist.github.com/4542125 I went for pedantic in a couple of examples... > 2) API definition > > I think this will give the orthogonal view we need to come to a decision. > > kris: What about you providing a snippet of the API you hate too? just for comparison sake :P > > -- qmx > _______________________________________________ > 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

firstPage is a field with a type of PagedList

On Wed, Jan 16, 2013 at 4:41 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: firstPage is a field with a type of PagedList Did you 'gist' that API as well ?

-M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Basically, anything that involves creating a new object to maintain paged pipes rather than just using any other pipe and overloading the read method to do paging doesn't make sense to me.

OK, so here is where I stand. I don't think there is any way to have the API's match identically between JS and the others. It sounds like Android and iOS are getting closer to agreement but as they get closer, it seems they get further away from what makes sense for JS. Basically, anything that involves creating a new object to maintain paged pipes rather than just using any other pipe and overloading the read method to do paging doesn't make sense to me. IMO, JS should move forward with basically what was written up in the strawman as that feels like the best solution for JS. On Jan 15, 2013, at 10:18 AM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > On 01/15/2013 08:45 AM, Sebastien Blanc wrote: >> Just to summarize what have until now : >> >> 1. Kris's proposition: https://gist.github.com/4531575 >> >> 2. Summers's proposition: https://gist.github.com/4532661 >> >> 3. qmx's propositon: https://gist.github.com/4538709 >> >> 4. Sebi's propositionhttps://gist.github.com/4538725 >> >> > I've just updated my proposition. PageContext is no longer and thing > and I've replaced it with a PagedList interface. >> >> >> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> > I was wondering, if the result should be received on every rquest, >> >> >> ideally on the callback..., to not block (at least in iOS land, I >> would pass that "result set" on to the "success" block) >> >> -M >> >> > >> > thx >> > >> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc >> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >> >> In the same spirit (inspired from >> >> >> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) >> >> : >> >> >> >> >> >> public interface PagedResult<T> { >> >> >> >> PagedResult<T> next(); >> >> >> >> PagedResult<T> prev(); >> >> >> >> PagedResult<T> withOffset(int offset); >> >> >> >> PagedResult<T> withLimit(int limit); >> >> >> >> List<T> result(); >> >> >> >> } >> >> >> >> >> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me >> <mailto:qmx@qmx.me>> wrote: >> >>> >> >>> I'm not a fan of those PageContext objects (remembers me of >> some wild-ass >> >>> ThreadLocals leaking all over) >> >>> >> >>> My proposal for the paging aware APIs would be something >> like this: >> >>> >> >>> public interface PagedResult<T> { >> >>> >> >>> List<T> next(); >> >>> >> >>> List<T> prev(); >> >>> >> >>> List<T> page(int offset, int limit); >> >>> >> >>> } >> >>> >> >>> and the Async counterpart >> >>> >> >>> public interface AsyncPagedResult<T> { >> >>> >> >>> void next(Callback<List<T>> callback); >> >>> >> >>> void prev(Callback<List<T>> callback); >> >>> >> >>> void page(int offset, int limit, Callback<List<T>> >> callback); >> >>> >> >>> public static interface Callback<U> { >> >>> public void onResult(U result); >> >>> } >> >>> } >> >>> >> >>> I don't like the idea of having a companion object for >> holding the >> >>> pagination state. >> >>> >> >>> Thoughts? >> >>> >> >>> -- qmx >> >>> >> >>> On 15/01/2013, at 08:37, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >>> >> >>> > Hi Summers, >> >>> > >> >>> > >> >>> > 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. >> >>> > >> >>> > >> >>> > from your Andorid gist: >> >>> > >> >>> > A) Once the response has been received, the Pipe >> implementation will >> >>> > return a List of objects. If this List instance is passed to >> >>> > Pipe.getPageContext the appropriate PageContext will be >> returned >> >>> > >> >>> > Note: There is no 'return' - the readWithFilter is void, >> instead a >> >>> > Callback is invoked (onSuccess(list)), see Pipe.java >> >>> > >> >>> > B) The developer will receive from readWithFilter() a List >> of object. If >> >>> > she passes this list into Pipe.getPageContext(List result) >> she will receive >> >>> > the PageContext associated with this result. >> >>> > >> >>> > Do you mean like: >> >>> > >> >>> > ... >> >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { >> >>> > >> >>> > >> >>> > @Override >> >>> > >> >>> > >> >>> > public void onSuccess(List<Data> data) { >> >>> > >> >>> > >> >>> > >> >>> > // get the PageContext: >> >>> > >> >>> > >> >>> > PageContext ctx = myPipe.getPageContext(data); >> >>> > >> >>> > >> >>> > ... >> >>> > >> >>> > >> >>> > } >> >>> > >> >>> > >> >>> > >> >>> > @Override >> >>> > >> >>> > >> >>> > public void onFailure(Exception e) { >> >>> > >> >>> > >> >>> > } >> >>> > }); >> >>> > Not sure about that..... >> >>> > >> >>> > But for iOS I am thinking about passing in the PageContext >> into the >> >>> > closure/block of the readWithFilter, like: >> >>> > >> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> >> config)) config >> >>> > >> >>> > >> >>> > success:(void (^)(id listOfObjects, id pageContext))success >> >>> > >> >>> > >> >>> > failure:(void (^)(NSError *error))failure; >> >>> > A usage would look like: >> >>> > >> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { >> >>> > >> >>> > >> >>> > // set the filter args and override the given defaults >> >>> > >> >>> > >> >>> > } success:^(id listOfObjects, id pageContext) { >> >>> > >> >>> > >> >>> > // work with the listOfObjects reponse. >> >>> > >> >>> > >> >>> > // for paging/query info, access the given pagecontext, >> >>> > >> >>> > >> >>> > // of the CURRENT request >> >>> > >> >>> > >> >>> > ... >> >>> > >> >>> > >> >>> > } failure:^(NSError *error) { >> >>> > >> >>> > >> >>> > // handle errorz >> >>> > >> >>> > >> >>> > }]; >> >>> > Any thoughts ? >> >>> > >> >>> > Not sure I like (or understand) the >> Pipe.getPageContext(List result) >> >>> > call. Current mindset is that thePageContext just (and >> only) belongs to the >> >>> > previous (executed) request... Not sure I want to support >> something like >> >>> > >> >>> > // first call: >> >>> > List<SomeType> first; >> >>> > myPipe.readWithFilter(.....) // set first inside of callback >> >>> > ... >> >>> > // second call: >> >>> > List<SomeType> second; >> >>> > myPipe.readWithFilter(.....) // set second inside of callback >> >>> > ... >> >>> > // third call: >> >>> > List<SomeType> third; >> >>> > myPipe.readWithFilter(.....) // set third inside of callback >> >>> > ... >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > /// A BIT LATER ....: >> >>> > myPipe.getPageContext(first); >> >>> > >> >>> > >> >>> > I am not sure if that (myPipe.getPageContext(first);) is >> really desired >> >>> > (or would even easily work, as it would need to store the >> "metadata")..... >> >>> > >> >>> > >> >>> > Perhaps I am just wrong. >> >>> > >> >>> > >> >>> > -- >> >>> > Matthias Wessendorf >> >>> > >> >>> > blog: http://matthiaswessendorf.wordpress.com/ >> >>> > sessions: http://www.slideshare.net/mwessendorf >> >>> > twitter: http://twitter.com/mwessendorf >> >>> > _______________________________________________ >> >>> > 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 >> <mailto:aerogear-dev@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 >> >> >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> 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

> Basically, anything that involves creating a new object to maintain paged pipes rather than just using any other pipe and overloading the read method to do paging doesn't make sense to me. I'm confused. Your strawman creates extra pipes to maintain paged states. The other proposals all use an overridden read method and return a list which can be used to fetch different pages of data (which is what it sounds like you want).

On 01/15/2013 08:45 AM, Sebastien Blanc wrote: > Just to summarize what have until now : > > 1. Kris's proposition: https://gist.github.com/4531575 > > 2. Summers's proposition: https://gist.github.com/4532661 > > 3. qmx's propositon: https://gist.github.com/4538709 > > 4. Sebi's propositionhttps://gist.github.com/4538725 > > I've just updated my proposition. PageContext is no longer and thing and I've replaced it with a PagedList interface. > > > On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > I was wondering, if the result should be received on every rquest, > > > ideally on the callback..., to not block (at least in iOS land, I > would pass that "result set" on to the "success" block) > > -M > > > > > thx > > > > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc > <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: > >> In the same spirit (inspired from > >> > http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) > >> : > >> > >> > >> public interface PagedResult<T> { > >> > >> PagedResult<T> next(); > >> > >> PagedResult<T> prev(); > >> > >> PagedResult<T> withOffset(int offset); > >> > >> PagedResult<T> withLimit(int limit); > >> > >> List<T> result(); > >> > >> } > >> > >> > >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me > <mailto:qmx@qmx.me>> wrote: > >>> > >>> I'm not a fan of those PageContext objects (remembers me of > some wild-ass > >>> ThreadLocals leaking all over) > >>> > >>> My proposal for the paging aware APIs would be something like > this: > >>> > >>> public interface PagedResult<T> { > >>> > >>> List<T> next(); > >>> > >>> List<T> prev(); > >>> > >>> List<T> page(int offset, int limit); > >>> > >>> } > >>> > >>> and the Async counterpart > >>> > >>> public interface AsyncPagedResult<T> { > >>> > >>> void next(Callback<List<T>> callback); > >>> > >>> void prev(Callback<List<T>> callback); > >>> > >>> void page(int offset, int limit, Callback<List<T>> callback); > >>> > >>> public static interface Callback<U> { > >>> public void onResult(U result); > >>> } > >>> } > >>> > >>> I don't like the idea of having a companion object for > holding the > >>> pagination state. > >>> > >>> Thoughts? > >>> > >>> -- qmx > >>> > >>> On 15/01/2013, at 08:37, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > >>> > >>> > Hi Summers, > >>> > > >>> > > >>> > 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. > >>> > > >>> > > >>> > from your Andorid gist: > >>> > > >>> > A) Once the response has been received, the Pipe > implementation will > >>> > return a List of objects. If this List instance is passed to > >>> > Pipe.getPageContext the appropriate PageContext will be > returned > >>> > > >>> > Note: There is no 'return' - the readWithFilter is void, > instead a > >>> > Callback is invoked (onSuccess(list)), see Pipe.java > >>> > > >>> > B) The developer will receive from readWithFilter() a List > of object. If > >>> > she passes this list into Pipe.getPageContext(List result) > she will receive > >>> > the PageContext associated with this result. > >>> > > >>> > Do you mean like: > >>> > > >>> > ... > >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { > >>> > > >>> > > >>> > @Override > >>> > > >>> > > >>> > public void onSuccess(List<Data> data) { > >>> > > >>> > > >>> > > >>> > // get the PageContext: > >>> > > >>> > > >>> > PageContext ctx = myPipe.getPageContext(data); > >>> > > >>> > > >>> > ... > >>> > > >>> > > >>> > } > >>> > > >>> > > >>> > > >>> > @Override > >>> > > >>> > > >>> > public void onFailure(Exception e) { > >>> > > >>> > > >>> > } > >>> > }); > >>> > Not sure about that..... > >>> > > >>> > But for iOS I am thinking about passing in the PageContext > into the > >>> > closure/block of the readWithFilter, like: > >>> > > >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> > config)) config > >>> > > >>> > > >>> > success:(void (^)(id listOfObjects, id pageContext))success > >>> > > >>> > > >>> > failure:(void (^)(NSError *error))failure; > >>> > A usage would look like: > >>> > > >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { > >>> > > >>> > > >>> > // set the filter args and override the given defaults > >>> > > >>> > > >>> > } success:^(id listOfObjects, id pageContext) { > >>> > > >>> > > >>> > // work with the listOfObjects reponse. > >>> > > >>> > > >>> > // for paging/query info, access the given pagecontext, > >>> > > >>> > > >>> > // of the CURRENT request > >>> > > >>> > > >>> > ... > >>> > > >>> > > >>> > } failure:^(NSError *error) { > >>> > > >>> > > >>> > // handle errorz > >>> > > >>> > > >>> > }]; > >>> > Any thoughts ? > >>> > > >>> > Not sure I like (or understand) the > Pipe.getPageContext(List result) > >>> > call. Current mindset is that thePageContext just (and > only) belongs to the > >>> > previous (executed) request... Not sure I want to support > something like > >>> > > >>> > // first call: > >>> > List<SomeType> first; > >>> > myPipe.readWithFilter(.....) // set first inside of callback > >>> > ... > >>> > // second call: > >>> > List<SomeType> second; > >>> > myPipe.readWithFilter(.....) // set second inside of callback > >>> > ... > >>> > // third call: > >>> > List<SomeType> third; > >>> > myPipe.readWithFilter(.....) // set third inside of callback > >>> > ... > >>> > > >>> > > >>> > > >>> > > >>> > /// A BIT LATER ....: > >>> > myPipe.getPageContext(first); > >>> > > >>> > > >>> > I am not sure if that (myPipe.getPageContext(first);) is > really desired > >>> > (or would even easily work, as it would need to store the > "metadata")..... > >>> > > >>> > > >>> > Perhaps I am just wrong. > >>> > > >>> > > >>> > -- > >>> > Matthias Wessendorf > >>> > > >>> > blog: http://matthiaswessendorf.wordpress.com/ > >>> > sessions: http://www.slideshare.net/mwessendorf > >>> > twitter: http://twitter.com/mwessendorf > >>> > _______________________________________________ > >>> > 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 > <mailto:aerogear-dev@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 > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'm thinking about dropping the blocking next(), prev(), etc. methods from the proposal and only keeping the callback driven methods.

WDYT? On 01/15/2013 11:18 AM, Summers Pittman wrote: On 01/15/2013 08:45 AM, Sebastien Blanc wrote: Just to summarize what have until now : 1. Kris's proposition: https://gist.github.com/4531575 2. Summers's proposition: https://gist.github.com/4532661 3. qmx's propositon: https://gist.github.com/4538709 4. Sebi's propositionhttps://gist.github.com/4538725 I've just updated my proposition. PageContext is no longer and thing and I've replaced it with a PagedList interface. On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > I was wondering, if the result should be received on every rquest, > > > ideally on the callback..., to not block (at least in iOS land, I > would pass that "result set" on to the "success" block) > > -M > > > > > thx > > > > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > > wrote: > >> In the same spirit (inspired from > >> > >> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...) > >> : > >> > >> > >> public interface PagedResult<T> { > >> > >> PagedResult<T> next(); > >> > >> PagedResult<T> prev(); > >> > >> PagedResult<T> withOffset(int offset); > >> > >> PagedResult<T> withLimit(int limit); > >> > >> List<T> result(); > >> > >> } > >> > >> > >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >>> > >>> I'm not a fan of those PageContext objects (remembers me of some > >>> wild-ass > >>> ThreadLocals leaking all over) > >>> > >>> My proposal for the paging aware APIs would be something like this: > >>> > >>> public interface PagedResult<T> { > >>> > >>> List<T> next(); > >>> > >>> List<T> prev(); > >>> > >>> List<T> page(int offset, int limit); > >>> > >>> } > >>> > >>> and the Async counterpart > >>> > >>> public interface AsyncPagedResult<T> { > >>> > >>> void next(Callback<List<T>> callback); > >>> > >>> void prev(Callback<List<T>> callback); > >>> > >>> void page(int offset, int limit, Callback<List<T>> callback); > >>> > >>> public static interface Callback<U> { > >>> public void onResult(U result); > >>> } > >>> } > >>> > >>> I don't like the idea of having a companion object for holding the > >>> pagination state. > >>> > >>> Thoughts? > >>> > >>> -- qmx > >>> > >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org&gt; > >>> wrote: > >>> > >>> > Hi Summers, > >>> > > >>> > > >>> > 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. > >>> > > >>> > > >>> > from your Andorid gist: > >>> > > >>> > A) Once the response has been received, the Pipe implementation will > >>> > return a List of objects. If this List instance is passed to > >>> > Pipe.getPageContext the appropriate PageContext will be returned > >>> > > >>> > Note: There is no 'return' - the readWithFilter is void, instead a > >>> > Callback is invoked (onSuccess(list)), see Pipe.java > >>> > > >>> > B) The developer will receive from readWithFilter() a List of > >>> > object. If > >>> > she passes this list into Pipe.getPageContext(List result) she will > >>> > receive > >>> > the PageContext associated with this result. > >>> > > >>> > Do you mean like: > >>> > > >>> > ... > >>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() { > >>> > > >>> > > >>> > @Override > >>> > > >>> > > >>> > public void onSuccess(List<Data> data) { > >>> > > >>> > > >>> > > >>> > // get the PageContext: > >>> > > >>> > > >>> > PageContext ctx = myPipe.getPageContext(data); > >>> > > >>> > > >>> > ... > >>> > > >>> > > >>> > } > >>> > > >>> > > >>> > > >>> > @Override > >>> > > >>> > > >>> > public void onFailure(Exception e) { > >>> > > >>> > > >>> > } > >>> > }); > >>> > Not sure about that..... > >>> > > >>> > But for iOS I am thinking about passing in the PageContext into the > >>> > closure/block of the readWithFilter, like: > >>> > > >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config > >>> > > >>> > > >>> > success:(void (^)(id listOfObjects, id pageContext))success > >>> > > >>> > > >>> > failure:(void (^)(NSError *error))failure; > >>> > A usage would look like: > >>> > > >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) { > >>> > > >>> > > >>> > // set the filter args and override the given defaults > >>> > > >>> > > >>> > } success:^(id listOfObjects, id pageContext) { > >>> > > >>> > > >>> > // work with the listOfObjects reponse. > >>> > > >>> > > >>> > // for paging/query info, access the given pagecontext, > >>> > > >>> > > >>> > // of the CURRENT request > >>> > > >>> > > >>> > ... > >>> > > >>> > > >>> > } failure:^(NSError *error) { > >>> > > >>> > > >>> > // handle errorz > >>> > > >>> > > >>> > }]; > >>> > Any thoughts ? > >>> > > >>> > Not sure I like (or understand) the Pipe.getPageContext(List result) > >>> > call. Current mindset is that thePageContext just (and only) belongs > >>> > to the > >>> > previous (executed) request... Not sure I want to support something > >>> > like > >>> > > >>> > // first call: > >>> > List<SomeType> first; > >>> > myPipe.readWithFilter(.....) // set first inside of callback > >>> > ... > >>> > // second call: > >>> > List<SomeType> second; > >>> > myPipe.readWithFilter(.....) // set second inside of callback > >>> > ... > >>> > // third call: > >>> > List<SomeType> third; > >>> > myPipe.readWithFilter(.....) // set third inside of callback > >>> > ... > >>> > > >>> > > >>> > > >>> > > >>> > /// A BIT LATER ....: > >>> > myPipe.getPageContext(first); > >>> > > >>> > > >>> > I am not sure if that (myPipe.getPageContext(first);) is really > >>> > desired > >>> > (or would even easily work, as it would need to store the > >>> > "metadata")..... > >>> > > >>> > > >>> > Perhaps I am just wrong. > >>> > > >>> > > >>> > -- > >>> > Matthias Wessendorf > >>> > > >>> > blog: http://matthiaswessendorf.wordpress.com/ > >>> > sessions: http://www.slideshare.net/mwessendorf > >>> > twitter: http://twitter.com/mwessendorf > >>> > _______________________________________________ > >>> > 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 > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

On 01/14/2013 02:27 PM, Kris Borchers wrote: On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com&gt; 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 listaerogear-dev@lists.jboss.orghttps://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.

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

On 14/01/2013, at 17:17, Summers Pittman <supittma(a)redhat.com&gt; wrote: > The biggest issue I see with a PagedPipe is it means a developer can't change his paging preferences without creating a new Pipe. why would I want to change paging mid-flight?

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> why would I want to change paging mid-flight? Contrived situation,

I am in the park reviewing JIRA bugs. I have chosen to only retrieve 5 at a time because I am on Sprint who has lousy data service. I walk into my coffee shop which has terrific WiFi and I now want to retreive 50 at a time because they will load before the heat death of the universe.

> Hmm, so you only create the pipes at app initialization? Looks like I was missing the android lifecycle. You can create one any time you like, but either a) each configuration would overwrite the old pipe in Pipeline or b) you would have obnoxious naming conventions.

As a less contrived example, you may have a background process updating cached data and a foreground process querying data. For instance your background thread was downloading all of the cars but you only want to see five red cards. It makes sense for Pipeline.get("car") to be used by both threads.

On 01/14/2013 04:26 PM, Douglas Campos wrote: > On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >>> Hmm, so you only create the pipes at app initialization? Looks like I was missing the android lifecycle. >> You can create one any time you like, but either a) each configuration >> would overwrite the old pipe in Pipeline or b) you would have obnoxious >> naming conventions. > I'm not following the naming conventions part, mind to elaborate? I suppose it just means you have to supply a name attribute to your PipeConfig. What this means is that the name of the pipe stops being the type of the pipe(which is our default) and starts being the role of the pipe (which is a rather new concept).

> >> As a less contrived example, you may have a background process updating >> cached data and a foreground process querying data. For instance your >> background thread was downloading all of the cars but you only want to >> see five red cards. It makes sense for Pipeline.get("car") to be used >> by both threads. > And this is the place where we disagree - I would go straight to make sure that background stuff have its own pipe instances ;) I've been trying to keep the pipe's methods threadsafe by minimizing mutable and shared state. (PageContext is an exception, but WeakHashMap explicitly uses the instance of the object for lookups and not the hash code). While I do this there is (as far as my biased POV can see) no good reason to have a single endpoint serviced by multiple RestAdapter instances. I would like to keep doing things this way, but if it really breaks the feel of a different language I can be flexible.

> > -- qmx > > > _______________________________________________ > 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

I've been trying to keep the pipe's methods threadsafe by minimizing mutable and shared state. (PageContext is an exception, but WeakHashMap explicitly uses the instance of the object for lookups and not the hash code).

On 14/01/2013, at 17:17, Summers Pittman <supittma(a)redhat.com&gt; wrote: > The biggest issue I see with a PagedPipe is it means a developer can't change his paging preferences without creating a new Pipe. why would I want to change paging mid-flight?

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev