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

Thu Jan 3 10:07:35 EST 2013

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/19f121c6/attachment.html 