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

Thu Jan 3 11:30:25 EST 2013

>Is it possible to combine pathParam and queryParam ?
Yes, it is possible to combine like your example shows. Though, I did
discovered a bug if the query parameter is not specified in the request but
has a default value. I'll add a test for this situation which is obviously
not covered :(

Thanks!

On 3 January 2013 16:12, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> 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 at gmail.com>wrote:
>
>> On Thu, Jan 3, 2013 at 4:03 PM, Daniel Bevenius <
>> daniel.bevenius at 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 at gmail.com> 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 at gmail.com> 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 at apache.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 3, 2013 at 12:57 PM, Daniel Bevenius <
>>>>>> daniel.bevenius at gmail.com> 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 at apache.org>wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius <
>>>>>>>> daniel.bevenius at gmail.com> 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-demo/>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> 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 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130103/67610391/attachment-0001.html 