On Jun 4, 2008, at 8:10 AM, Stephan Koops wrote:
>
> +1 for b. Perhaps it is useful to change the javadoc of PathSegment,
> that an object represents "one" PathSegment instead of "a" and to
> note explicit that it is only the last one, if @Path.limited is false.
>
Yes, I'll clarify the docs once we reach agreement on exactly what we
want.
> What about the follwoing case, where there are multiple variables
> with the same name?
>
> @Path("{var}") // limited=true
> public class SomeResource {
> @GET
> @Path(value="{var}" limited=false)
> public SomeType get(@PathParam("var") T var) {...}
> }
>
> The following table shows the possibilties for the path "1/2/3" that
> seems useful to me, bases on Marcs proposal b.
> +------
> +-------------------------------------------------------------------+
> | |
> T |
> |Option+------+------------+-----------+--------------
> +--------------------+
> | |String|List<String>|PathSegment|List<PathSegm>|
> List<List<PathSegm>>|
> +------+------+------------+-----------+--------------
> +--------------------+
> | b1 |"2/3" |["1","2/3"] | "3" | ["2","3"] | [["1"],
> ["2","3"]] |
> +------+------+------------+-----------+--------------
> +--------------------+
> | b2 |"2/3" |["1","2/3"] | "3" |["1","2","3"] | [["1"],
> ["2","3"]] |
> +------+------+------------+-----------+--------------
> +--------------------+
> I prefer b1. Then List<PathSegm> is analog to String (from the view
> of the given information), and it seems useful to me to also allow
> List<List<PathSegm>> analog to List<String>.
Hmm, I think I prefer b2 without support for List<List<T>>. I can see
the attraction of List<List<T>> but its starting to feel too
complicated.
Another (simpler) possibility is to only allow List<PathSegment> and
not support List<other_types>. @PathParam would always apply to the
most recent path parameter and, in the case of limited=false,
List<PathSegment> would decompose the value into individual path
segments.
>
> IMO it is needed, because you could not enusre, that the name you
> choose ("var") is not be used in another @Path, that already matched
> parts of the current requested path.
> And - for know - the case
> @Path("{var}") // limited=true
> public class SomeResource {
> @GET
> @Path(value="{var}/abc/{var}", limited=false)
> // // limited effects only the second
> variable
> public SomeType get(@PathParam("var") T var) {...}
> }
> (all var names the same) is also allowed.
> A call with "1/2/abc/3/4" will result in var_1 is "1", var_2 = "2"
> and var_3 = "3/4". What should happen for T = List<PathSegment>? If
> b2 above is used, it is clear, that is contains ["1","2","3","4"],
> but for b1? ["2","3","4"] or ["3","4"]?
>
With the simpler suggestion above, var would be ["3", "4"].
Marc.
>> Marc Hadley wrote:
>>> Attached is a HTML table that outlines what I see as the possible
>>> values of var depending on type T in:
>>>
>>> @Path(value="{var}" limited=false)
>>> public class SomeResource {
>>> @GET
>>> public SomeType get(@PathParam("var") T var) {...}
>>> }
>>>
>>> for a request
>>>
>>> GET /1/2/3.
>>>
>>> As pointed out earlier in the thread, options (a) and (d) don't
>>> really work for PathSegment since that is designed to represent a
>>> single path segment rather than multiple. IMO, option (c) gives a
>>> surprising result for String which really only leaves option (b)
>>> as viable. Option (b) is a bit odd since the results are quite
>>> different depending on the type T but its already the case that
>>> PathSegment is special (it extracts the whole path segment even if
>>> the referenced template variable has adjacent literal characters)
>>> so I think I can live with that.
>>>
>>> Thoughts ?
>>> Marc.
>> For those who couldn't read it the first time, the table is at:
>>
>> https://jsr311.dev.java.net/sketches/table.html
>>
>> Sorry about that.
>> Marc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.