3:14 p.m.
Hi,
I'm currently working on scaffolding AG-controller stuff and for that I'm
relying on the REST endpoints generated by the forge REST plugin. A typical
method's signature of a generated endpoint looks like that :
*public Response findById(Long id)*
But an AG Controller route definition can't point to such a target method
since it only support Strings as parameters :
*
route().from("/customers/{id}").on(RequestMethod.GET).consumes(JSON).produces(JSON).to(CustomerEndpoint.class).findById(param("id"));
*
*
*
Of course, the quick workaround would be to change the signature of the
endpoint to :
*public Response findById(String id)*
*
*
But, in my particular case, after the scaffolding happens I can't really
tell the developers : "Well, now you have to change manually all the
signature of your endpoints and convert your Strings to Longs".
Another use case could be an application having existing endpoints used by
a Application A and we introduce Application B using AG controller. More
generally, I think it would be a nice addition to AG controller.
I've already proposed a pull request[1] that can't handle all the types
which have a constructor with a single String parameter : Long, Integer,
BigDecimal, etc ... And also added unit tests to be sure I doesn't break
Feedback is more than welcome !
Seb
[1] https://github.com/aerogear/aerogear-controller/pull/55
9:33 p.m.
Just an additional info : this PR doesn't imply any breaking changes, AG
controller demo, TODO app will continue to work without any code change !
Seb
On Tue, Mar 12, 2013 at 3:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
Hi,
I'm currently working on scaffolding AG-controller stuff and for that I'm
relying on the REST endpoints generated by the forge REST plugin. A typical
method's signature of a generated endpoint looks like that :
*public Response findById(Long id)*
But an AG Controller route definition can't point to such a target method
since it only support Strings as parameters :
*
route().from("/customers/{id}").on(RequestMethod.GET).consumes(JSON).produces(JSON).to(CustomerEndpoint.class).findById(param("id"));
*
*
*
Of course, the quick workaround would be to change the signature of the
endpoint to :
*public Response findById(String id)*
*
*
But, in my particular case, after the scaffolding happens I can't really
tell the developers : "Well, now you have to change manually all the
signature of your endpoints and convert your Strings to Longs".
Another use case could be an application having existing endpoints used by
a Application A and we introduce Application B using AG controller. More
generally, I think it would be a nice addition to AG controller.
I've already proposed a pull request[1] that can't handle all the types
which have a constructor with a single String parameter : Long, Integer,
BigDecimal, etc ... And also added unit tests to be sure I doesn't break
Feedback is more than welcome !
Seb
[1] https://github.com/aerogear/aerogear-controller/pull/55
9:02 a.m.
Hey Seb,
Support for types other than String were actually implemented in the past
but, it was decided to not add such support in favour of promoting the
usage of Java types (excluding the primitive wrappers). But requirements
can change, and perhaps this should be discussed again.
The motivation for adding before was the same as your second argument, that
it would be easier to use existing classes with aerogear controller. I'd
like to see this feature added for this reason.
/Dan
On 12 March 2013 15:14, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Hi,
I'm currently working on scaffolding AG-controller stuff and for that I'm
relying on the REST endpoints generated by the forge REST plugin. A typical
method's signature of a generated endpoint looks like that :
*public Response findById(Long id)*
But an AG Controller route definition can't point to such a target method
since it only support Strings as parameters :
*
route().from("/customers/{id}").on(RequestMethod.GET).consumes(JSON).produces(JSON).to(CustomerEndpoint.class).findById(param("id"));
*
*
*
Of course, the quick workaround would be to change the signature of the
endpoint to :
*public Response findById(String id)*
*
*
But, in my particular case, after the scaffolding happens I can't really
tell the developers : "Well, now you have to change manually all the
signature of your endpoints and convert your Strings to Longs".
Another use case could be an application having existing endpoints used by
a Application A and we introduce Application B using AG controller. More
generally, I think it would be a nice addition to AG controller.
I've already proposed a pull request[1] that can't handle all the types
which have a constructor with a single String parameter : Long, Integer,
BigDecimal, etc ... And also added unit tests to be sure I doesn't break
Feedback is more than welcome !
Seb
[1] https://github.com/aerogear/aerogear-controller/pull/55
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:32 p.m.
+1
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, March 13, 2013 at 1:31 PM, Douglas Campos wrote:
On 13/03/2013, at 05:02, Daniel Bevenius <daniel.bevenius(a)gmail.com
(mailto:daniel.bevenius@gmail.com)> wrote:
> But requirements can change, and perhaps this should be discussed again.
You've nailed it, I think we should add this support.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev
6:06 p.m.
Great !
Do we need more discussion before integrating this PR ?
Seb
On Wed, Mar 13, 2013 at 5:32 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
+1
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, March 13, 2013 at 1:31 PM, Douglas Campos wrote:
>
> On 13/03/2013, at 05:02, Daniel Bevenius <daniel.bevenius(a)gmail.com(mailto:
daniel.bevenius(a)gmail.com)> wrote:
>
> > But requirements can change, and perhaps this should be discussed
again.
>
> You've nailed it, I think we should add this support.
>
> -- qmx
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:34 a.m.
Do we need more discussion before integrating this PR ?
Looks
like we all agree. I'll process and provide feedback on the PR after
1.0.0, if that is ok with you Seb?
On 13 March 2013 18:06, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Great !
Do we need more discussion before integrating this PR ?
Seb
On Wed, Mar 13, 2013 at 5:32 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
> +1
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Wednesday, March 13, 2013 at 1:31 PM, Douglas Campos wrote:
>
> >
> > On 13/03/2013, at 05:02, Daniel Bevenius <daniel.bevenius(a)gmail.com(mailto:
> daniel.bevenius(a)gmail.com)> wrote:
> >
> > > But requirements can change, and perhaps this should be discussed
> again.
> >
> > You've nailed it, I think we should add this support.
> >
> > -- qmx
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4054
days inactive
4056
days old
6 comments
4 participants
participants (4)
-
Bruno Oliveira -
Daniel Bevenius -
Douglas Campos -
Sebastien Blanc