Or an alternative is to change the place where 'edit' is positioned and
have these templates:
@UriTemplate(value="edit/{folders}", limited=false)
@UriTemplate(value="{folders}", limited=false)
I have used that trick (but not with limited=false) for differentiating
between read only and read/write atom entries in the atom server
example. There is a read only entry resource class and a read/write
entry resource class that extends from the former.
Having 'edit' at the end could cause issues if 'edit' is the last
segment in of a folder.
Using a matrix param is is nice too, but it is not currently possible to
split the functionality in an OO fashion and you will have to check if
the parameter is present or not and return method not allowed. It
depends on the design you want.
Paul.
Marc Hadley wrote:
> On Oct 17, 2007, at 12:32 PM, A S Manzoor wrote:
>>
>> Is there any way to get UriTemplate to match wild cards? In a nut
>> shell, the number of segments in a uri is indeterminate (I am not
>> talking about the terminal segment which can be handled using
>> limited=false). For instance,
>> @UriTemplate(value="{name}/{workspace}/{folders}/edit"). Here the
>> {folders} may have one or more segments. It would then be really nice
>> to have @UriParam("folders") String[] folders. One could then argue
>> for generalizing this by supporting regular expressions, though I have
>> no current use cases to require support for that. I am pretty sure
>> UriTemplate & UriParam doesn't offer this. If not, does something like
>> this make sense? Could it possibly be supported at some point?
>>
> Rather than use a final path segment for "edit", perhaps you could use a
> matrix param instead? Then you could use the limited=false mechanism to
> get the value of {folders} since matrix params are not by default
> considered significant for URI template matching.
>
> We don't support automatically splitting the resulting string but you
> could instead use your own type instead of String[] with a constructor
> that takes a String to do that.
>
> Hope that helps,
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109