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

On Thu, Jan 3, 2013 at 4:03 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com > 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 > >