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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com