Re: [aerogear-dev] [aerogear-controller] Request Parameter support

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