Magnolia 6.0 reached end of life on June 26, 2019. This branch is no longer supported, see End-of-life policy.
DEVELOPER PREVIEW
This page describes data source definition of a Magnolia Content type. A data source defines how content type items are persisted.
The Magnolia Content Types module is currently available as a Developer Preview. The full version is still under development.
This developer preview brings several powerful features. Please try it out and feel free to send us your feedback and suggestions based on your experience.
We are working to finalize the module as soon as possible.
Example configuration:
datasource: workspace: tourguides namespaces: mt: https://www.magnolia-travel.com/jcr/1.0/mt autoCreate: true model: nodeType: mt:tourGuide properties: - name: birthday type: Date - name: gender - name: shortBio
datasource
properties:type | optional, default is The type of the data source. If the value is JCR, the definition class must implement JcrDataSourceDefinition. |
workspace | required The name of the JCR workspace to store the content items. When the definition item is loaded, and if there is no workspace registered by the given name and the |
rootPath | optional, default is The root path for content type items in the given JCR workspace. |
namespaces | optional A list of JCR namespace names. |
| A JCR namespace name. When the definition item is loaded, and if the given JCR namespace hasn't been registered yet, the system will register the namespace. The namespace name must comply with the rules for XML namespaces, see https://www.w3.org/TR/REC-xml-names/#NT-NCName, https://www.w3.org/TR/REC-xml/#sec-common-syn. |
autoCreate | optional , default is If set to
|
nodeTypeDefinition | optional The path to an XML file which defines a JCR node type definition. The file must be a Magnolia Resource. When the definition item is loaded, and if the node type defined in the file is not yet registered, the system will register it. (See Using the |
The model
, explained in more detail on the Content type Model definition page, defines which nodeType
is used. The model itself does not define the nature of the node type. In the example above the nodetype
chosen is mt:tourGuide
.
Let's assume that the
mt:tourGuide
nodetype has not been registered yet. How to make sure that the model can utilize it?
There are two approaches.
nodeTypeDefinition
and XML-based node type definition.The example above defines all the JCR parameters in one YAML file. In most cases this is the recommended approach.
Namespace
If you intend to use a JCR namespace that hasn't been defined yet, you can define the new namespace, for example mt
, with the namespaces
property.
Node type
In the above example, assuming that mt:tourGuide
has not been registered yet, the system will automatically register a new node type with the given namespace mt
, and the new node type inherits from the Magnolia mgnl:content
node type.
nodeTypeDefinition
and XML-based node type definitionWith the nodeTypeDefinition
property you can define a path to an XML file to define a JCR node type definition.
Using an XML file allows you to define various JCR namespace and node type definitions. Node type definitions based on an XML file can be more complex than the automatically generated node types, which inherit from mgnl:content
automatically.
Example of an XML-based node type definition:
<?xml version="1.0" encoding="UTF-8"?> <nodeTypes xmlns:mgnl="http://www.magnolia.info/jcr/mgnl" xmlns:mt="https://www.magnolia-travel.com/jcr/1.0/mt"> <nodeType name="mt:traveller" isMixin="false" hasOrderableChildNodes="true" primaryItemName=""> <supertypes> <supertype>mgnl:content</supertype> </supertypes> </nodeType> <nodeType name="mt:tourGuide" isMixin="false" hasOrderableChildNodes="true" primaryItemName=""> <supertypes> <supertype>mt:traveller</supertype> </supertypes> </nodeType> <nodeType name="mt:happyCustomer" isMixin="false" hasOrderableChildNodes="true" primaryItemName=""> <supertypes> <supertype>mt:traveller</supertype> </supertypes> </nodeType> </nodeTypes>
datasource: workspace: happycustomers autoCreate: true nodeTypeDefinition: /content-type-examples/jcr-node-type-files/travellers-node-types.xml model: nodeType: mt:happyCustomer properties: - name: country - name: age type: Double
The XML node type definition resource is loaded only if the XML resource is referenced in the Content type Data source definition of a Content type definition.
Access to JCR workspaces is controlled by role-based access control lists (ACLs).
When the system detects and registers a new JCR workspace from a data source definition, it also automatically updates the superuser
role by adding an ACL for the given workspace and granting read/write permissions for the /
path.
In a production system, if you want to provide anonymous website visitors with (read) access to a specific JCR workspace, you must update the anonymous
role by adding an ACL for the workspace.
For further information please read:
The base DataSourceDefinition interface is agnostic of any data source type. To specify a JCR data source, Magnolia provides the JcrDataSourceDefinition interface and the ConfiguredJcrDataSourceDefinition implementation class.
For DataSourceDefinition the ConfiguredJcrDataSourceDefinition is the default implementation class via type mapping on the XML-based module descriptor of the magnolia-content-types
module.
By default Magnolia expects you to configure properties for ConfiguredJcrDataSourceDefinition to define a JCR data source.
3 Comments
Will Scheidegger
That's great stuff. I managed to define a content type in a name space and a custom workspace – everything worked fine. However, if you have bootstrap data using that namespace and workspace, things will fail miserably.
After manually adding a workspace definition to the module descriptor, Magnolia only complains about the unknown namespace.
So it seems like Magnolia should read the contentTypes definitions first, before bootstrapping anything. Of course this will hardly be possible, if the contentTypes are defined in JCR. Seems like a bit of a deadlock here...
Christoph Meier
Hello Will Scheidegger
I was glad to read the 1st paragraph of your comment. :^)
I highly recommend using YAML based configuration for CTs (in a light-module or in jar file based on a Magnolia Maven module). However, this has no influence regarding your issue.
To work around your issue:
Use the Content Importer module . It works on 6.0, I have just tested it.
Side note:
I first wanted to recommend you to split your "stuff" into two modules:
- m1: contains the CTs
- m2: contains the bootsrap (in bootsrap folder)
Then define appropriate module dependencies. However, this also fails.
Reason:
Bootstraps are executed at install phase, whereas CTs are initialized (and workspaces created) at module startup (hence registry startup) time.
P.S.
Which Magnolia version are you using?
Will Scheidegger
This was with Magnolia 6.0. And yes, splitting things up won't help.
IMO, the Magnolia startup code needs to be adapted: When there repo config is read from the module descriptor files, Magnolia should also check for content type definitions files. OR at least name space definitions in module descriptors should be supported. However this would be a bit of a compromise as it would force us to keep the workspace and namespace definition in the module descriptor and the content type definition.