Logic to create a file structure is very much baked in the code so not possible to influence that currently i.e. specify a different node for jcr:content node of nt:file. So would need some change in Sling
Though IMHO I would change the default logic to use a non referenceable node and avoid relying on user to pass the hint and remember yet another optimization flag. If this change causes issue and user want old behavior a config switch can be provided for that As mentioned earlier changing the default at Oak level is not possible as changing the nodetype semantics would break backward compatibility. While changing the nodetype used in some content structure created at Sling level should have lower impact and something which can be mitigated via config switch Chetan Mehrotra On Mon, Oct 3, 2016 at 5:37 PM, Carsten Ziegeler <[email protected]> wrote: > Chetan Mehrotra wrote >> >> That being said then same argument can be applied to change being done >> in Sling level where for same POST request now results in different >> nodetypes being used. If that is a big concern then we can make use of >> this new nodetype based on some request param. So a user would have to >> specify that nodetype hint if he wants to use the oak:Resource >> nodetype? > > Which should be doable today - same would be true for oak:unstructured > (vs nt:unstructured). So I think there is nothing to be done in Sling. > > Regards > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
