Configuration Syntax
- Current implementation: Allows register a simple node type with fixed/predefined supertypes. See JcrRegistrationImpl#register
- A power user may want more than that by defining custom super types, mixin, property definition, etc. All of definitions which is supported by JCR.
- Provide as YAML syntax: Seem like we're reinventing the node type configuration by converting xml syntax of node type definition to yaml syntax
- Pros: Bring consistency to the definition mechanism. Easier to read.
- Cons: More work to do. Need to adapt when never changes occurs in the JCR implementation.
- Using the existing XML syntax: Use as we did before. Provide just an "nodeTypeFile" property and point to xml file of node types definition. <nodeTypeFile>/mgnl-nodetypes/magnolia-contacts-nodetypes.xml</nodeTypeFile>
- Pros: Provide for advanced use cases with minimal efforts. Evolution with the JCR implementation by it self. Simpler configuration.
- Cons: Not nicely as YAML syntax.
Technical Detail
- JCR node types - http://jackrabbit.apache.org/jcr/node-types.html
- Registering node types
- Un-registering node types
- API: NodeTypeManager#unregisterNodeType
- If a node is using, need to force delete or do a migration. Mentioned here.
- Renaming node types: Kind of migration.
- Register the new node type.
- Scan the data is using old node types.
- Change the type of nodes to the new node type.
- Un-register the old node type.
- Updating node type definition
- API NodeTypeManager#registerNodeType
- The second parameter is "allowUpdate". When it's turned to "true", updating node type definition should be handled by JCR implementation.
Summary
- In production environment, changing node types definition frequently is not a right thing to do. And it's cost too much.
- In development environment, the changing process is more frequently.
- Conclusion: Need a decision regarding the level of supporting node type definition modifying.
TBC
|
- Renaming/unregistering to be done in a cloned ticket
- Add nodeTypeDefinition property to JRDatasource def (in addition with nodeTypes).
- If this file is configured (e.g. nodeTypeDefinition: /ds/contentTypes/cars-nodetypes.xml), then we just pass the file for registration by JR;
- then we don't do the "simple" registration for configured nodeTypes; they must be provided in that XML/CND file; otherwise log an error.
- if the nodeTypes list is empty; then we should log a warning (because CT consumers will not be able to deduce node-type, e.g. for contentConnector or delivery endpoint)
- If this file is not configured, we use the nodeTypes list and set mgnl:content as supertype for all configured node-types.
Registration to be done via info.magnolia.jackrabbit.ProviderImpl#registerNodeTypes(java.io.InputStream)
—for further updates (MGNLCT-37), we will need to extract reregistration logic from RegisterNodeTypeTask.
|