>if we add a dependency on the params into our client library, we pretty much build against a "demo API". There should be no dependencies in the client APIs to these params or headers. This is up the the implementation of the target Route and the params names, the response headers could be anything they user wants. This is just an example where we try to provide a good way of doing this. At least this is my view of it. /Dan On 14 January 2013 10:28, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Looking at the PR for the demo ([1]) ,I am a bit surprised that classes like "Links.java" or "Metadata.java" are part of the demo code. I thought that the metadata/header informations on the response, like: ``` AG-Paging-Offset: 1 AG-Paging-Limit: 4 AG-Paging-Total: 4 AG-Links-First: cars?offset=0&limit=4 AG-Links-Previous: cars?offset=0&limit=4 AG-Links-Next: cars?offset=2&limit=4 AG-Links-Last: cars?offset=3&limit=4 ``` are applied by the framework. Of course, the "cars" in there is app specific, but this information could be read out of the actual route (/cars). Not sure, but... if all the time we (end user) needs to (re)impl. these things... it could be a bit annoying. IMO the problem would be: - if we add a dependency on the params into our client libraries, we pretty much build against a "demo API". Which is odd... I thought these "metadata details" are offered by the framework. -M [1] https://github.com/aerogear/aerogear-controller-demo/pull/19 On Sun, Jan 13, 2013 at 12:09 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > I've updated the demo and think I've included all the requests. > * Pre-populate the database upon deployment of demo. > * Use 'offset/limit' instead of 'page/perPage'. > * Use 'AG-' prefix for headers. > > Let me know if you are missing anything, or would like something done in a > different way. > > Use case > > The example is using /cars as the resource to interact with. > > The following route has been added to the demo: > > route() > .from("/cars") > .on(RequestMethod.GET) > .produces(MediaType.JSON) > .to(Cars.class).get(param("offset", "0"), param("limit", "-1")); > > From this we can see that there are two optional parameters, offset and > limit. If these are not specified all cars will be returned. > > Getting a page of Cars > > curl -i --header "Accept: application/json" > "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?offset=0&limit=4" > > The request will return: > > HTTP/1.1 200 OK > Content-Type: application/json;charset=UTF-8 > Content-Length: 160 > AG-Paging-Offset: 0 > AG-Paging-Limit: 4 > AG-Paging-Total: 4 > AG-Links-Next: cars?offset=1&limit=4 > AG-Links-Last: cars?offset=3&limit=4 > [ > {"color":"Green","brand":"Audi","id":1}, > {"color":"White","brand":"Audi","id":2}, > {"color":"Black","brand":"Audi","id":3}, > {"color":"Black","brand":"BMW","id":4} > ] > > Getting the next page of Cars > > To get the next page you can follow the next link: > > curl -i --header "Accept: application/json" > "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?offset=1&limit=4" > > HTTP/1.1 200 OK > Content-Type: application/json;charset=UTF-8 > Content-Length: 166 > AG-Paging-Offset: 1 > AG-Paging-Limit: 4 > AG-Paging-Total: 4 > AG-Links-First: cars?offset=0&limit=4 > AG-Links-Previous: cars?offset=0&limit=4 > AG-Links-Next: cars?offset=2&limit=4 > AG-Links-Last: cars?offset=3&limit=4 > [ > {"color":"Green","brand":"BMW","id":5}, > {"color":"Red","brand":"Ferrari","id":6}, > {"color":"White","brand":"Ferrari","id":7}, > {"color":"Pink","brand":"Ferrari","id":8} > ] > > Get all Cars > > curl -i --header "Accept: application/json" > "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars" > > This request will return: > > [ > {"color":"Green","brand":"Audi","id":1}, > {"color":"White","brand":"Audi","id":2}, > {"color":"Black","brand":"Audi","id":3}, > {"color":"Black","brand":"BMW","id":4}, > {"color":"Green","brand":"BMW","id":5}, > {"color":"Red","brand":"Ferrari","id":6}, > {"color":"White","brand":"Ferrari","id":7}, > {"color":"Pink","brand":"Ferrari","id":8}, > {"color":"White","brand":"Golf","id":15}, > {"color":"Brown","brand":"Lada","id":16}, > {"color":"Orange","brand":"Mazda","id":14}, > {"color":"Pink","brand":"Mini","id":13}, > {"color":"Gray","brand":"Nissan","id":11}, > {"color":"Yello","brand":"Opel","id":10}, > {"color":"Blue","brand":"Scoda","id":9}, > {"color":"Red","brand":"Volvo","id":12} > ] > > Get a single Car > > curl -i --header "Accept: application/json" > "http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars/1" > > The request will return: > > {"color":"Green","brand":"Audi","id":1} > > > > On 12 January 2013 11:08, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >> >> Great, lets go with 'AG-' prefix then. >> >> >> >> >> On 11 January 2013 18:24, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> >>> >>> On 11/01/2013, at 15:10, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> > I guess what I meant is I'm not specifically +1 for X- prefix but just >>> > some sort of prefix in general. It just makes it easier for devs when >>> > looking through headers to see what is being sent. Even something like AG- >>> > or AeroGear- would be better IMO than no prefix. >>> >>> d'oh, +1 - thought I've typed it… >>> >>> AG- looks nicer - less bandwidth ;) >>> >>> -- 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'm trying to find an easy way for doing this and wondering what people things about something like this: public OffsetPagedResponse findCarsByBrand(final String offsetParam, final String limitParam) { final int offset = Integer.valueOf(offsetParam); final int limit = Integer.valueOf(limitParam); final int total = getCarsTotal(); final List<Car> cars = getCars(offset, limit); return Pagination.offset(offset) .limit(limit) .total(total) .resourcePath("cars") .headersPrefix("Demo-") .response(cars); } On 14 January 2013 14:41, Douglas Campos <qmx(a)qmx.me&gt; wrote: > Well, from reading the PR I really think this should be part of the > controller - something that decorates the return and sets appropriate > headers. > > a very high level usage example would be something like this: > > public List<Car> findCarsByFoo(Car example) { > List<Car> cars = // does the magic > return paginate(cars); // static helper that wraps this list on a > lightweight wrapper, > // that triggers the behavior > } > > Thoughts? > > Matzew already put this on our meeting agenda for today, but feel free to > send suggestions here :) > > -- qmx > > On 14/01/2013, at 07:30, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; > wrote: > > > >if we add a dependency on the params into our client library, we > pretty much build against a "demo API". > > There should be no dependencies in the client APIs to these params or > headers. This is up the the implementation of the target Route and the > params names, the response headers could be anything they user wants. This > is just an example where we try to provide a good way of doing this. At > least this is my view of it. > > > > /Dan > > > > > > On 14 January 2013 10:28, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Looking at the PR for the demo ([1]) ,I am a bit surprised that > > classes like "Links.java" or "Metadata.java" are part of the demo > > code. > > > > I thought that the metadata/header informations on the response, like: > > ``` > > AG-Paging-Offset: 1 > > AG-Paging-Limit: 4 > > AG-Paging-Total: 4 > > AG-Links-First: cars?offset=0&limit=4 > > AG-Links-Previous: cars?offset=0&limit=4 > > AG-Links-Next: cars?offset=2&limit=4 > > AG-Links-Last: cars?offset=3&limit=4 > > ``` > > > > are applied by the framework. Of course, the "cars" in there is app > > specific, but this information could be read out of the actual route > > (/cars). > > > > Not sure, but... if all the time we (end user) needs to (re)impl. > > these things... it could be a bit annoying. > > > > > > IMO the problem would be: > > - if we add a dependency on the params into our client libraries, we > > pretty much build against a "demo API". Which is odd... > > I thought these "metadata details" are offered by the framework. > > > > -M > > > > [1] https://github.com/aerogear/aerogear-controller-demo/pull/19 > > > > On Sun, Jan 13, 2013 at 12:09 PM, Daniel Bevenius > > <daniel.bevenius(a)gmail.com&gt; wrote: > > > I've updated the demo and think I've included all the requests. > > > * Pre-populate the database upon deployment of demo. > > > * Use 'offset/limit' instead of 'page/perPage'. > > > * Use 'AG-' prefix for headers. > > > > > > Let me know if you are missing anything, or would like something done > in a > > > different way. > > > > > > Use case > > > > > > The example is using /cars as the resource to interact with. > > > > > > The following route has been added to the demo: > > > > > > route() > > > .from("/cars") > > > .on(RequestMethod.GET) > > > .produces(MediaType.JSON) > > > .to(Cars.class).get(param("offset", "0"), param("limit", "-1")); > > > > > > From this we can see that there are two optional parameters, offset > and > > > limit. If these are not specified all cars will be returned. > > > > > > Getting a page of Cars > > > > > > curl -i --header "Accept: application/json" > > > " > http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... > " > > > > > > The request will return: > > > > > > HTTP/1.1 200 OK > > > Content-Type: application/json;charset=UTF-8 > > > Content-Length: 160 > > > AG-Paging-Offset: 0 > > > AG-Paging-Limit: 4 > > > AG-Paging-Total: 4 > > > AG-Links-Next: cars?offset=1&limit=4 > > > AG-Links-Last: cars?offset=3&limit=4 > > > [ > > > {"color":"Green","brand":"Audi","id":1}, > > > {"color":"White","brand":"Audi","id":2}, > > > {"color":"Black","brand":"Audi","id":3}, > > > {"color":"Black","brand":"BMW","id":4} > > > ] > > > > > > Getting the next page of Cars > > > > > > To get the next page you can follow the next link: > > > > > > curl -i --header "Accept: application/json" > > > " > http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... > " > > > > > > HTTP/1.1 200 OK > > > Content-Type: application/json;charset=UTF-8 > > > Content-Length: 166 > > > AG-Paging-Offset: 1 > > > AG-Paging-Limit: 4 > > > AG-Paging-Total: 4 > > > AG-Links-First: cars?offset=0&limit=4 > > > AG-Links-Previous: cars?offset=0&limit=4 > > > AG-Links-Next: cars?offset=2&limit=4 > > > AG-Links-Last: cars?offset=3&limit=4 > > > [ > > > {"color":"Green","brand":"BMW","id":5}, > > > {"color":"Red","brand":"Ferrari","id":6}, > > > {"color":"White","brand":"Ferrari","id":7}, > > > {"color":"Pink","brand":"Ferrari","id":8} > > > ] > > > > > > Get all Cars > > > > > > curl -i --header "Accept: application/json" > > > " > http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars" > > > > > > This request will return: > > > > > > [ > > > {"color":"Green","brand":"Audi","id":1}, > > > {"color":"White","brand":"Audi","id":2}, > > > {"color":"Black","brand":"Audi","id":3}, > > > {"color":"Black","brand":"BMW","id":4}, > > > {"color":"Green","brand":"BMW","id":5}, > > > {"color":"Red","brand":"Ferrari","id":6}, > > > {"color":"White","brand":"Ferrari","id":7}, > > > {"color":"Pink","brand":"Ferrari","id":8}, > > > {"color":"White","brand":"Golf","id":15}, > > > {"color":"Brown","brand":"Lada","id":16}, > > > {"color":"Orange","brand":"Mazda","id":14}, > > > {"color":"Pink","brand":"Mini","id":13}, > > > {"color":"Gray","brand":"Nissan","id":11}, > > > {"color":"Yello","brand":"Opel","id":10}, > > > {"color":"Blue","brand":"Scoda","id":9}, > > > {"color":"Red","brand":"Volvo","id":12} > > > ] > > > > > > Get a single Car > > > > > > curl -i --header "Accept: application/json" > > > " > http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars/1&... > > > > > > The request will return: > > > > > > {"color":"Green","brand":"Audi","id":1} > > > > > > > > > > > > On 12 January 2013 11:08, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; > wrote: > > >> > > >> Great, lets go with 'AG-' prefix then. > > >> > > >> > > >> > > >> > > >> On 11 January 2013 18:24, Douglas Campos <qmx(a)qmx.me&gt; wrote: > > >>> > > >>> > > >>> On 11/01/2013, at 15:10, Kris Borchers <kris(a)redhat.com&gt; wrote: > > >>> > I guess what I meant is I'm not specifically +1 for X- prefix but > just > > >>> > some sort of prefix in general. It just makes it easier for devs > when > > >>> > looking through headers to see what is being sent. Even something > like AG- > > >>> > or AeroGear- would be better IMO than no prefix. > > >>> > > >>> d'oh, +1 - thought I've typed it… > > >>> > > >>> AG- looks nicer - less bandwidth ;) > > >>> > > >>> -- 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 > > > > _______________________________________________ > > 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 >

