Hi
On 25/02/13 14:35, 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.
I was also thinking about it today, and thought "UriBuilder.match(...)"
may be read as "does the current URI being built matches the
following..." and may be that can do, kind of testing what is already
there and such, so adding a single method may work, with a more complete
support for UriTemplate following, whether it is the best approach or
not, I'm not 100% sure
Cheers, Sergey
>
> -- Santiago
>
>