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