For me the proposed "strict" modifier doesn't seem obvious what it is going to do.
I would prefer a more verbose language with several options and let me choose which one to use. In other words, deprecate the original (ambiguous) "create path" syntax and replace it with a new "[create|update|createOrUpdate] node" syntax that is more clear what is expected to happen. For example: # the original syntax (leave as is for backward compatibility). # This would be similar to the "createOrUpdate" use case without any # attempts to change the primaryNodeType and mixinTypes of already existing nodes create path (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps # ---------------------------------------------------------------------------------------- # ----------------- New replacement syntax ----------------------------------------------- # ---------------------------------------------------------------------------------------- # new syntax that will fail if any of the paths already exist create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps # new syntax that will fail if any of the affected paths do not already exist # and would attempt to change the primaryNodeType and mixinTypes where specified update node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps # new syntax that will create nodes that do not yet exist and update nodes that do already exist # by attempting to change the primaryNodeType and mixinTypes where specified createOrUpdate node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps Regards, -Eric On Fri, Dec 16, 2022 at 6:53 AM Julian Reschke <[email protected]> wrote: > On 16.12.2022 14:38, Konrad Windszus wrote: > > > >> On 16. Dec 2022, at 14:31, Bertrand Delacretaz <[email protected]> > wrote: > >> > >> So in the case of SLING-11736 I have proposed adding a [strict] option > >> to "create path", exemple: > >> > >> create path [strict] (nt:folder) /one(mixin nt:art)/step(mixin > >> nt:dance)/two/steps > >> > >> which activates the improved behavior proposed in that ticket > >> (adjusting primary + mixin types of existing nodes if needed), without > >> changing the behavior for existing code. > >> > >> I think that's inline with the above principles, WDYT? > >> > >> -Bertrand > > > > > > I don’t like this for the reasons outlined at > https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/41#issuecomment-1354488929 > > > > "From an end user perspective deprecating one statement and introducing > a new one with a more concise name is better than just adding the option > strict to existing statements with fuzzy names like “path”: > > > > Also I consider the statement name “create path” very inconcise as > adding properties in JCR is also creating a “path”. > > Since for backwards compatibility reasons users of the existing “create > path” which want to leverage the stricter handling in any way have to > update the statement they should rather replace “create path” by “create > node” instead of adding a new option “strict”. IMHO that makes the > statement also easier to read/understand. > > Feedback from an innocent bystander: if the command already has a poorly > chosen name, it really makes sense to add a new command with precisely > defined semantics and a clear failure mode. > > (so, no to adding "strict" here) > > Best regards, Julian > >