Is OffsetPagedResponse a class that implements ResponseHeaders ?

About the name maybe just PagedResponse instead of OffsetPagedResponse ?

Is OffsetPagedResponse a class that implements ResponseHeaders ? About the name maybe just PagedResponse instead of OffsetPagedResponse ? On Wed, Jan 16, 2013 at 3:45 PM, Daniel Bevenius < daniel.bevenius(a)gmail.com&gt; wrote: > Sorry about the spacing of code in my last post, you can see the source > here: > > https://github.com/danbev/aerogear-controller-demo/blob/AEROGEAR-795-pagi... > > > > > On 16 January 2013 15:43, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt;wrote: > >> I'm trying to find an easy way for doing this and wondering what people >> things about something like this: >> >> >> public OffsetPagedResponse findCarsByBrand(final String offsetParam, final String limitParam) { >> >> >> final int offset = Integer.valueOf(offsetParam); >> >> >> final int limit = Integer.valueOf(limitParam); >> >> >> final int total = getCarsTotal(); >> >> >> final List<Car> cars = getCars(offset, limit); >> >> >> >> return Pagination.offset(offset) >> >> >> .limit(limit) >> >> >> .total(total) >> >> >> .resourcePath("cars") >> >> >> .headersPrefix("Demo-") >> >> >> .response(cars); >> >> >> } >> >> >> >> On 14 January 2013 14:41, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> >>> Well, from reading the PR I really think this should be part of the >>> controller - something that decorates the return and sets appropriate >>> headers. >>> >>> a very high level usage example would be something like this: >>> >>> public List<Car> findCarsByFoo(Car example) { >>> List<Car> cars = // does the magic >>> return paginate(cars); // static helper that wraps this list on a >>> lightweight wrapper, >>> // that triggers the behavior >>> } >>> >>> Thoughts? >>> >>> Matzew already put this on our meeting agenda for today, but feel free >>> to send suggestions here :) >>> >>> -- qmx >>> >>> On 14/01/2013, at 07:30, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; >>> wrote: >>> >>> > >if we add a dependency on the params into our client library, we >>> pretty much build against a "demo API". >>> > There should be no dependencies in the client APIs to these params or >>> headers. This is up the the implementation of the target Route and the >>> params names, the response headers could be anything they user wants. This >>> is just an example where we try to provide a good way of doing this. At >>> least this is my view of it. >>> > >>> > /Dan >>> > >>> > >>> > On 14 January 2013 10:28, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> > Looking at the PR for the demo ([1]) ,I am a bit surprised that >>> > classes like "Links.java" or "Metadata.java" are part of the demo >>> > code. >>> > >>> > I thought that the metadata/header informations on the response, like: >>> > ``` >>> > AG-Paging-Offset: 1 >>> > AG-Paging-Limit: 4 >>> > AG-Paging-Total: 4 >>> > AG-Links-First: cars?offset=0&limit=4 >>> > AG-Links-Previous: cars?offset=0&limit=4 >>> > AG-Links-Next: cars?offset=2&limit=4 >>> > AG-Links-Last: cars?offset=3&limit=4 >>> > ``` >>> > >>> > are applied by the framework. Of course, the "cars" in there is app >>> > specific, but this information could be read out of the actual route >>> > (/cars). >>> > >>> > Not sure, but... if all the time we (end user) needs to (re)impl. >>> > these things... it could be a bit annoying. >>> > >>> > >>> > IMO the problem would be: >>> > - if we add a dependency on the params into our client libraries, we >>> > pretty much build against a "demo API". Which is odd... >>> > I thought these "metadata details" are offered by the framework. >>> > >>> > -M >>> > >>> > [1] https://github.com/aerogear/aerogear-controller-demo/pull/19 >>> > >>> > On Sun, Jan 13, 2013 at 12:09 PM, Daniel Bevenius >>> > <daniel.bevenius(a)gmail.com&gt; wrote: >>> > > I've updated the demo and think I've included all the requests. >>> > > * Pre-populate the database upon deployment of demo. >>> > > * Use 'offset/limit' instead of 'page/perPage'. >>> > > * Use 'AG-' prefix for headers. >>> > > >>> > > Let me know if you are missing anything, or would like something >>> done in a >>> > > different way. >>> > > >>> > > Use case >>> > > >>> > > The example is using /cars as the resource to interact with. >>> > > >>> > > The following route has been added to the demo: >>> > > >>> > > route() >>> > > .from("/cars") >>> > > .on(RequestMethod.GET) >>> > > .produces(MediaType.JSON) >>> > > .to(Cars.class).get(param("offset", "0"), param("limit", >>> "-1")); >>> > > >>> > > From this we can see that there are two optional parameters, offset >>> and >>> > > limit. If these are not specified all cars will be returned. >>> > > >>> > > Getting a page of Cars >>> > > >>> > > curl -i --header "Accept: application/json" >>> > > " >>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... >>> " >>> > > >>> > > The request will return: >>> > > >>> > > HTTP/1.1 200 OK >>> > > Content-Type: application/json;charset=UTF-8 >>> > > Content-Length: 160 >>> > > AG-Paging-Offset: 0 >>> > > AG-Paging-Limit: 4 >>> > > AG-Paging-Total: 4 >>> > > AG-Links-Next: cars?offset=1&limit=4 >>> > > AG-Links-Last: cars?offset=3&limit=4 >>> > > [ >>> > > {"color":"Green","brand":"Audi","id":1}, >>> > > {"color":"White","brand":"Audi","id":2}, >>> > > {"color":"Black","brand":"Audi","id":3}, >>> > > {"color":"Black","brand":"BMW","id":4} >>> > > ] >>> > > >>> > > Getting the next page of Cars >>> > > >>> > > To get the next page you can follow the next link: >>> > > >>> > > curl -i --header "Accept: application/json" >>> > > " >>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... >>> " >>> > > >>> > > HTTP/1.1 200 OK >>> > > Content-Type: application/json;charset=UTF-8 >>> > > Content-Length: 166 >>> > > AG-Paging-Offset: 1 >>> > > AG-Paging-Limit: 4 >>> > > AG-Paging-Total: 4 >>> > > AG-Links-First: cars?offset=0&limit=4 >>> > > AG-Links-Previous: cars?offset=0&limit=4 >>> > > AG-Links-Next: cars?offset=2&limit=4 >>> > > AG-Links-Last: cars?offset=3&limit=4 >>> > > [ >>> > > {"color":"Green","brand":"BMW","id":5}, >>> > > {"color":"Red","brand":"Ferrari","id":6}, >>> > > {"color":"White","brand":"Ferrari","id":7}, >>> > > {"color":"Pink","brand":"Ferrari","id":8} >>> > > ] >>> > > >>> > > Get all Cars >>> > > >>> > > curl -i --header "Accept: application/json" >>> > > " >>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars" >>> > > >>> > > This request will return: >>> > > >>> > > [ >>> > > {"color":"Green","brand":"Audi","id":1}, >>> > > {"color":"White","brand":"Audi","id":2}, >>> > > {"color":"Black","brand":"Audi","id":3}, >>> > > {"color":"Black","brand":"BMW","id":4}, >>> > > {"color":"Green","brand":"BMW","id":5}, >>> > > {"color":"Red","brand":"Ferrari","id":6}, >>> > > {"color":"White","brand":"Ferrari","id":7}, >>> > > {"color":"Pink","brand":"Ferrari","id":8}, >>> > > {"color":"White","brand":"Golf","id":15}, >>> > > {"color":"Brown","brand":"Lada","id":16}, >>> > > {"color":"Orange","brand":"Mazda","id":14}, >>> > > {"color":"Pink","brand":"Mini","id":13}, >>> > > {"color":"Gray","brand":"Nissan","id":11}, >>> > > {"color":"Yello","brand":"Opel","id":10}, >>> > > {"color":"Blue","brand":"Scoda","id":9}, >>> > > {"color":"Red","brand":"Volvo","id":12} >>> > > ] >>> > > >>> > > Get a single Car >>> > > >>> > > curl -i --header "Accept: application/json" >>> > > " >>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars/1 >>> " >>> > > >>> > > The request will return: >>> > > >>> > > {"color":"Green","brand":"Audi","id":1} >>> > > >>> > > >>> > > >>> > > On 12 January 2013 11:08, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; wrote: >>> > >> >>> > >> Great, lets go with 'AG-' prefix then. >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On 11 January 2013 18:24, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> > >>> >>> > >>> >>> > >>> On 11/01/2013, at 15:10, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> > >>> > I guess what I meant is I'm not specifically +1 for X- prefix >>> but just >>> > >>> > some sort of prefix in general. It just makes it easier for >>> devs when >>> > >>> > looking through headers to see what is being sent. Even >>> something like AG- >>> > >>> > or AeroGear- would be better IMO than no prefix. >>> > >>> >>> > >>> d'oh, +1 - thought I've typed it… >>> > >>> >>> > >>> AG- looks nicer - less bandwidth ;) >>> > >>> >>> > >>> -- 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 >>> > >>> > _______________________________________________ >>> > 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

