I'm developing a website where I want to use the nested content property to add sections to a page. Some sections will be unique to the page and some will be shared across the site. To add shared content to a list of nested content I would add special doc type with a link to a section node in the tree.
In Umbraco 7 this could be accomplished by making any document types available both in the tree (shared) and in a nested content property. However in version 8, an element type must be created specifically for the Nested content property. This means I would have to create two identical document types to make this work. Obviously this limitation makes the system less flexible.
Any thoughts or background on this limitation would be appreciated, or perhaps a workaround!
Can you explain a little more on how to create nested content in Umbraco 8. I have tried but the Document Type and tab drop-down's are empty. could you provide some steps to achieve it.
I would like to create image slide show with title and description for each image.
I created all individual properties but don't know how combine in nested content.
It was pointed out many times why and when documentation was going to be released.
The v8 release was done to get it out - if you are not comfortable using it, stay on v7. v8 will get better and better for every release, but it was never meant to be in the same state as a 5 year old product, with 14 minor releases and 100+ patch releases.
UPDATE
As pointed out below I got ahead of myself and answered this without reading the question carefully. My answer here is for a basic NestedContent setup and not what the OP asked for. Sorry.
For Doctypes that are to be allowed as Nested Content Elements you need to go to the Doctypes Permission tab and enable the "Is an Element type" setting.
I would create a compostion with the properties, and then use that in either a element or document.
Lets say you want to include imformation about a person somewhere, you create a "Person Composition". Then if you need a "Person" as a document, create a "Person Document" that is composed by the composition - this will then be able to live in the content tree. When you need elements (for like nested content) you create a "Person Element" that you can then use in where needed.
Nested content is just the first editor that uses element type. I would expect to see a lot more of them within the next months (think grid elements etc).
But maybe we could allow both Element and non-element at some point in the future. This may require building 2 versions of the Model, one for each type?
No - this does not make sense. It would clutter your setup.
Nested Content in v7 was more of a hack. The document types where never intended to be able to live as elements on documents. This feature was introduced with v8.
Therefore, the v7-way is and old way of doing something, and will therefore be removed at some point.
You would very rarely have elements and documents with the same properties. Think of elements as a way of building a custom data type. If you want to use shared content, you would still need to create this a content that can be linked to (ie documents) -- I do believe that an "element repository" is in the works, so you may create reusable elements.
I do believe that an "element repository" is in the works, so you may create reusable elements.
I hope so. I was just about to post a comment expressing my desire for this separation of concerns when I saw that sentence .
@Søren Gregersen can you give a quick comparison from a programming persepective what an element is supposed to be/represent? It seems to me like it would act like an abstract class.... something that can't be used on its own without inheriting (or otherwise absorbing) it into a usable class...?
Still not making total sense.
I am trying now with shared composition for both but getting this error:
Failed to build models.
Cannot generate model for type 'heroItemNested' because it is an element type, but it is composed of 'heroItemFields' which is not.
Just feels like I have to duplicate the fields for no reason.
This is going to work only if your composition is an element type. It seems a non element type can inherit an element type but not the other way round.
I run into the same issue. Any better solutions to this problem?
The hacky solution discussed so far with duplicating doctypes, is far from ideal, not even sure it works well.
Also I don't see why non-page nodes (element types) are not allowed in the content tree.
I still haven't seen a solution yet which doesn't require a settings section which is usually made of nodes that are not intended to be pages.
Or pages that are grouped under folder nodes where folders are not pages.
Enable non element types in Nested Content
Hi,
I'm developing a website where I want to use the nested content property to add sections to a page. Some sections will be unique to the page and some will be shared across the site. To add shared content to a list of nested content I would add special doc type with a link to a section node in the tree.
In Umbraco 7 this could be accomplished by making any document types available both in the tree (shared) and in a nested content property. However in version 8, an element type must be created specifically for the Nested content property. This means I would have to create two identical document types to make this work. Obviously this limitation makes the system less flexible.
Any thoughts or background on this limitation would be appreciated, or perhaps a workaround!
Hi,
Can you explain a little more on how to create nested content in Umbraco 8. I have tried but the Document Type and tab drop-down's are empty. could you provide some steps to achieve it. I would like to create image slide show with title and description for each image. I created all individual properties but don't know how combine in nested content.
Thanks in Advance!
I would also love to know how to do this. I'm appalled at the paucity of docs for the new Umbraco 8 stuff.
It was pointed out many times why and when documentation was going to be released.
The v8 release was done to get it out - if you are not comfortable using it, stay on v7. v8 will get better and better for every release, but it was never meant to be in the same state as a 5 year old product, with 14 minor releases and 100+ patch releases.
Hi there, Running into the same issue. Already any thoughts on a workaround?
UPDATE As pointed out below I got ahead of myself and answered this without reading the question carefully. My answer here is for a basic NestedContent setup and not what the OP asked for. Sorry.
For Doctypes that are to be allowed as Nested Content Elements you need to go to the Doctypes Permission tab and enable the "Is an Element type" setting.
-Roger
Hi, this does not really help the OP, since it is pointed out they don't want this solution :)
You're right Søren I didn't read the question very well did I? Sorry. I do like your solution below.
Hi,
I would create a compostion with the properties, and then use that in either a element or document.
Lets say you want to include imformation about a person somewhere, you create a "Person Composition". Then if you need a "Person" as a document, create a "Person Document" that is composed by the composition - this will then be able to live in the content tree. When you need elements (for like nested content) you create a "Person Element" that you can then use in where needed.
Nested content is just the first editor that uses element type. I would expect to see a lot more of them within the next months (think grid elements etc).
Thnx Søren,
Went with your approach.
Thank you Søren, this is the best solution I've seen so far!
And it seems to work with Models Builder as long as your composition is an element type.
But maybe we could allow both Element and non-element at some point in the future. This may require building 2 versions of the Model, one for each type?
No - this does not make sense. It would clutter your setup.
Nested Content in v7 was more of a hack. The document types where never intended to be able to live as elements on documents. This feature was introduced with v8.
Therefore, the v7-way is and old way of doing something, and will therefore be removed at some point.
You would very rarely have elements and documents with the same properties. Think of elements as a way of building a custom data type. If you want to use shared content, you would still need to create this a content that can be linked to (ie documents) -- I do believe that an "element repository" is in the works, so you may create reusable elements.
I hope so. I was just about to post a comment expressing my desire for this separation of concerns when I saw that sentence .
@Søren Gregersen can you give a quick comparison from a programming persepective what an element is supposed to be/represent? It seems to me like it would act like an abstract class.... something that can't be used on its own without inheriting (or otherwise absorbing) it into a usable class...?
Most set-ups also use Re-usable content. So we do still end up having content in the tree which has no route.
...and this is what elements are meant to solve :)
Still not making total sense. I am trying now with shared composition for both but getting this error:
Failed to build models. Cannot generate model for type 'heroItemNested' because it is an element type, but it is composed of 'heroItemFields' which is not.
Just feels like I have to duplicate the fields for no reason.
This is going to work only if your composition is an element type. It seems a non element type can inherit an element type but not the other way round.
OK thanks I feel that composition components shouldn't be a full IPublishedContent type either as they are only parts.
I run into the same issue. Any better solutions to this problem?
The hacky solution discussed so far with duplicating doctypes, is far from ideal, not even sure it works well.
Also I don't see why non-page nodes (element types) are not allowed in the content tree. I still haven't seen a solution yet which doesn't require a settings section which is usually made of nodes that are not intended to be pages. Or pages that are grouped under folder nodes where folders are not pages.
UPDATE - still waiting approval?
is working on a reply...