This page is about the possible extension to data module that is in no way finalized nor supported at the moment. Use at your own risk.
This extension allows for creation and maintenance of multiple different types under the same hierarchy in Data Module as well as using any of the types as a parent/child for any other type existing in same hierarchy.
Current version of the Data module with the extension to support multiple mixed type hierarchies is in the sandbox at http://svn.magnolia-cms.com/svn/community/sandbox/magnolia-module-data-multitype/
The sandbox branch of code is a replacement for Data Module version 1.3.x, is such it works against Magnolia 4.1.x.
- install the module build from the sandbox (just replace your current m-m-data-1.3.jar with the snapshot you build)
- create two different types (let's call them
typeB) and use the same rootFolder (say
/mytypes) for them
- logout/login to get the submenu entries displayed.
- go to
configurationClassnodeData and set it to
- go to
config:/modules/data/dialogs/typeAand change value of
- go to
data:typeAand if you click on
NewItemthe selection dialog will popup letting you choose from either
typeB... click on desired type, click
OKand continue as usual. you should be able to nest the entries as well (e.g. have
typeAentry with a child entry of
typeBand so on)
=== The changes in classes:
- info.magnolia.module.data.dialogs.TypeSelectDataDialog (new)
- info.magnolia.module.data.trees.MultiTypeDataAdminTreeConfig (new)
- info.magnolia.module.data.trees.GenericDataAdminTree (modified)
... you see there wasn't much work necessary to get this started ... there might be more work involved to smooth out all the rough edges
=== What could/should be improved:
- the configuration class should be added to the tree automatically, some for the dialog (might need to add another checkbox to the type creation dialog. Something like "allow multiple types" or similar.
- possibility to define some constrains (like the pot entry could be only
typeCcan have as a parent only
typeAcan't have any other type as a parent, etc.
- the trees again, since you can use the
data:typeAto edit all types that share given rootPath, there is really no need for another tree for just
- surely you can think of some more
Jan Haderka and Bert Leunis had a deeper email discussion about the topic. I attached the summarizing email by Bert as a PDF document (contains screen shots)