Yepp, so I guess going with 2) is the better option, however this would require something like a add(Resource parent, String childNodeName, Map props) on the resource resolver.
So maybe we go the same route as we did with getParent(), listChildren and add the functionality to the resource resolver but provide convenience methods on the resource which just delegate Carsten 2012/7/6 Bertrand Delacretaz <[email protected]>: > On Fri, Jul 6, 2012 at 11:32 AM, Carsten Ziegeler <[email protected]> > wrote: >> ...I would prefer 1) although that raise some interesting questions, >> especially as intermediate nodes might end up to be persisted in >> different storages... > > Right, so IMO requiring the parent Resource to pre-exist makes things > simpler for us, and less surprising to the user. > > -Bertrand -- Carsten Ziegeler [email protected]
