Hey Bertrand,
long time no e-mail....
It's not clear why you even need the resetParent concept. Why not just
build the two sets of resources separately? Eg:
p.resource("a/b");
p.resource("c/d");
Peter Hunsberger
On Fri, Dec 11, 2015 at 10:13 AM, Bertrand Delacretaz <
[email protected]> wrote:
> Hi Julian,
>
> On Fri, Dec 11, 2015 at 5:01 PM, Julian Sedding <[email protected]>
> wrote:
> > ...what does "resetParent()" do? Sounds
> > like it resets all changes on the parent, but I suspect that's not it...
>
> Indeed, that's not it. It resets the original parent as the current
> parent under which resources are created, so that for example,
> starting with a builder having /tmp as its parent resource:
>
> .resource("a/b").resource("c/d")
>
> results in a resource at /tmp/a/b/c/d, whereas
>
> .resource("a/b").resetParent().resource("c/d")
>
> results in both /tmp/a/b and /tmp/c/d resources.
>
> As explained (I think) in the ResourceBuilder javadocs the logic is:
>
> -The builder starts in "hierarchy mode" where it starts with a parent
> resource, and makes the newly created resource the new current parent
> (the builder accepts only relative paths)
>
> -You can switch to "siblings mode" and back. In siblings mode creating
> a resource does not change the current parent
>
> -resetParent() resets current parent to the original one, supplied at
> builder creating time.
>
> Does this make it clearer? Do we need better names?
>
> resetHierarchy() maybe? The method also sets hierarchy mode so that
> might make sense.
>
> -Bertrand
>
