Re: [aerogear-dev] [ag-controller] PaginationStrategy

Hi Dan! +1 for I'm just not sure about the producers, it looks like too much. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, February 19, 2013 at 10:51 AM, Daniel Bevenius wrote: > For AEROGEAR-863 "Make PagingStrategy pluggable" the following suggestion is being proposed: > > Custom PaginationStrategy > > This section describes how a custom pagination strategy can be implemented in AeroGear Controller. > Depending on if you need a completely different strategy, or if you simply want to change/add/rename the returned HTTP response headers, you have two options: > > Extend AbstractPaginationStrategy > > You would extend AbstractPaginationStrategy if you simply want to change/add/rename the returned HTTP response headers. > > Example of extending AbstractPaginationStrategy: > public class MyStrategy extends AbstractPaginationStrategy { @Override public void setResponseHeaders(PaginationMetadata md, HttpServletResponse response, int resultSize) { for (Entry<String, String> entry : md.getHeaders(resultSize).entrySet()) { response.setHeader(entry.getKey(), entry.getValue()); } } } > > > This implementation actually does exactly what the default implementation does. But you can of course modify this to suite your own requirements. You have access to all the metadata (http://aerogear.org/docs/specs/aerogear-controller/org/jboss/aerogear/con...) for the pagination, like the raw links (http://aerogear.org/docs/specs/aerogear-controller/org/jboss/aerogear/con...) etc, so you could assemble headers in any way you see fit. > > Implement PaginationStrategy > > This will give you more control over the pagination strategy. The interface you have to implement looks like this: > > /** * A strategy for implementing pagination in AeroGear Controller. */ public interface PaginationStrategy { /** * Creates a PaginationInfo instance. * How this information is gathered, be it from an Annotation on the target * endpoint method, or by using separate request parameters is up to the * concrete implementation. * * @param routeContext the {@link RouteContext} of the route being processed. * @param arguments the extracted arguments from the current request. * @return {@link PaginationInfo} the information requred for paging. */ PaginationInfo createPaginationInfo(RouteContext routeContext, Map<String, Object> arguments); /** * Called before the target endpoint method has been invoked and enables a * concrete strategy to manipulate the arguments that will be passed to * the target endpoint method. * * @param pagingInfo the {@link PaginationInfo} instance created by * this strategy. * @param arguments the extracted arguments from the current request. * * @return {@code Obj ect[]} the arguments that will be passed to the target * endpoint method. */ Object[] preInvocation(PaginationInfo pagingInfo, Map<String, Object> arguments); /** * Called after the target endpoint method has been invoked and * allows the strategy to set HTTP Response headers. * * @param result the result returned from the target endpoint method. * @param routeContext the {@link RouteContext}. * @param pagingInfo the {@link PaginationInfo} instance created by this strategy. * * @return {@code Object} Either the unchanged result or a modified result * depending on the underlying implementation. */ Object postInvocation(Object result, RouteContext routeContext, PaginationInfo pagingInfo); }