Hi Roy, In general, JCR namespaces are well suited (the same could said for most other uses of namespaces) for cases where there is a possibility of naming conflicts. In JCR, this generally happens when you have multiple "application" (used broadly) owners overlapping on the same node. When you have relatively common names like "settings" "configRef" (well, maybe that isn't as common), "dialog", etc. this becomes important and especially so when adding a new content model which is expected to be applied to an *existing* content structure as I understand is the case with context aware config.
I'm not sure I understand the part of your question about nodetypes. Namespaces and nodetypes are orthogonal. HTH, Justin On Sun, Nov 13, 2016 at 3:16 PM Roy Teeuwen <[email protected]> wrote: > Hey all, > > Could anyone explain me what the benefit is of using node (or property) > names that contain a namespace, instead of just using nodetypes to force > rules on what can be placed on certain nodes? For example for the context > aware config there has been chosen to call the node sling:settings and the > property sling:configRef, or in AEM they use cq:dialog, cq:template and > cq:editConfig Does this give any advantage over just using a normal node > name with a custom primaryType? I have noticed you can not use arbitrarily > namespaces if they haven't been registered, for example trying to make a > node named custom:node will throw a RepositoryException if custom is not > registered, so they definitely get checked specifically. > > Thanks! > Greetings, > Roy
