You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by Apache Wiki <wi...@apache.org> on 2012/08/17 16:12:20 UTC

[Jackrabbit Wiki] Update of "NodeNamingConventions" by AlexanderKlimetschek

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "NodeNamingConventions" page has been changed by AlexanderKlimetschek:
http://wiki.apache.org/jackrabbit/NodeNamingConventions?action=diff&rev1=1&rev2=2

- = Overview =
+ == Overview ==
  Here are some recommendations for naming nodes, that have worked well for us in the context of Sling and other JCR-based applications.
  
  The main goal is to ''keep the transparency of JCR'' - good node names will help make your content structure obvious.
  
  = Node naming recommendations =
  
+ == Nodes ==
  Use all lower case for node names.
  
  Separate words using hyphen (-) instead of underscore (_), e.g. `funky-content`.
  
+ Short unixish names work well, especially at the top of the hierachy, and the [[http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard|Filesystem Hierarchy Standard]] is good inspiration for a JCR content hierarchy.
+ 
+ If several nodes share a common prefix or suffix, it might be a sign that they belong in a folder with a descriptive name. If you have `business-rule-foo` and `business-rule-bar` for example, `business-rule/foo` and `business-rule/bar` probably makes sense, with an additional hierarchy level.
+ 
+ == Properties ==
+ 
  Use camel``Case for property names, e.g. `lastModifiedBy`.
+ 
+ Short but clearly understandable property names are good, don't be too cryptic here. Property names are always the last element of a path, so it's not that bad if they are a bit longer.
+ 
+ == Namespaces ==
  
  Use namespaces with care, they are usually only required for infrastructure code. The `sling:resourceType` property name is a good example, it's a Sling-specific thing and you don't want collisions with a user-defined `resourceType` property.
  
- Do not use the reserved namespaces and prefixes (jcr:, nt:, mix: etc.) for node names that are not predefined by the spec.
+ Do not use the reserved namespaces and prefixes (jcr:, nt:, mix:, rep:, sv:, xml:, xmlns: etc.) for node names that are not predefined by the spec. And don't use namespaces from another library, e.g. sling: in a an application on top of sling.
  
- Short unixish names work well, especially at the top of the hierachy, and the http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard is good inspiration for a JCR content hierarchy.
+ == Node types ==
  
- Short but clearly understandable property names are good, don't be too cryptic here. Property names are always the last element of a path, so it's not that bad if they are a bit longer.
+ Local name starts with an uppercase. For example: `sling:Resource`.
+ (JCR spec is an exception here with node types all lower case, eg. `nt:file`).
  
- If several nodes share a common prefix or suffix, it might be a sign that they belong in a folder with a descriptive name. If you have `business-rule-foo` and `business-rule-bar` for example, `business-rule/foo` and `business-rule/bar` probably makes sense, with an additional hierarchy level.
-