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