Hi slackers, after some discussion with @danbev we ended up with a middle term for 0.1 version on pagination (**Controller only**). Dan suggested a callback method to enable us to inform the number of records on Routes, which is fair enough. Suggestion ->>>>> https://gist.github.com/a167f34408281527e7ee @qmx also proposed to extend Controller via CDI to the further releases. And you wdyt? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 16, 2013 at 1:19 PM, Daniel Bevenius wrote: > > Is OffsetPagedResponse a class that implements ResponseHeaders ? > > At the moment it is. We are still working on the server side, and will probably make this an interface. > > > About the name maybe just PagedResponse instead of OffsetPagedResponse ? > Yep, that sounds better. > > Thanks, > > /Dan > > > On 16 January 2013 16:12, Sebastien Blanc <scm.blanc(a)gmail.com (mailto: scm.blanc(a)gmail.com)&gt; wrote: > > Is OffsetPagedResponse a class that implements ResponseHeaders ? About the name maybe just PagedResponse instead of OffsetPagedResponse ? > > > > > > On Wed, Jan 16, 2013 at 3:45 PM, Daniel Bevenius < daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)> wrote: > > > Sorry about the spacing of code in my last post, you can see the source here: > > > https://github.com/danbev/aerogear-controller-demo/blob/AEROGEAR-795-pagi... > > > > > > > > > > > > > > > On 16 January 2013 15:43, Daniel Bevenius <daniel.bevenius(a)gmail.com(mailto: daniel.bevenius(a)gmail.com)&gt; wrote: > > > > I'm trying to find an easy way for doing this and wondering what people things about something like this: > > > > > > > > public OffsetPagedResponse findCarsByBrand(final String offsetParam, final String limitParam) { > > > > final int offset = Integer.valueOf(offsetParam); > > > > final int limit = Integer.valueOf(limitParam); > > > > final int total = getCarsTotal(); > > > > final List<Car> cars = getCars(offset, limit); > > > > > > > > return Pagination.offset(offset) > > > > .limit(limit) > > > > .total(total) > > > > .resourcePath("cars") > > > > .headersPrefix("Demo-") > > > > .response(cars); > > > > } > > > > > > > > > > > > > > > > On 14 January 2013 14:41, Douglas Campos <qmx(a)qmx.me (mailto: qmx(a)qmx.me)&gt; wrote: > > > > > Well, from reading the PR I really think this should be part of the controller - something that decorates the return and sets appropriate headers. > > > > > > > > > > a very high level usage example would be something like this: > > > > > > > > > > public List<Car> findCarsByFoo(Car example) { > > > > > List<Car> cars = // does the magic > > > > > return paginate(cars); // static helper that wraps this list on a lightweight wrapper, > > > > > // that triggers the behavior > > > > > } > > > > > > > > > > Thoughts? > > > > > > > > > > Matzew already put this on our meeting agenda for today, but feel free to send suggestions here :) > > > > > > > > > > -- qmx > > > > > > > > > > On 14/01/2013, at 07:30, Daniel Bevenius < daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)> wrote: > > > > > > > > > > > > if we add a dependency on the params into our client library, we pretty much build against a "demo API". > > > > > > There should be no dependencies in the client APIs to these params or headers. This is up the the implementation of the target Route and the params names, the response headers could be anything they user wants. This is just an example where we try to provide a good way of doing this. At least this is my view of it. > > > > > > > > > > > > /Dan > > > > > > > > > > > > > > > > > > On 14 January 2013 10:28, Matthias Wessendorf < matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > > > > > > Looking at the PR for the demo ([1]) ,I am a bit surprised that > > > > > > classes like "Links.java" or "Metadata.java" are part of the demo > > > > > > code. > > > > > > > > > > > > I thought that the metadata/header informations on the response, like: > > > > > > ``` > > > > > > AG-Paging-Offset: 1 > > > > > > AG-Paging-Limit: 4 > > > > > > AG-Paging-Total: 4 > > > > > > AG-Links-First: cars?offset=0&limit=4 > > > > > > AG-Links-Previous: cars?offset=0&limit=4 > > > > > > AG-Links-Next: cars?offset=2&limit=4 > > > > > > AG-Links-Last: cars?offset=3&limit=4 > > > > > > ``` > > > > > > > > > > > > are applied by the framework. Of course, the "cars" in there is app > > > > > > specific, but this information could be read out of the actual route > > > > > > (/cars). > > > > > > > > > > > > Not sure, but... if all the time we (end user) needs to (re)impl. > > > > > > these things... it could be a bit annoying. > > > > > > > > > > > > > > > > > > IMO the problem would be: > > > > > > - if we add a dependency on the params into our client libraries, we > > > > > > pretty much build against a "demo API". Which is odd... > > > > > > I thought these "metadata details" are offered by the framework. > > > > > > > > > > > > -M > > > > > > > > > > > > [1] https://github.com/aerogear/aerogear-controller-demo/pull/19 > > > > > > > > > > > > On Sun, Jan 13, 2013 at 12:09 PM, Daniel Bevenius > > > > > > <daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)> wrote: > > > > > > > I've updated the demo and think I've included all the requests. > > > > > > > * Pre-populate the database upon deployment of demo. > > > > > > > * Use 'offset/limit' instead of 'page/perPage'. > > > > > > > * Use 'AG-' prefix for headers. > > > > > > > > > > > > > > Let me know if you are missing anything, or would like something done in a > > > > > > > different way. > > > > > > > > > > > > > > Use case > > > > > > > > > > > > > > The example is using /cars as the resource to interact with. > > > > > > > > > > > > > > The following route has been added to the demo: > > > > > > > > > > > > > > route() > > > > > > > .from("/cars") > > > > > > > .on(RequestMethod.GET) > > > > > > > .produces(MediaType.JSON) > > > > > > > .to(Cars.class).get(param("offset", "0"), param("limit", "-1")); > > > > > > > > > > > > > > From this we can see that there are two optional parameters, offset and > > > > > > > limit. If these are not specified all cars will be returned. > > > > > > > > > > > > > > Getting a page of Cars > > > > > > > > > > > > > > curl -i --header "Accept: application/json" > > > > > > > " http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... " > > > > > > > > > > > > > > The request will return: > > > > > > > > > > > > > > HTTP/1.1 200 OK > > > > > > > Content-Type: application/json;charset=UTF-8 > > > > > > > Content-Length: 160 > > > > > > > AG-Paging-Offset: 0 > > > > > > > AG-Paging-Limit: 4 > > > > > > > AG-Paging-Total: 4 > > > > > > > AG-Links-Next: cars?offset=1&limit=4 > > > > > > > AG-Links-Last: cars?offset=3&limit=4 > > > > > > > [ > > > > > > > {"color":"Green","brand":"Audi","id":1}, > > > > > > > {"color":"White","brand":"Audi","id":2}, > > > > > > > {"color":"Black","brand":"Audi","id":3}, > > > > > > > {"color":"Black","brand":"BMW","id":4} > > > > > > > ] > > > > > > > > > > > > > > Getting the next page of Cars > > > > > > > > > > > > > > To get the next page you can follow the next link: > > > > > > > > > > > > > > curl -i --header "Accept: application/json" > > > > > > > " http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?of... " > > > > > > > > > > > > > > HTTP/1.1 200 OK > > > > > > > Content-Type: application/json;charset=UTF-8 > > > > > > > Content-Length: 166 > > > > > > > AG-Paging-Offset: 1 > > > > > > > AG-Paging-Limit: 4 > > > > > > > AG-Paging-Total: 4 > > > > > > > AG-Links-First: cars?offset=0&limit=4 > > > > > > > AG-Links-Previous: cars?offset=0&limit=4 > > > > > > > AG-Links-Next: cars?offset=2&limit=4 > > > > > > > AG-Links-Last: cars?offset=3&limit=4 > > > > > > > [ > > > > > > > {"color":"Green","brand":"BMW","id":5}, > > > > > > > {"color":"Red","brand":"Ferrari","id":6}, > > > > > > > {"color":"White","brand":"Ferrari","id":7}, > > > > > > > {"color":"Pink","brand":"Ferrari","id":8} > > > > > > > ] > > > > > > > > > > > > > > Get all Cars > > > > > > > > > > > > > > curl -i --header "Accept: application/json" > > > > > > > " http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars" > > > > > > > > > > > > > > This request will return: > > > > > > > > > > > > > > [ > > > > > > > {"color":"Green","brand":"Audi","id":1}, > > > > > > > {"color":"White","brand":"Audi","id":2}, > > > > > > > {"color":"Black","brand":"Audi","id":3}, > > > > > > > {"color":"Black","brand":"BMW","id":4}, > > > > > > > {"color":"Green","brand":"BMW","id":5}, > > > > > > > {"color":"Red","brand":"Ferrari","id":6}, > > > > > > > {"color":"White","brand":"Ferrari","id":7}, > > > > > > > {"color":"Pink","brand":"Ferrari","id":8}, > > > > > > > {"color":"White","brand":"Golf","id":15}, > > > > > > > {"color":"Brown","brand":"Lada","id":16}, > > > > > > > {"color":"Orange","brand":"Mazda","id":14}, > > > > > > > {"color":"Pink","brand":"Mini","id":13}, > > > > > > > {"color":"Gray","brand":"Nissan","id":11}, > > > > > > > {"color":"Yello","brand":"Opel","id":10}, > > > > > > > {"color":"Blue","brand":"Scoda","id":9}, > > > > > > > {"color":"Red","brand":"Volvo","id":12} > > > > > > > ] > > > > > > > > > > > > > > Get a single Car > > > > > > > > > > > > > > curl -i --header "Accept: application/json" > > > > > > > " http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars/1&... > > > > > > > > > > > > > > The request will return: > > > > > > > > > > > > > > {"color":"Green","brand":"Audi","id":1} > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12 January 2013 11:08, Daniel Bevenius < daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)> wrote: > > > > > > > > > > > > > > > > Great, lets go with 'AG-' prefix then. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 January 2013 18:24, Douglas Campos <qmx(a)qmx.me(mailto: qmx(a)qmx.me)&gt; wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/01/2013, at 15:10, Kris Borchers <kris(a)redhat.com(mailto: kris(a)redhat.com)&gt; wrote: > > > > > > > > > > I guess what I meant is I'm not specifically +1 for X- prefix but just > > > > > > > > > > some sort of prefix in general. It just makes it easier for devs when > > > > > > > > > > looking through headers to see what is being sent. Even something like AG- > > > > > > > > > > or AeroGear- would be better IMO than no prefix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > d'oh, +1 - thought I've typed it… > > > > > > > > > > > > > > > > > > AG- looks nicer - less bandwidth ;) > > > > > > > > > > > > > > > > > > -- qmx > > > > > > > > > _______________________________________________ > > > > > > > > > aerogear-dev mailing list > > > > > > > > > aerogear-dev(a)lists.jboss.org (mailto: 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(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 (mailto: 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(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(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 (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

