On 25/02/13 16:36, Bill Burke wrote:
>
>
> On 2/25/2013 9:35 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Feb 22, 2013, at 11:02 AM, Sergey Beryozkin <sberyozkin_at_talend.com>
>> wrote:
>>
>>> On 22/02/13 15:51, Bill Burke wrote:
>>>>
>>>>
>>>> On 2/22/2013 10:06 AM, Sergey Beryozkin wrote:
>>>>> On 22/02/13 14:55, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 2/21/2013 12:37 PM, Marek Potociar wrote:
>>>>>>>
>>>>>>> On Feb 21, 2013, at 3:08 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/20/2013 12:08 PM, Marek Potociar wrote:
>>>>>>>>> Hello experts,
>>>>>>>>>
>>>>>>>>> Please review the issue that has been recently filed:
>>>>>>>>> http://java.net/jira/browse/JAX_RS_SPEC-359
>>>>>>>>>
>>>>>>>>> In summary the user wants to be able take a URI template, e.g.
>>>>>>>>> "http://example.com/name/{name}/age/{age}" and then take a URI,
>>>>>>>>> e.g.
>>>>>>>>> "http://example.com/name/Arnold/age/65" (guess who...) and extract
>>>>>>>>> the
>>>>>>>>> parameter values information into a Map<String, String> instance.
>>>>>>>>>
>>>>>>>>> The solution may look like:
>>>>>>>>>
>>>>>>>>> UriBuilder builder
>>>>>>>>> = UriBuilder.fromUri("http://example.com/name/{name}/age/{age}");
>>>>>>>>> UriTemplate template = builder.template();
>>>>>>>>> Map<String, String> params = new HashMap<String, String>();
>>>>>>>>> if (template.match("http://example.com/name/Arnold/age/65",
>>>>>>>>> params)) {
>>>>>>>>> params.put("name", "Alois");
>>>>>>>>> URI uri = builder.buildFromMap(params);
>>>>>>>>> ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The above requires following API changes:
>>>>>>>>>
>>>>>>>>> * introduce UriTemplate to represent, well, URI templates...
>>>>>>>>> * add ability to get UriTemplate instances from UriBuilder and
>>>>>>>>> WebTarget
>>>>>>>>> * expose the boolean UriTemplate.match(URI, Map<String,
>>>>>>>>> String>) method as part of the UriTemplate API.
>>>>>>>>>
>>>>>>>>> Now, finally, my question is:
>>>>>>>>>
>>>>>>>>> Q1. Do you think the above API would be useful?
>>>>>>>>> Q2. Is it something we should still try to add into JAX-RS 2.0,
>>>>>>>>> given
>>>>>>>>> where we are?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'd say extend UriBuilder with a match() method instead of
>>>>>>>> adding yet
>>>>>>>> another class we have to include within RuntimeDelegate. Something
>>>>>>>> like:
>>>>>>>>
>>>>>>>> Map<String, String> match(String URI);
>>>>>>>>
>>>>>>>> match() returns null if it can't match the current expression with
>>>>>>>> the passed in URI.
>>>>>>>
>>>>>>> Ok, your other email seems to make sense. Even though I think the
>>>>>>> user
>>>>>>> has a point (see issue comments) that the map should not be
>>>>>>> created by
>>>>>>> us, but user should be able to pass it as an input parameter. (Or
>>>>>>> maybe we can have 2 versions of the method.)
>>>>>>>
>>>>>>>>
>>>>>>>> Useful. Yes. Include in JAX-RS 2.0? Well... I don't get it...you've
>>>>>>>> deferred some pretty trivial improvements that I've submitted
>>>>>>>> and in
>>>>>>>> some cases important JIRAs like:
>>>>>>>>
>>>>>>>> JAX_RS_SPEC-339
>>>>>>>> JAX_RS_SPEC-317
>>>>>>>>
>>>>>>>> But you want to include a brand new feature? Plus complain
>>>>>>>> everytime
>>>>>>>> I make a suggestion that we're too close to the PFD? A bit
>>>>>>>> hypocritical don't you think?
>>>>>>>
>>>>>>> Maybe I should have just ignored this rant, but then again, it's
>>>>>>> rude
>>>>>>> to not reply to direct questions. :)
>>>>>>>
>>>>>>> Note that in my email I'm merely asking what you (EG) think. I'm not
>>>>>>> pushing for anything, or suggesting we should (or must) do anything.
>>>>>>> For that matter, I have not expressed any opinion about whether
>>>>>>> or not
>>>>>>> we should include the feature in 2.0. So to answer your last
>>>>>>> question,
>>>>>>> no, I do not think I'm being hypocritical here.
>>>>>>>
>>>>>>> Funny thing is that knowing you're somewhat frustrated after our
>>>>>>> recent conversations I tried to be extra careful to not sound like I
>>>>>>> would be pushing for anything and formulate the email as a pure
>>>>>>> summary of the issue at hand plus a couple of questions I'd like to
>>>>>>> get EG feedback on. Alas, apparently to no avail.
>>>>>>>
>>>>>>
>>>>>> You are the spec lead. You're the one with deadlines. You decide when
>>>>>> you are closing feature requests. I don't care either way, but if the
>>>>>> spec is still open there are minor improvements I'd like to get in,
>>>>>> specifically the exception message stuff.
>>>>>>
>>>>>> FWIW, I think the uri template stuff is a nice addition, but want new
>>>>>> methods on UriBuilder.
>>>>>>
>>>>> I'm against turning UriBuilder into UriTemplate, it is way too complex
>>>>> already, and as I said it is *not* UriTemplate, but the 'user' of it
>>>>>
>>>>
>>>> A uri template is something you build URIs from. Also, UriBuilder is
>>>> already a mutable uri template. UriBuilder already has code to parse
>>>> and
>>>> process uri templates. Seems like a perfectly natural place to include
>>>> match to me.
>>>>
>>> UriBuilder builds URI, asking URIBuilder "are you matching it" is
>>> confusing, because it is a builder, not a matcher. UriTemplate may
>>> have a number of useful methods letting users to get the properties
>>> of a given template - and having most of those methods would not make
>>> sense to have at UriBuilder level;
>>
>> I tend to agree with Sergey here. Matching is, in fact, a form of
>> "deconstruction"; mixing this with "construction" isn't very clean. If
>> it's about sharing code, that should be an implementation not an API
>> issue.
>>
>
> Then I vote to defer this new feature as it would require yet another
> class to be added to RuntimeDelegate. BTW, someday RuntimeDelegate is
> going to have to get more generic.
>
To me it was all about
myUriBuilder.getUriTemplate().match()
vs
myUriBuilder.match()
it is nearly the same, but the former option simply moves the extension
into a new 'direction' as opposed to getting the 'main' UriBuilder
interface expanded further. I was definitely not proposing to get
UriTemplate.valueOf() introduced.
Perhaps we even agree on this after all :-)
Cheers, Sergey
>