dev@jsr311.java.net

Re: Removing _at_UnmatchedPath

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 09 Jul 2007 12:20:06 -0400

On Jul 9, 2007, at 7:43 AM, Bill de hOra wrote:
>
> I prefer the new version for the API. However, if I read the uri
> templates draft right, I think greedy is the default - it doesn't
> support any operators/quantifiers but says any legal URI tokens can
> go inside the brackets. So if I had (assuming greedy)
>
> @UriTemplate(value="folders/{path}")
>
> I'll match this - "folders/*".

Right, the URI templates draft only really specifies mapping a
template to a URI, not the reverse. As Paul notes, by default we
constrain a URI template parameter to a single path segment to enable
sub-resources.

Marc.

> if I added another tenmplate pattern
>
> @UriTemplate(value="folders/{path}")
> @UriTemplate(value="folders/{path}/{subpath}")
>
> then "folders/*" could go to either; ie, what gets called depends
> on the order they're invoked - unless we're saying implementations
> are expected to resolve this.
>
> With a greedy operator in play, the call order could be changed as
> well, assuming we did this
>
> @UriTemplate(value="folders/{path}")
> @UriTemplate(value="folders/{path}/{subpath}
>
> and this
>
> @UriTemplate(value="folders/{path}" greedy=true)
> @UriTemplate(value="folders/{path}/{subpath}
>
> what gets called changes subject to implementation details.
>
> I think this means a) order of template evaluation matters, b) we
> need test cases.
>
> cheers
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.