On Thu, Jan 17, 2013 at 02:59:15PM +0100, Sebastien Blanc wrote: > I'm not sure to understand exactly this part : > > param("name").offset(offset).limit(limit).total(total)) This is confusing! what's the content of those variables? did you mean offset("offset")... and so on. At this current form, I'm -1 on it - just too intrusive. Perhaps just doing a paginate() call on the route and specifying the parameters via config object? -- 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

I've been thinking about this and needed to make an update to the controller as I hade neglected to support returning query parameters in link headers, other than those used for paging. I've looked into Bruno's original suggestion and think it has a huge advantage in that the target endpoint class does not have to be changed, and can simply return a List<?>. route() .from("/cars") .on(RequestMethod.GET) .produces(MediaType.JSON) .paged().offset()) .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), param("limit", "10")); For cases where the parameters 'offset' and 'limit' are named differently they could be configurable: route() .from("/cars") .on(RequestMethod.GET) .produces(MediaType.JSON) .paged().offset("myoffset").limitParamName("mylimit") .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), param("limit", "10"));

For now, I've just ignored support for a total as I think we need more time to investigate a proper solution for it, if we think it should be supported at all. The problem with having a callback is that in some situations, like the one above, that callback would also have to take a query parameter(s) so we'd need to do more work that like it initial idea were it would be possible to simply specify a name of a no-args method that returned an int/long.

