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@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/aerogear-dev