[aerogear-dev] Server Side: Paging API with Metadata and Links (was: Re: Paging Demo)

Bruno Oliveira bruno at abstractj.org
Mon Jan 21 19:43:00 EST 2013


I'd stick with the first alternative. Dan has already introduced decorators for CORS support, maybe we add it for pagination. Introduce annotations in this case is doable 




-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Monday, January 21, 2013 at 9:04 PM, Douglas Campos 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 at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130121/a955f49b/attachment.html 


More information about the aerogear-dev mailing list