[MGNLCT-11] Register node type for given content type Created: 04/Jul/17  Updated: 04/Jun/18  Resolved: 25/May/18

Status: Closed
Project: Content Types
Component/s: None
Affects Version/s: 0.5.1
Fix Version/s: 1.0

Type: Task Priority: Neutral
Reporter: Ilgun Ilgun Assignee: Hieu Nguyen Duc
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 2.75d
Original Estimate: 2d

Issue Links:
Cloners
is cloned by MGNLCT-37 Update registered node-types Closed
dependency
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Content types foundation
Sprint: Saigon 143, Saigon 144, Saigon 145, Saigon 146
Story Points: 3

 Description   

Node type name will be derived from content type and for now we accept the namespace as 'mgnl'. This will however change in the future and most likely we will have it configurable by user.



 Comments   
Comment by Antti Hietala [ 05/Jan/18 ]

Removing the issue from backlog. Reconsider after Q1 2018.

Comment by Ngoc Nguyenthanh [ 10/May/18 ]
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

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

Comment by Mikaël Geljić [ 18/May/18 ]
  • 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.

Generated at Mon Feb 12 00:36:18 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.