Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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
The sandbox branch of code is a replacement for Data Module version 1.3.x, is such it works against Magnolia 4.1.x.

=== Installation

  • 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 typeA and typeB) and use the same rootFolder (say /mytypes) for them
  • logout/login to get the submenu entries displayed.
  • go to config:/modules/data/trees/typeA and add configurationClass nodeData and set it to
  • go to config:/modules/data/dialogs/typeA and change value of class to
  • go to data:typeA and if you click on NewItem the selection dialog will popup letting you choose from either typeA item or typeB ... click on desired type, click OK and continue as usual. you should be able to nest the entries as well (e.g. have typeA entry with a child entry of typeB and so on)

=== The changes in classes:

  • (new)
  • (new)
  • (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 typeA and typeB or typeC can have as a parent only typeA, or typeA can't have any other type as a parent, etc.
  • the trees again, since you can use the data:typeA to edit all types that share given rootPath, there is really no need for another tree for just data:typeB
  • surely you can think of some more (big grin)

Next Steps

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)

  • No labels