Ugh, I see. I had assumed a more functional style with the state travelling with the return value, that then get's chained to the next call. Been looking at Scala DSL's too long, but I think it is the patten you want here; each step returns a wrapper class around the call to the ResourceBuilder and state is retained in the wrapper instead of the ResourceBuilder itself? May be too much refactoring, I've just started looking at Sling...
On Saturday, December 12, 2015, Bertrand Delacretaz <[email protected]> wrote: > Hi Peter, > > Good to read you here! > > On Fri, Dec 11, 2015 at 5:49 PM, Peter Hunsberger > <[email protected] <javascript:;>> wrote: > > ...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"); ... > > The ResourceBuilder is stateful, to make it easy to create content > hierarchies, so I think you need a way to tell it to restart at the > top in some cases - or implement pop() to go back up the stack of > created resources, but that makes it less intuitive IMO. > > But maybe you have better ideas on how to express this example tree in > a fluent API? > > > ├── apps > > │ ├── myapp > > │ │ └── components > > │ │ └── resource > > │ │ ├── models.js > > │ │ └── text.html > > │ └── myapp.json > > └── content (title:"foo") > > ├── myapp > > │ └── resource > > └── myapp.json > > The current code for creating a similar tree is in > ResourceBuilderImplTest.treeWithFiles() [1] > > -Bertrand > > [1] > https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/resourcebuilder/src/test/java/org/apache/sling/resourcebuilder/impl/ResourceBuilderImplTest.java > -- Peter Hunsberger
