Hi Will, You're quite right again. One other thing you can look into is the usage of folders. You maybe define the types customer, supplier and contact as 3 rootlevel types, and allow folders for them. Can you create customer and supplier types at the root level and in a folder under these nodes the contact type nodes? I did not have time to see if that at all works.
The types in the data module can not be arranged and used in a free way. The types must be defined in a strict hierarchy. You cannot use them outside the defined hierarchy. A next step in the development of the module should consider these points: - the base of definition should probably be the rootpath - a menu entry gives access to all nodes created in a specific rootpath - one or more types can be defined for that rootpath - the definition of types should determine if a strict hierarchy must be followed when creating nodes, or if the nodes can be used freely in every desired structure. If anyone runs into another use case for structured data that the current version of the Data Module cannot support, or has any other idea to improve its workings, please put your ideas on this list. A next version can then serve more peoples needs. Regards, Bert > -----Original Message----- > From: [email protected] [mailto:user-list- > [email protected]] On Behalf Of Will Scheidegger > Sent: maandag 28 december 2009 18:01 > To: Magnolia User-List > Subject: Re: [magnolia-user] Data module: hierarchical data > > > Hi Bert > > Thanks for the feedback. I'm afraid I missed something though... > > When I rename the a copied typedefinition (e.g. form employee to > employee2) then nodes I create at this spot will be of the type > employee2 too instead of employee. Now what if you would like to assign > employees to a company or to a department of the a company and you > would like to be able to move an employee from a company to one of it's > departments. Depending on how you do queries or check node types this > would cause problems since at one spot nodes of the type "employee" are > expected and at the other of the type "employee2". > > Ideally one should be able to define types with their dialogs etc. and > then "use" them (as references) in the type structure. And of course > one should be able to use a type multiple times then in that structure. > > I'm currently working on an internal project where we make heavily use > of nested data. If I should come up with a technical implementation of > the above, I'll let you know. > > Regards, > -will > > On 28.12.2009, at 16:50, Bert Leunis wrote: > > > > > Hi Will, > > > > You have a valid point there. The Data Module now expects all > typedefinitions to have unique names. But that is not enforced by the > UI, you can indeed move and copy the type definition nodes. As a > gruesome workaround you can rename the copied node, for example to > employee2. Do that in the config/data/types nodes. Be sure to create a > tree definition with that name too at config/data/trees. Just copy the > definition that exist there for "employee". > > > > I could not repeat the deleting-NPE. Which node did you delete, the > copied or the original Type node? Your problem here can be that the > node types do not share the same rootpath. > > > > Regards, Bert > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:user-list- > >> [email protected]] On Behalf Of Will Scheidegger > >> Sent: maandag 21 december 2009 18:45 > >> To: Magnolia User-List > >> Subject: Re: [magnolia-user] Data module: hierarchical data > >> > >> > >> Oh... and deleting a node type does not seem to work either... It > >> throws a NullPointerException: > >> > >> 2009-12-21 18:43:42,368 ERROR > >> fo.magnolia.module.data.commands.TypeDeleteCommand: cannot do delete > >> java.lang.NullPointerException > >> at > >> > info.magnolia.module.data.commands.TypeDeleteCommand.itemsExist(TypeDel > >> eteCommand.java:119) > >> at > >> > info.magnolia.module.data.commands.TypeDeleteCommand.execute(TypeDelete > >> Command.java:84) > >> at > >> > info.magnolia.commands.MgnlCommand.executePooledOrSynchronized(MgnlComm > >> and.java:173) > >> at > >> info.magnolia.commands.MgnlCommand.execute(MgnlCommand.java:160) > >> at > >> > info.magnolia.cms.servlets.CommandBasedMVCServletHandler.execute(Comman > >> dBasedMVCServletHandler.java:99) > >> at > >> info.magnolia.cms.servlets.MVCServlet.doPost(MVCServlet.java:122) > >> > >> -will > >> > >> On 21.12.2009, at 18:39, Will Scheidegger wrote: > >> > >>> > >>> More data hierarchy questions - heading in a similar direction: > >>> > >>> What if you have the following data types > >>> - customer > >>> - supplier > >>> Now you would like to have a list of contacts (people) for both > types > >> of data, i.e. > >>> - customer X > >>> - contacts > >>> - John Smith > >>> - Jane Smith > >>> - supplier Y > >>> - contacts > >>> - Johnny Walker > >>> - Jack Daniels > >>> - Jim Beam > >>> The contacts should all be of the same type so that you only have > to > >> define a dialog once. Since the "copy" and "move" menu item is > active > >> in the "Types" tree, I tried to copy a type definition from one spot > >> (A) in the tree to an other (B). But when I then try to add a new > item > >> of that type underneath a node of the type "B" the dialog says: "No > >> item types can be added to this type". > >>> > >>> So I thought that there must be a difference between creating a > type > >> somewhere in the types hierarchy or copying it. I checked in the > >> configuration tree: Exactly the same. So I checked in the > >> custom_nodetypes.xml: Again, no difference. > >>> > >>> Can anyone tell me what the difference is between creating a type > and > >> copying it? > >>> > >>> Thanks! > >>> -will > >>> > >>> On 15.12.2009, at 14:32, Bert Leunis wrote: > >>> > >>>> > >>>> Hi Ernst, > >>>> > >>>> The hierarchies in the datamodule exist of hierarchies of > different > >> types. Every type has its own definition and can store its own data. > >> You can allow to have more types in the same rootpath. You can also > >> allow a parent to have multiple types of children. The hierarchy is > set > >> up in such a way that the hierarchy you define is maintained in the > >> tree with the actual data. If you defined type B to be a child of > type > >> A, it should never be possible to have a type B at another place > than > >> as child of a type A. This way you force yourself and/or your users > to > >> always store the data in a predictable way. > >>>> > >>>> You can solve your problem I think by using (sub)folders. If you > >> have a type X in a rootpath, and allow the use of folders, you can > >> store your categories in a folder structure in that rootpath. If you > >> wanted to store type Y also in that folder structure, you can define > >> that type next to type X, and store that in the same rootpath. > >>>> > >>>> If you want to be freed of the limitation of the strict > hierarchical > >> structure as imposed by the Data Module you could consider writing > your > >> own version of it just to allow that. > >>>> > >>>> @ Jan and Boris: if this would be a much wanted or used idea, we > >> might consider adding an extra boolean for a type like 'enforce > >> hierarchy'. If not enforced, types can be all mixed as the users > wants > >> it. > >>>> > >>>> Hope this helps. > >>>> > >>>> Bye, Bert > >>>> > >>>>> -----Original Message----- > >>>>> From: [email protected] [mailto:user-list- > >>>>> [email protected]] On Behalf Of Ernst Bunders > >>>>> Sent: dinsdag 15 december 2009 11:14 > >>>>> To: Magnolia User-List > >>>>> Subject: [magnolia-user] Data module: hierarchical data > >>>>> > >>>>> > >>>>> hello > >>>>> > >>>>> I have a question about the data module version 1.4 and the > >> creation > >>>>> of hierarchical data types. What i want is to create a hierarchy > of > >>>>> categories, so there has to be a child-parent relation between > >> objects > >>>>> of the same type (i.e. 'Category'). > >>>>> > >>>>> Also I would like it if this possible depth of the nesting of > >>>>> categories is not determined by creating a similar nesting in the > >>>>> category data type definition, but rather by rather allow > >> indefinite > >>>>> nesting. This, by the way, is a nice to have. I could live with > >>>>> creating a data type definition for categories that simply nest > >>>>> category types five steps deep or so. > >>>>> > >>>>> Is this currently possible? and if not: what would be the best > way > >> to > >>>>> achieve it? > >>>>> > >>>>> thanks, > >>>>> > >>>>> -- > >>>>> Ernst Bunders > >>>>> Ontwikkelaar VPRO > >>>>> > >>>>> ---------------------------------------------------------------- > >>>>> For list details see > >>>>> http://www.magnolia-cms.com/home/community/mailing-lists.html > >>>>> To unsubscribe, E-mail to: <user-list-unsubscr...@magnolia- > cms.com> > >>>>> ---------------------------------------------------------------- > >>>> > >>>> > >>>> ---------------------------------------------------------------- > >>>> For list details see > >>>> http://www.magnolia-cms.com/home/community/mailing-lists.html > >>>> To unsubscribe, E-mail to: <user-list-unsubscr...@magnolia- > cms.com> > >>>> ---------------------------------------------------------------- > >>>> > >>> > >>> > >>> ---------------------------------------------------------------- > >>> For list details see > >>> http://www.magnolia-cms.com/home/community/mailing-lists.html > >>> To unsubscribe, E-mail to: <[email protected]> > >>> ---------------------------------------------------------------- > >>> > >> > >> > >> ---------------------------------------------------------------- > >> For list details see > >> http://www.magnolia-cms.com/home/community/mailing-lists.html > >> To unsubscribe, E-mail to: <[email protected]> > >> ---------------------------------------------------------------- > > > > > > ---------------------------------------------------------------- > > For list details see > > http://www.magnolia-cms.com/home/community/mailing-lists.html > > To unsubscribe, E-mail to: <[email protected]> > > ---------------------------------------------------------------- > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