Have you researched on using CDI interceptors for this?

So what about injecting pagination info via CDI?

Another option would be to have the method receiving the PaginationInfo parameter, which would eliminate the need for annotations and stuff - if you put the parameter on the signature, the response will be wrapped automagically.

We already got rid of total :)

On Sun, Jan 20, 2013 at 07:29:41AM -0800, danielbevenius wrote: > I've been thinking about this and needed to make an update to the controller > as I hade neglected to support returning query parameters in link headers, > other than those used for paging. > > I've looked into Bruno's original suggestion and think it has a huge > advantage in that the target endpoint class does not have to be changed, and > can simply return a List<?>. > > route() > .from("/cars") > .on(RequestMethod.GET) > .produces(MediaType.JSON) > .paged().offset()) > .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), > param("limit", "10")); > > For cases where the parameters 'offset' and 'limit' are named differently > they could be configurable: > route() > .from("/cars") > .on(RequestMethod.GET) > .produces(MediaType.JSON) > .paged().offset("myoffset").limitParamName("mylimit") > .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), > param("limit", "10")); Well, I'm not a fan of putting the pagination info on the routes themselves. Have you researched on using CDI interceptors for this? as it's clearly an infrastructure concern. So what about injecting pagination info via CDI? This means that we'll need to use instance variables on the Controller class, and decorate it during instantiation. The paging support could be enabled by using an annotation on the controller method (@Paginated), and the CDI extension would take care of wrapping the response/putting the headers accordingly. public class Cars { private PaginationInfo paginationInfo; @Paginated public List<Car> list() { // fetch offset/limit from this.paginationInfo } } The response would be decorated with the appropriate links. Another option would be to have the method receiving the PaginationInfo parameter, which would eliminate the need for annotations and stuff - if you put the parameter on the signature, the response will be wrapped automagically. Thoughts? > For now, I've just ignored support for a total as I think we need more time > to investigate a proper solution for it, if we think it should be supported > at all. The problem with having a callback is that in some situations, like > the one above, that callback would also have to take a query parameter(s) so > we'd need to do more work that like it initial idea were it would be > possible to simply specify a name of a no-args method that returned an > int/long. We already got rid of total :) -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'm +1 for annotations or include it on Routes configuration. Any thoughts? If I don't hear any opinions, I'll be selfish and pick up my suggestion to implement with Dan :)

-- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, January 22, 2013 at 4:58 AM, Daniel Bevenius wrote: >Have you researched on using CDI interceptors for this? No, I've not looked at a solution that involved CDI interceptors for this. >So what about injecting pagination info via CDI? I think that it makes sense for users to be able to simply use their existing classes with AeroGear Controller by configuring their routes and not have to touch existing code. This is what I liked about liked with Bruno's suggestion. Using any of the suggestions here, and my previous suggestion with having a specific response type, all have this disadvantage. But this might just be wishful thinking and we might simply discover that this is required when more functionality is added hence might as well do this now. >Another option would be to have the method receiving the PaginationInfo >parameter, which would eliminate the need for annotations and stuff - if >you put the parameter on the signature, the response will be wrapped >automagically. I that case I think it makes more sense to go with a solution of having a specific return type on the method. The information in PaginationInfo would already be available to the target endpoint methods as parameters (offset/limit) and it would use something like was suggested earlier in this thread. I just think that might be more clear about what is actually going on. I'll start looking into using an CDI interceptor solution and see how this would work. I'll also take a look at the other approach with using PaginationInfo. As we don't have much time here it would be great if we as a team can decide on one solution by the end of today (2012-0122). >We already got rid of total :) Glad to hear that :) On 22 January 2013 00:04, Douglas Campos <qmx(a)qmx.me&gt; wrote: On Sun, Jan 20, 2013 at 07:29:41AM -0800, danielbevenius wrote: > I've been thinking about this and needed to make an update to the > controller > as I hade neglected to support returning query parameters in link headers, > other than those used for paging. > > I've looked into Bruno's original suggestion and think it has a huge > advantage in that the target endpoint class does not have to be changed, > and > can simply return a List<?>. > > route() > .from("/cars") > .on(RequestMethod.GET) > .produces(MediaType.JSON) > .paged().offset()) > .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), > param("limit", "10")); > > For cases where the parameters 'offset' and 'limit' are named differently > they could be configurable: > route() > .from("/cars") > .on(RequestMethod.GET) > .produces(MediaType.JSON) > .paged().offset("myoffset").limitParamName("mylimit") > .to(Cars.class).findCarsBy(param("offset", "0"), param("color"), > param("limit", "10")); Well, I'm not a fan of putting the pagination info on the routes themselves. Have you researched on using CDI interceptors for this? as it's clearly an infrastructure concern. So what about injecting pagination info via CDI? This means that we'll need to use instance variables on the Controller class, and decorate it during instantiation. The paging support could be enabled by using an annotation on the controller method (@Paginated), and the CDI extension would take care of wrapping the response/putting the headers accordingly. public class Cars { private PaginationInfo paginationInfo; @Paginated public List<Car> list() { // fetch offset/limit from this.paginationInfo } } The response would be decorated with the appropriate links. Another option would be to have the method receiving the PaginationInfo parameter, which would eliminate the need for annotations and stuff - if you put the parameter on the signature, the response will be wrapped automagically. Thoughts? > For now, I've just ignored support for a total as I think we need more > time > to investigate a proper solution for it, if we think it should be > supported > at all. The problem with having a callback is that in some situations, > like > the one above, that callback would also have to take a query parameter(s) > so > we'd need to do more work that like it initial idea were it would be > possible to simply specify a name of a no-args method that returned an > int/long. We already got rid of total :) -- 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jan 22, 2013 at 11:09:56AM -0200, Bruno Oliveira wrote: > I'm +1 for annotations or include it on Routes configuration. Since pagination != routing, annotation seems less intrusive, and there's the bonus point you can specify the limit/offset parameter names on that annotation. -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 For keeping this on the Route configuration for M8. We can certainly change things later, I just feel that time is starting to run out, and I'd also need to add and test the Web Linking support. On 22 January 2013 14:22, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > +1 > > > On Tue, Jan 22, 2013 at 2:22 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >> On Tue, Jan 22, 2013 at 11:09:56AM -0200, Bruno Oliveira wrote: >> > I'm +1 for annotations or include it on Routes configuration. >> Since pagination != routing, annotation seems less intrusive, and >> there's the bonus point you can specify the limit/offset parameter names >> on that annotation. >> >> -- 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 > >