jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "NodeNamingConventions" by AlexanderKlimetschek
Date Fri, 17 Aug 2012 14:12:20 GMT
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.
- 

Mime
View raw message