On 31/08/11 09:47, Marek Potociar wrote:
> Hi Sergey,
>
> On 08/30/2011 11:54 PM, Sergey Beryozkin wrote:
>> I'm still not getting though what I'd use this method for ?
>> To avoid typing UriBuilder.fromUri(target.getUri()); ?
>> I can understand why UriInfo needs such methods - but not sure what I can do with getUriBuilder().build() or similar in
>> context of working with Target
>
> URI is the main piece of data encapsulated in Target. So there is a getter for it and in line with other JAX-RS
> components, when it comes to URI getters, there is also an overloaded version that returns UriBuilder which is supposed
> to overcome some of the URI API deficiencies. We don't ask why users would want to retrieve the Target's current URI. We
> just expose this possibility as Target's URI is an important piece of information. That's it. I didn't have any
> particular use case in mind when designing the getter, but I assumed that some users may find it useful in the context
> of their application and the external APIs they might be using. E.g. some specific 3-rd party resource localization API
> that is provided to support a particular service which takes a canonical URI as an input and returns new URI pointing to
> the resource representation that matches the user environment localization settings. If such API is accepting UriBuilder
> too, the UriBuilder version would likely be slightly more effective as there is no need to create another URI object to
> be returned from the API. Just a "off the top of my head" example of a potential use case. I am sure there is infinite
> space of potential use cases, as with any getter exposing interesting information.
I can agree there are many cases but when we work with Target we do
build the Target, so have getURI() and getURIBuilder() seems redundant -
the latter won;t harm but it's redundant IMHO...
>
>>>> 4. Can we consider adding a back() method ? That would allow Target glide back to the previous segment after multiple
>>>> path() invocations...
>>>
>>> Seems to me that current set of methods can cover the use cases where back() would be usable. The method would add more
>>> complexity without a real benefit (you would probably also need methods for finding out where would back() take you in
>>> any given moment, etc.).
>>>
>>
>> How the current rev can help with iterating over a set of relative URIs ?
>> I propose to have back() returning strictly to the prev path segment, optionally to the base URI
>
> Instead of DFS you can implement BFS.
>
> As I said, the purpose of back() method is very confusing, since there are certain browser-based assumptions about what
> "back" means:
>
> Target target = client.target("http://jax-rs-spec.java.net/");
> target.path("eg/sergey");
>
> // ...do some processing
>
> target.back();
>
> Where am I? "http://jax-rs-spec.java.net/" or "http://jax-rs-spec.java.net/eg"? Why?
>
As I've said twice, back() means to the "previous" path segment,
in this case it is clearly "
http://jax-rs-spec.java.net/eg" because a
path segment is separated from another one by "/" - Java docs can put
some extra clarification. Having back(boolean) would easily cover the
case "back to the prev segment or to the base URI".
However, I'm fine with having it not there, let me know please how does
the current API can facilitate something like that ?
Thanks, Sergey
> Marek
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com