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

Thu Jan 3 10:12:49 EST 2013

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130103/56fa3710/attachment-0001.html 