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

[Matthias Wessendorf]

On Tue, Jan 22, 2013 at 2:09 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> I'm +1 for annotations or include it on Routes configuration.
>
> Any thoughts? If I don't hear any opinions, I'll be selfish and pick up my
> suggestion to implement with Dan :)


+1


>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> On Tuesday, January 22, 2013 at 4:58 AM, Daniel Bevenius wrote:
>
>>Have you researched on using CDI interceptors for this?
> No, I've not looked at a solution that involved CDI interceptors for this.
>
>>So what about injecting pagination info via CDI?
> 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.
>
>>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.
> 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.
>
> 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).
>
>>We already got rid of total :)
> Glad to hear that :)
>
>
>
>
>
>
> On 22 January 2013 00:04, Douglas Campos <qmx at qmx.me> 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
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf