We've pushed a version of AeroGear Controller with support for request parameters (AEROGEAR-671 <https://issues.jboss.org/browse/AEROGEAR-671>) to openshift<http://controllerdemo-danbev.rhcloud.com/aerogear-controller... . This demo has the following new route added to it: route() .from("/cars") .on(RequestMethod.GET) .produces(MediaType.JSON.toString(), "application/custom") .to(Home.class).get(param("color", "pink"), param("brand", "mini"));

>Hrm, not sure if I like having the default values for the parameters inside of the routing definition. Would you prefer not having support for default parameters values,

or would you like default parameter values but in a different form?

In the example above we are passing query parameters and might not make sense to have default values in this case, but these parameters could also be header, form, or cookie parameters.

situations where one might consider a header parameter or a cookie parameter as optional and would like a default value for it. Without defaults, we would need to have overloaded target methods as the current implementation needs an exact match for arguments -> parameters (but I'm sure we could look into different solutions).

/Dan On 3 January 2013 11:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; wrote: > >> We've pushed a version of AeroGear Controller with support for request >> parameters (AEROGEAR-671 <https://issues.jboss.org/browse/AEROGEAR-671>) >> to openshift<http://controllerdemo-danbev.rhcloud.com/aerogear-controller... >> . >> >> This demo has the following new route added to it: >> >> route() >> .from("/cars") >> .on(RequestMethod.GET) >> .produces(MediaType.JSON.toString(), "application/custom") >> .to(Home.class).get(param("color", "pink"), param("brand", "mini")); >> >> > > Hrm, not sure if I like having the default values for the parameters > inside of the routing definition. > > -Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

>Yeah, not exactly sure about the "location". Ah, I think this is a good point. When writing this it makes sense as I expect most people have code completion and you can understand that this is a default value that is expected. But reading them afterwards it is not obvious which is a bad thing. >Let's go with the current version. I was just not sure, when I took an initial look :) Lets see what the others think and perhaps change this if needed, or like you said, go with this for now and revisit. Thanks! On 3 January 2013 13:07, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Thu, Jan 3, 2013 at 12:57 PM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; wrote: > >> >Hrm, not sure if I like having the default values for the parameters >> inside of the routing definition. >> Would you prefer not having support for default parameters values, >> > > Nope, I am OK with default values > > > >> or would you like default parameter values but in a different form? >> > > Yeah, not exactly sure about the "location". > > I am fine with the current approach, but thought it may not be the best > to define them in the routing section. > But on the other hand, that's a very simple (and centralistic) solution > right now, so I am 99% OK with it :-) > > >> >> In the example above we are passing query parameters and might not make >> sense to have default values in this case, but these parameters could also >> be header, form, or cookie parameters. >> > Not sure if this makes a different but I'm thinking that there might be >> situations where one might consider a header parameter or a cookie >> parameter as optional and would like a default value for it. Without >> defaults, we would need to have overloaded target methods as the current >> implementation needs an exact match for arguments -> parameters (but I'm >> sure we could look into different solutions). >> > > Let's go with the current version. I was just not sure, when I took an > initial look :) > > >> >> >> /Dan >> >> >> On 3 January 2013 11:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; wrote: >>> >>>> We've pushed a version of AeroGear Controller with support for request >>>> parameters (AEROGEAR-671<https://issues.jboss.org/browse/AEROGEAR-671> >>>> ) to openshift<http://controllerdemo-danbev.rhcloud.com/aerogear-controller... >>>> . >>>> >>>> This demo has the following new route added to it: >>>> >>>> route() >>>> .from("/cars") >>>> .on(RequestMethod.GET) >>>> .produces(MediaType.JSON.toString(), "application/custom") >>>> .to(Home.class).get(param("color", "pink"), param("brand", "mini")); >>>> >>>> >>> >>> Hrm, not sure if I like having the default values for the parameters >>> inside of the routing definition. >>> >>> -Matthias >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> 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 >> >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > 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

>About the "location" I have a bit the same feeling as Matthias but like him I have no better idea for the moment. Sounds like this need to change this :) Perhaps somethings like param("name").default("value") Not sure if this is possible but just throwing it out there. I like this syntax ! +1

You said that for now, without any defaults, we have to overload the target method but is it not possible to just pass null if no values and no default is provided ? Yeah, I think that would work. So, just specify the params as done and if the param is missing from the request then pass null instead of generating an exception? My concern here would be that it might be a little more difficult to troubleshoot the application.

Thanks, /Dan On 3 January 2013 15:30, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > > About the "location" I have a bit the same feeling as Matthias but like > him I have no better idea for the moment. > You said that for now, without any defaults, we have to overload the > target method but is it not possible to just pass null if no values and no > default is provided ? > Because in your example that would mean that must have 2 differents > routes defined if I want to retrieve all the cars or filtered cars based on > the request params. > > Seb > > > > > On Thu, Jan 3, 2013 at 1:12 PM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; wrote: > >> >Yeah, not exactly sure about the "location". >> Ah, I think this is a good point. When writing this it makes sense as I >> expect most people have code completion and you can understand that this is >> a default value that is expected. But reading them afterwards it is not >> obvious which is a bad thing. >> >> >Let's go with the current version. I was just not sure, when I took an >> initial look :) >> Lets see what the others think and perhaps change this if needed, or >> like you said, go with this for now and revisit. >> >> Thanks! >> >> >> >> On 3 January 2013 13:07, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> On Thu, Jan 3, 2013 at 12:57 PM, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; wrote: >>> >>>> >Hrm, not sure if I like having the default values for the parameters >>>> inside of the routing definition. >>>> Would you prefer not having support for default parameters values, >>>> >>> >>> Nope, I am OK with default values >>> >>> >>> >>>> or would you like default parameter values but in a different form? >>>> >>> >>> Yeah, not exactly sure about the "location". >>> >>> I am fine with the current approach, but thought it may not be the best >>> to define them in the routing section. >>> But on the other hand, that's a very simple (and centralistic) solution >>> right now, so I am 99% OK with it :-) >>> >>> >>>> >>>> In the example above we are passing query parameters and might not >>>> make sense to have default values in this case, but these parameters could >>>> also be header, form, or cookie parameters. >>>> >>> Not sure if this makes a different but I'm thinking that there might be >>>> situations where one might consider a header parameter or a cookie >>>> parameter as optional and would like a default value for it. Without >>>> defaults, we would need to have overloaded target methods as the current >>>> implementation needs an exact match for arguments -> parameters (but I'm >>>> sure we could look into different solutions). >>>> >>> >>> Let's go with the current version. I was just not sure, when I took an >>> initial look :) >>> >>> >>>> >>>> >>>> /Dan >>>> >>>> >>>> On 3 January 2013 11:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius < >>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>> >>>>>> We've pushed a version of AeroGear Controller with support for >>>>>> request parameters (AEROGEAR-671<https://issues.jboss.org/browse/AEROGEAR-671> >>>>>> ) to openshift<http://controllerdemo-danbev.rhcloud.com/aerogear-controller... >>>>>> . >>>>>> >>>>>> This demo has the following new route added to it: >>>>>> >>>>>> route() >>>>>> .from("/cars") >>>>>> .on(RequestMethod.GET) >>>>>> .produces(MediaType.JSON.toString(), "application/custom") >>>>>> .to(Home.class).get(param("color", "pink"), param("brand", "mini")); >>>>>> >>>>>> >>>>> >>>>> Hrm, not sure if I like having the default values for the parameters >>>>> inside of the routing definition. >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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

Is it possible to combine pathParam and queryParam ?

Other question : Is it possible to combine pathParam and queryParam ? i.e /classroom/12?sex=male On Thu, Jan 3, 2013 at 4:07 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > On Thu, Jan 3, 2013 at 4:03 PM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; wrote: > >> >About the "location" I have a bit the same feeling as Matthias but >> like him I have no better idea for the moment. >> Sounds like this need to change this :) >> Perhaps somethings like >> param("name").default("value") >> Not sure if this is possible but just throwing it out there. >> >> I like this syntax ! +1 > > >You said that for now, without any defaults, we have to overload the >> target method but is it not possible to just pass null if no values and no >> default is provided ? >> Yeah, I think that would work. So, just specify the params as done and >> if the param is missing from the request then pass null instead of >> generating an exception? My concern here would be that it might be a little >> more difficult to troubleshoot the application. >> > > Yes, I'm also not really happy with passing null and we have to find a > better solution > > >> >> Thanks, >> >> /Dan >> >> >> >> On 3 January 2013 15:30, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >>> Hi, >>> >>> About the "location" I have a bit the same feeling as Matthias but like >>> him I have no better idea for the moment. >>> You said that for now, without any defaults, we have to overload the >>> target method but is it not possible to just pass null if no values and no >>> default is provided ? >>> Because in your example that would mean that must have 2 differents >>> routes defined if I want to retrieve all the cars or filtered cars based on >>> the request params. >>> >>> Seb >>> >>> >>> >>> >>> On Thu, Jan 3, 2013 at 1:12 PM, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; wrote: >>> >>>> >Yeah, not exactly sure about the "location". >>>> Ah, I think this is a good point. When writing this it makes sense as >>>> I expect most people have code completion and you can understand that this >>>> is a default value that is expected. But reading them afterwards it is not >>>> obvious which is a bad thing. >>>> >>>> >Let's go with the current version. I was just not sure, when I took >>>> an initial look :) >>>> Lets see what the others think and perhaps change this if needed, or >>>> like you said, go with this for now and revisit. >>>> >>>> Thanks! >>>> >>>> >>>> >>>> On 3 January 2013 13:07, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jan 3, 2013 at 12:57 PM, Daniel Bevenius < >>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>> >>>>>> >Hrm, not sure if I like having the default values for the >>>>>> parameters inside of the routing definition. >>>>>> Would you prefer not having support for default parameters values, >>>>>> >>>>> >>>>> Nope, I am OK with default values >>>>> >>>>> >>>>> >>>>>> or would you like default parameter values but in a different form? >>>>>> >>>>> >>>>> Yeah, not exactly sure about the "location". >>>>> >>>>> I am fine with the current approach, but thought it may not be the >>>>> best to define them in the routing section. >>>>> But on the other hand, that's a very simple (and centralistic) >>>>> solution right now, so I am 99% OK with it :-) >>>>> >>>>> >>>>>> >>>>>> In the example above we are passing query parameters and might not >>>>>> make sense to have default values in this case, but these parameters could >>>>>> also be header, form, or cookie parameters. >>>>>> >>>>> Not sure if this makes a different but I'm thinking that there might >>>>>> be situations where one might consider a header parameter or a cookie >>>>>> parameter as optional and would like a default value for it. Without >>>>>> defaults, we would need to have overloaded target methods as the current >>>>>> implementation needs an exact match for arguments -> parameters (but I'm >>>>>> sure we could look into different solutions). >>>>>> >>>>> >>>>> Let's go with the current version. I was just not sure, when I took >>>>> an initial look :) >>>>> >>>>> >>>>>> >>>>>> >>>>>> /Dan >>>>>> >>>>>> >>>>>> On 3 January 2013 11:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius < >>>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> We've pushed a version of AeroGear Controller with support for >>>>>>>> request parameters (AEROGEAR-671<https://issues.jboss.org/browse/AEROGEAR-671> >>>>>>>> ) to openshift<http://controllerdemo-danbev.rhcloud.com/aerogear-controller... >>>>>>>> . >>>>>>>> >>>>>>>> This demo has the following new route added to it: >>>>>>>> >>>>>>>> route() >>>>>>>> .from("/cars") >>>>>>>> .on(RequestMethod.GET) >>>>>>>> .produces(MediaType.JSON.toString(), "application/custom") >>>>>>>> .to(Home.class).get(param("color", "pink"), param("brand", "mini")); >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hrm, not sure if I like having the default values for the >>>>>>> parameters inside of the routing definition. >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev