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> wrote:
On Thu, Jan 3, 2013 at 12:57 PM, Daniel Bevenius <
daniel.bevenius(a)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(a)apache.org> wrote:
>
>>
>>
>> On Thu, Jan 3, 2013 at 11:24 AM, Daniel Bevenius <
>> daniel.bevenius(a)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...
>>> .
>>>
>>> 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