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: <[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]> ----------------------------------------------------------------
