Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
Just downloaded the 7.4-beta to test the new content type editor. First thing that scared me is that you can't have inheritence any more in doctypes. You can only use compositions.
What I used to do with my content types is the following :
Create compositions for stuff that I reuse accross multiple doctypes for example seo data.
So we would create a doctype called "Seo data - Composition" which will contain some propertie like title, description, etc on a SEO data tab.
Then I would create a "Base Page" doctype that will have the include the Seo data composition and some general properties like title, hide in navigation, etc..you get the point.
Then I would inherit most of my website doctypes from this page, sometimes with extra properties. This ways I have one base doctype, but have the freedom to have different structure settings or templates.
With 7.4-beta the concept of the master doctype is gone.
You now can only have compositions. So with the previous example that would mean I would have to create all properties again (maybe you use compositions) for each doctype that I would normally inherit from my base doctype.
Also some advantages of the master doctype is that you could write a query for all pages that inherit a certain doctype.
Question to the core team is why the removed the master doctype. This is a widely used concept.
What happens with master doctypes you have from before the upgrade?
I too still use a combination of inheritance & composition in our more recent websites.
inheritance = often have shared (inherited) templates
document composition = shared data for partials used in those templates (e.g. meta tags)
if that makes sense....
The pattern the teams I've been in match what you describe Dave. It sounds like this change would increase the developer burden without any obvious benefit.
I'd love to hear the rationale behind it. Because it sounds like it would be tedious going forward :(
If I understand correctly, can't you do the same with composition?
You would just have a Seo and a Basepage composition doctypes, and then your pages would be composed of both.
I can't remember if compositions can be nested, so your Basepage doctypes could have Seo as a composition, and the your content page could just be composed of the Basepage one?
Yeah that would work, only thing missing would be the "visual representation"
ofcourse it's not logical to show this many-many relationship in a treestructure :)
It's not possible to nest compositions. Have tried that.
As in the checkboxes are missing, or they are there but it's not working?
If a doctype has been composed of compositions, that doctype can not be used on another doctype as composition.
That was my first try to have a workaround
I haven't got to mess around 7.4 yet, it is on my to-do list this weekend. With that said, I'm sad to hear that the inheritance would be taken out. My first concern would be backwards compatibility for sites that get upgraded to 7.4, what happens to the current structure that isn't built this way? Would it break?
I've only just started using compositions in a test environment and even then I use the inheritance structure and have one off doctypes composing, say universal hero options, from a doctype. Benefit of that is not having to re-make those properties over and over, I can just apply the composition.
Another benefit of having inheritance is just the visual structure of quickly figuring out what doctypes are inhering properties from other doctypes. It makes it quick to find things, where as with only compositions you would have to click on the doctype and then check the structure to see what doctypes it is inheriting properties from.
I haven't messed with them enough to know how it handles inheriting from multiple doctypes yet, if you have a doctype that has 3+ parents, depending on the structure needed. I would assume that would get confusing and maybe it's not good to even do that, again I haven't tested it out yet so it is something I'd want to look into.
I'm not really sure why the decision was made to remove the inheritance structure all together for the doctypes? Is there a benefit to this? I will do some more research on it and see what I can figure out because I clearly have a lot of questions and this feels like a big change from how sites have always been structured. I'm not opposed to the change, I just want to make sure it works. :)
I'm not opposed to change either, I encourage it. But at the moment I don't see the benefits yet. Probably because i'm hooked on the master doctype structure. I actually remember times when we didn't have this.
I think it probalby requires rethinking how you structure your doctypes.
But like you mentioned you don't have the overview anymore on which doctypes share which compositions.
There isn't really that much work though using comps. It'd mean that what once was your base doc type will now be a comp doc type instead, and instead of it being a master doc type, on your new doc types, you just check a single checkbox to say "use my base comp doc type". You'd still only create your properties once, and you can update them any time, you just have to explicitly opt in for your new doc types (which you were basically doing before anyway by using the master doc type).
In reality, comps are actually more flexible, as you can remove the base comp reference if you needed to at any point, where as with master doc types, once you have a master, there is no undoing it (without hitting the db).
For the record, I too use a mixture at the moment so will need to change myself, but I don't really see it being a huge shift. And if you were using them before for organizational purposes, doc types now have folders to allow you to do that.
Where base doctypes also came in handy is the following :
On a site we are building now we have this structure in our doctypes :
- Base article
They all the common properties are on the base article (some times with compositions). Each derived doctype can have some extra articles.
If you Zbu models builder it's really easy to do a query to get a list of most recent articles (no matter what doctype they have), because you can query on the base doctype.
With compositions I don't see how this is possible. Or you should have a unique composition that is only used in the base article.
I can't vouch for models builder, or the fact you can use comps on a master doc type currently, but you should know that Umbraco essentially uses comps for the master doc type right now, it's only UI sugar (and consistancy with previous versions) that you can represent them in a nested tree structure so in theory, what was possible before, should still be (apart from the nested comps).
The only real change then would be that you'd just not be able to use nested comps, so in your new concrete doc type, you'd have to check multiple checkboxes for multiple compositions you want to use. You still have the same abilities as before, it's just moved.
Yes... like mentioned already. It probably needs some rethinking on how to build doctypes.
But the new doctype editor is a big improvement.
Always tricky when someone moves your cheese, but I honestly don't see any loss of functionality, in fact, with the ability to enabled / disabled comps, you actually have more functionality than you had before with master doc types.
Whether it makes life easier, I've yet to have the experience with it to decide (my gut is with you, but it's probably just the fear of the new).
I'll have to check out these folders you speak of. Its good to hear that you find it more flexible. There have definitely been times where it is a pain if some changes require a new structure. Reworking that area later is not fun.
I don't mind changing structure for the better though, I think I just really like having the tree structure to see relationships quickly but I'll learn to live without it.
Any idea on backwards compatibility though for sites that you upgrade to 7.4 that only use inheriting vs compositions? I'm going to have to give that a shot and see what happens.
I am excited about the new doc type composer though, it looks pretty awesome! Yay for new things to play with! :)
EDIT: Looks like twitter answered my question about upgrading though. Child DocTypes will remain there but you can't create new ones, you can only do compositions going forward.
@Dave You could create a BaseArticle composition and give Text, News, etc the BaseArticle composition. With ModeldBuilder your models will get a IBaseArticle interface. When you query you can just do .Children<IBaseArticle> to still get all the articles that have that composition.
@morten you can't use nested comps as it would become way too easy to create a circular reference (I believe they supported it originally, but it became way too problematic, so now comp doc types have to be non composite, and can't have a master doc type)
I love nested doc types, it's one of the reasons I really 'took' to Umbraco over other CMS that use composition approaches to Schema.
But to do nested doc types well, you have to really think about it, have several levels of nesting; maybe appreciate principles of inheritence; and this sort of contributes to the fable, you have to build a couple of Umbraco sites before you get it right.
So that's not a great experience for people who are new to Umbraco and perhaps want to build mildly complicated sites; it's a hard principle to grasp first off the bat when everything else is new.
After a while you end up creating deep doctype nesting strategies such as 'Root - Content - Page - LandingPage - News' because you've learned the hard way that, that such an approach gives you the best coping strategy, not necessarily for a one off build, but for supporting and growing an Umbraco build over a long period of time.
It becomes your philosophy, and because you've learned the hard way, your 'go to' doctypes, are your friends, they are awesome and you don't want them to die suddenly overnight in a beta.
But explain these 'learned strategies' to someone new to Umbraco and they think you are insane, or that Umbraco is difficult. Which I think is what HQ are trying to address here.
The general misconception about nested doctypes, is they are about organising doctypes into a sort of folder you don't use;
I've seen people use nested doctypes like this, ie create a doctype called 'Offers Section' then create the Offer doctype as the child; but the Offers Section will have properties controlling what is shown on the Offers section that a single Offer should not inherit, which leads to editor confusion. So the new 'folder' option for organising document types are going to be great for people who use this approach, and makes perfect sense.
For me nested doctypes are more about an inference of type and common properties from the tree structure - particularly with team development, ie telling someone to create a new MembersNewsArticle doctype, it needs to inherit NewsArticle, which in turn inherits Article; and that feels more comfortable and fits in with a developer's inheritance mindset than saying create a new MembersNewsArticle doc type in the NewsArticle folder and remember to tick _content, _articlecontent and _seo compositions.
But it's not a super big difference.
And not everyone who uses Umbraco has come from a development background anyway.
But I'll miss my nested doctype structure friends...
I've been experimenting with a mixture of nested doctypes and compositions on the latest set of builds I've worked on, and alright, it's kind of ok; it's a change of philosophy but it's not a deal breaker. Compositions can be nice and friendly too.
One thing I have found though is the flexibility of compositions has given me a new way to mess things up. (this has turned into a blog post, apologies if you've read this far...)
Basically if I have used a composition on a doc type; ie a ContentComposition that has Title, RichTextArea, and used this across all my document types, and content is imported; and later on I need to add a Summary Text Box to only on one document type, maybe an article, but here is the thing the new Summary needs to be inbetween Title and Rich Text Area, you know because it's better for the editors not to have Title - RichText - Summary;
(well (and I know nested doc types doesn't solve this problem either, it's where both approaches fall down, and it's a niche issue, but once a build...))
...well, the great flexible thing about Compositions is I can create a new composition with the right order, Title - Summary - RichTextArea, and call it my ArticleContentComposition; and Title and RichTextArea 'can have the same' property names and alias as the Title and RichTextArea on my original ContentComposition, so no changes to my templates - awesome it's the obvious thing to do - and I can go to my DocType untick the ContentComposition, and Tick ArticleContentComposition instead, however even though those DocType properties of Title and RichTextArea are called the same thing Alias wise, they are not the actual same property, and entered data into those fields just vanish, just sorta accidentally, the rigidity of nested doctypes prevents you from making this error...
(I felt a bit like an idiot too! Compositions were not my friend - I'm not trying to say compositions are bad because of this, just that this is an unexpected bi-product of the change, a new thing that can happen - but I've learned not to do it again -maybe just need a warning when you untick a composition ?
So to try to avoid the natural progression that might lead you to make this accidental error, wouldn't it be great to have a way to order properties on a document type, when they have originated from a Composition; because then in the above scenario, I would have kept my ContentComposition, and I'd only need the Summary text in my ArticleComposition, and then on my article doc type, I could tick both ArticleComposition and ContentComposition, merge them together, and override the order (think it's alphabetical at present?) to position the Summary Textbox between the Title and Rich text area on the same tab.
You can almost see it might be possible in the lovely new GUI:
So compositions can be used to group and maintain repositories of common sets of properties, single level poly-morphic inheritance! (still sounds developery enough right?) - but then override their order for the way they are presented to the editor to suit the document type they are merged on.
Hmm but then Properties are Atoms, Compositions are Molecules, DocTypes are Organisms. I may not have thought this through; and may just be accidentally suggesting not to use either Nested DocTypes or Compositions :-)
I think it's strange that sorting of inherited properties (whether they be from master doctypes or compositions) is still not supported.
Also, I don't see the value in disallowing composing a document type from a document type that is itself composed of another doctype composition.
It seems like these things were not implemented simply because they would have been too hard to implement. Perhaps we'll get them in Umbraco 8.
I recorded you nasty gotcha about data disappearing when removing composites here http://issues.umbraco.org/issue/U4-7593
Additionally sorting of property types is already logged as http://issues.umbraco.org/issue/U4-6738
@marc I agree with your view on the doctypes being more about an inference of type and common properties from the tree structure. I don't come from a development background and I usually never have any sort of 'folder' type structure in the doctypes just for the sake of having a folder to organize doctypes. but I find that I've never needed this (yet).
Usually the only time I have any sort of "folder" in my doctypes is when I require a folder in the content structure to allow only certain types of nodes (usually without templates) in the content tree. With that setup, I don't actually have my folder doctype as a parent to anything, I just allow a certain doctype below it. That way the child doesn't have any properties on it that are inherited from the parent that it doesn't need. Example:
-Widgets Folder (can only be created under home)
-Widget (can only be created under widgets folder)
With that setup, you need a folder in the content tree but not in the doctypes area I just haven't seen the need from the types of builds I've done in the past.
Playing with this beta more, I can see getting used to building without actually seeing the inherited doctypes in the tree (I'm still not 100% sure why this feature is being removed) although there will be some change to my process in setting up document types. I will miss the rigidity of just creating a child doctype and having it inherit all the properties from the parent (or more ancestors) without having to remember to click all the applicable compositions. I think I'd be happy with the current functionality where we have the best of both worlds. I would like to have my cake and eat it too as the saying goes :)
I love the new doctype editor and I am going to spend lots of time over the holidays building and rebuilding structures and folder trees while the turkey burns, but i do have concerns over upgrades.
If I take the following from a live site
While you could build this structure anew in a 7.4 composite only way, and you would probably get a lot of goodness from that, If this site is upgraded to 7.4 you would be unable to add any new doctypes below content and you could not use content (or detail) as a composite as they are child doctypes.
This would make the site a lot harder to maintain and enhance, if some extra functionality was called for by the client, you would have to build a whole mirror structure of composite types before you could add a new doctype?
TL:DR so forgive me if I'm missing some points or are saying something that has been said aldready.
But in regards to upgrading I just did a simple POC with a nested document type structure on a 7.3.4 which I then upgraded to 7.4.0 - That works just fine.
However as Kevin points out maintaining an upgraded site where some document types are listed in a nested structure and then having to do further development using compositions only maye be a bit confusing. Don't know if it could be an idea to have an option that allows one to use inherited document types if such structure exists after an upgrade perhaps? But when that's said I think that it will probably just complicate things in future development for the HQ since they will need to maintain this scenario while moving forward.
However in my little POC I also tried moving document types that were placed under my "Master" document type into the "Document types" root and it seems to just work like a charm - The document type, which is my textpage still inherits from my original "SEO" composition.
So perhaps it's not that bad anyway? It seems to be quick to restructure the inherited structure into another folder based structure or whatever one desires and then still have the option to easily and quickly make newly created document types make use of the "SEO" composition for instance.
EDIT: Just did some further testing - In the current implementation it's important to keep the "Master" document type, which the other document types used to inherit from. If it's deleted - I did because when I moved the pages into a "Page" folder instead then it did not make sense to have it laying around anymore - But that means the inheritance disappears from the document types that inherited from it, which I guess makes sense. Don't know if it can be fixed that whenever a document type is moved to some other place the inheritance of the "SEO" composition (Or whatever composition) still remains even though the original document type it used to inherit it from is deleted - Changing the relationship in the background somehow.
Just my 2 cents for what it's worth :)
I just had a little play around with the new editor, and feels great with regards to getting something created fast.
I have been a long time fan of compositions over base/inheritance, because it is much more flexible, so I'm happy to see that become the way of the editor. From a developer perspective I see these as interfaces instead of base classes, which in my view works much better. I also hope there is/will be support in the API for querying for doctypes with certain compositions, or at least the option to ask if node.HasType("SEO").
A couple of suggestions, some of which have also been mentioned before:
As others have mentioned, it would be great to have more granular control over how to sort properties from multiple doctypes on merged tabs. I understand the technical challenge of having a drag'n'drop interface, that can potentially change the "SEO" types sorting, while editing the "Text Page" type.
One solution could be something like "field sets" that would group properties together from the "SEO" type. The those properties could not be separated from eachother, but if the properties are in different field sets, then child properties could be dropped in between them.
A simpler approach would be to add a "sort order" field in the "Property settings" dialog, that would allow you to configure you SEO type with gaps in it's own sort order.: "Title: 10, Description: 20" and so on.
Structure at a clance
I see the challenge of instantly knowing which doctypes this doctype is composed of. Here we might take a page out of the Sitecore (buuuhhh) playbook, and display that information in the tree. Something like:
- My Comps Folder
- - SEO
- - Navigation
- - SEO
- - Navigation
- - SEO
That way you can easily spot that "TextPage" is composed of SEO and Navigation.
Conflict error messages
This might just be a beta thing, but if I create a "Title" property on both SEO and Navigation, and then try to compose my TextPage doctype from both, then I just get a server error with a "look at the log" message.
I think it should be possible to catch this during validation, and return a more friendly message to the user saying "You have composed you doctype with conflicting property: Title" (or something similar).
I'm also worried about upgrading an existing website. We're working on a very large project that has close to a 100 doctypes and we use inheritance everywhere. We're also using the Models Builder so all our models have base models. When we're upgrading to 7.4 I would still like to use base doctypes for this current project because switching to composition while we have so many base doctypes will result in very messy code. The Models Builder won't have base models, but interfaces for the new doctypes.
I also reported an issue for this at the Models Builder because if everything becomes an interface some things get more difficult. For example override interface properties: https://github.com/zpqrtbnk/Zbu.ModelsBuilder/issues/40
I'll just toss in my two cents.
To me, compositions mirror interfaces in the OOP world.
Removing base types is like saying we're not going to have base classes in C# anymore. We'll just use interfaces and delegation.
Not that that would be a bad architecture, but there's still tons of use-cases for base classes.
I don't see why we can't have both.
Well, the C# analogy is not precise.
In C# you would use a base class to have shared methods/implementations. That is not possible with doctypes anyway, so in effect, all base doctypes act as interfaces.
The only thing that is missing is the option to inherit "interfaces", so you could do:
IContent : ISeo
MyContent : IContent
and then MyContent would automatically get ISeo.
That you cannot do with the new implementation of doctypes.
The question is if it's to big of a problem to just do :
MyContent : IContent, ISeo
which will achieve the same thing.
I think that interfaces can work pretty well for new projects. But for existing projects base doctypes should still be supported if you want to create new doctypes.
@Jeroen I think it might be better if they could safely be migrated to composition types instead. Taking each ancestor base doctype, and making it a composition type. That way your data structure would remain intact, and you could keep extending it?
@Morten A migration would be a nice idea, but that will be difficult with the Models Builder. We have added custom properties to base classes and you can't do that with interfaces. More info here: https://github.com/zpqrtbnk/Zbu.ModelsBuilder/issues/40
@Morten, I don't agree. Base classes can very well be used for common properties.
Interfaces on the other hand is more like contracts - "I promise I have this property".
I'm guessing it can be done like this?
Which is essentially multi-level inheritance, but I guess the UI doesn't represent it like that visually?
So the question remains, why not keep both?
@Lars-Erik You can use base classes for that, but that does not offer anything that interfaces does not?
In 7.4.0 you cannot nest composition types as in your example. As far as I understand, it is to avoid cyclic dependencies. So you will need to add all the "interfaces" you want, to each of your final doctypes.
Except for the multi level nesting, I see no problem with removing base doctypes.
Of course I'm coming from a typed model perspective.
What base classes offer is the option not to generate concrete properties for each interface for each concrete type.
Also, when doing typed models, you may actually very well want to add behavior to the base classes. (partial classes for the generated models)
This can be done with extensions, but it's not as pretty.
It'll probably iron out some way or the other.
I'll be honest, this thread is super long and I haven't read it all but would like to make something particularly clear:
There is actually no technical change going on here. A 'Parent' doc type is 100% the same as a composition... that's actually what it is. The only difference is that the parentId column was used in the database. We still support this for backwards compatibility sake but we don't support creating new parent/child relations this way in the UI.
The decision is because of a few factors:
To re-iterate: There is no technical change here, it is 100% backwards compatible.
And for those that are scared of upgrading.... Please test this, this is the purpose of releasing a beta. If you don't actually do the tests, we won't know if you are having issues.
So just a new way of thinking.
Sounds like we can actually clean up a bit then.
We've got a few useless base classes only used for organization. :)
I know it's 100% backwards compatible, but we have a project with many base doctypes and switching to compostions is going to generate messy code because the Models Builder won't generate base classes, but interfaces for the new doctypes.
For new projects compositions is just fine, but for older projects I still want to use base doctypes. If it's just a UI thing can we still create base doctypes another way? Is it still possible in code?
I don't see why models builder would be any different for upgraded projects... When you upgrade you will still have parent/child relations, you just can't create new ones.
Please try the upgrade.
I understand from a code point of view there is no change.
But I think the core team is wrong in thinking that people only use it for organizational purposes (aka folders). We actually use as it is intended, and from what I understand from this thread is that a lot of people use it like that.
But I still this is a breaking change in terms of workflow. This will change how people create their doctypes. And there has been no communication about this at all in the blog post about 7.4 beta release.
Also I see it breaking existing packages that rely on the master doctype structure. In uWebshop for example you create custom product types by inheriting the out of the box uWebshop product type. If you don't have the master doctype functionality in 7.4 anymore it will make this package useless.
Also I see people not upgrading to 7.4 on bigger sites because of the lack of this functionality.
Maybe just put it back and remove it in a major version (8.0.0)
I agree that you can accomplish the same (and more) with compositions... for me it's mostly a change of habbits.. ;) .. but to say that the parent/child relations was only used to organize things is a bold statement..!
I can't remember a single site (of more than 100) where i haven't used inheritance of properties... oh well, maybe my first umbraco site.. ;)
@Shannon The problem is that you can't create new ones. Half the project will have base/child relations. The new doctypes don't. That is going to be difficult with the Models Builder.
@ulrich - I did not say the parent/child relations was only used to organize things. I said if you did that, you now have folders for organizing. And again, i'll re-iterate, parent/child relations is technically the same as a composition, we haven't taken that away from you.
@dave - the entire workflow of the new doc type editor is different... if you'd like i can make that listed as a breaking change so it's listed on the download page. I'm pretty sure uWebshop would still work because you can still make your doc type a composition of their's - since that is the same as a parent/child relation. The only reason it might not work is if it is specifically looking at the ParentId... would love to see if people can test these things.
Ok guys, we'll get back to you all, just need to have some discussion based on when/why/how the decision was made. The decision to change the way this operates was made after user group testing and also based on the technical issues we face with multiple compositions, potential issues with circular references in compositions, and generally the very difficult task of dealing with how compositions technically work.
This is why we release alpha/betas, in order to get feedback such as this. It's clear that many of you want a parent/child relation. We'll let you know the outcome of our discussion (though xmas holidays have begun so I might not have a result for you until the NY)
Maybe a config setting can be used for upgraded sites.
So a new install of 7.4 will only allow compositions.
If you do a upgrade this config setting will be set and you can still create doctypes based of a master doctype.
We had several of this settings in the past.
Than the functionality can be removed in 8.0.0
@Dave, I'm not against adding parent/child back, I need to talk to some people about this decision to see if/why/how we can or cannot add it back and I'll get back to you.
I am however against adding another config setting that we don't need.
In the meantime, if everyone can actually test your projects to see what happens, that'd be ace.
I'm not against removing the master doctype functionality, but doing so will break a lot of peoples workflow. And there has been no communication from the Core about it when the beta is released.
So people only start noticing when they use the beta. And not all people try the beta's.
Will try to do some more testing this holiday with upgrade scenario's and maybe some packages like uWebshop.
A "parent content type" in the 7.3 acceptance is just the combination of (a) being a parent in the tree and (b) being part of the composition. So it combines organization and composition. 7.4 tries to separate these two notions, ideally to make things clearer.
It targets the issues that arize when using the tree to "organize" a large number of content types... creating some "placeholder" content types that have no real "content" meaning but just contain or group other types... and then wanting to move things around and that is not possible, because "moving" content types in 7.3 means both dealing with organization & composition.
The restriction on nested compositions exists mainly because when compositions were first introduced, the whole codebase had issues with maintaining them. Nested compositions definitively work - once they have been properly created. And there were many ways to create crazy & failing structures (cyclic graphs, alias conflicts...). There is no reason to rule them out - only we need to ensure we manage them properly.
About generating models and ModelsBuilder: there is an open issue for this, and I plan to work on in Q1 2016. We need to make it easier to manage compositions, override things... and we could very well add an way to indicate that a given type, used in compositions, should be generated as an inherited type and not an interface.
That being said, with 7.3 you would get Children() to get all children of a type that inherits (has parent) from Product... in 7.4 you would do Children() to get all children of a type that implements (is composed of) Product.
So at that point I would say... not being able to represent a parent-child relationship in the tree is probably only "moving the cheese" - but not being able to nest content types is definitively missing.
OK, posting now - still need to understand the impact on some packages (uWebShop...?) and during upgrades...
So, let's keep this discussion going!
So at that point I would say... not being able to represent a parent-child relationship in the tree is probably only "moving the cheese" - but not being able to nest content types is definitively missing.
OK, posting now - still need to understand the impact on some packages (uWebShop...?) and during upgrades...
So, let's keep this discussion going!
As far as I'm concerned, the most important thing to fix is validation of cyclic graphs.
It should be as simple as removing any descendants of the doctype being edited from the composition dialog.
As it stands now, we'll end up with a ton of unnecessary "mixins".
Personally I liked to use a mixture of inheritance and compositions as they both have their strong points - and don't really see any advantage in removing a feature.
I ditto that! They both have their strengths/weaknesses.
I think upgrading a site that uses inheritance would be a pain to maintain and enhance in 7.4 where you couldn't keep the inheritance structure going. That would get pretty hard to maintain seeing as you would have to setup some new compositions just to duplicate doctype properties that already exist and then maintain two things.
I do like the flexibility that compositions give you in just selecting to inherit properties from a doctype, however you may have to select quite a few.
I'm still messing around with this myself, although I'm not coming at this from a developer 'model building' aspect as some others I see on here. I still just don't see the advantage to removing the inheritance feature just yet.
Also side note, I totally up vote this Property Sorting feature, that would be so awesome to actually order the properties that are being added via compositions/inheritance to make it a little easier for content editors.
I would tend to agree with most people on here about using the Parent/Child document types in association with the composites.
Both ways have their merits, and I'm sure someone coming to Umbraco at V7.4 would wonder what all the fuss was about!
We're do use ModelBuilder and Hybrid Framework extensively for all our projects - it speeds up development significantly as well as giving the Strongly Typed properties across the whole project - so if ModelBuilder struggled with composites only then this could potentially have a catastrophic effect on the way we build projects - it would also prohibit upgrading our older sites to the new version. It could also mean having to maintain two versions of Hybrid and ModelBuilder.
I can't see the benefit in allowing inheritance from a composite - most of ours basically act as the tabs on a document, so we have a composite for SEO, one for page images, one for page content and so on. Any additions to the document then can be placed on the appropriate area for that document only and not affect any other document type - and this is where the property sorting feature would be a real bonus as sometimes the document properties come in above the composite properties and it can look a bit weird - the secondary header comes in before the main header is an example that comes to mind!
If we could keep the document inheritance, that would be brilliant - I feel that most people are comfortable working this way and the addition of folders in the document tree will make our settings section even easier to use and understand. I think the thing that's annoyed most people is that it has been sprung on us without prior warning or discussion with the wider community.
Umbraco does keep on getting better though and the guys at HQ are doing some great work.
I've got an update on this for everyone :)
For a 7.4 (minor version) release, removing this feature is an oversight and we understand that it may pose some issues for people especially with regards to upgrades. So we'll be putting this features back, but with a configuration toggle - which by default on new installs will disable parent/child doc type inheritance.
I realize that many of you have used Umbraco for a long time and are used to knowing how parent/child doc types work and how to deal with hierarchical doc types + compositions (which can be confusing). However, from a new user perspective we want to make things very simple. We don't want to have multiple ways to achieve the same thing, which is why by default we simply want developers to just use Compositions.
Property sorting among compositions is another topic, there's been discussions internally on how to achieve this - but this will be a post 7.4.0 feature as we need to get this version out sooner than later.
@Shannon This is great news! Making it a configuration toggle seems like the best solution :-).
So will the UI also support hierarchical doc types?
Nice to hear...Great example of how the core listens to the community. H5YR !!!
That's great news. I'll be using compositions on all the new sites I build, but it's good to know doctype inheritance will still be there for the existing sites I will probably upgrade at some point.
Looks like my "workflow" will remain unharmed:
Where is the configuration toggle documented?
I'm on an Umbraco 7.5 build and even by modifying the generated .udt and re-importing I cannot get any properties to inherit.
@Jeroen ... I see you haven't tested the upgrade yet then ;) Yes, as i mentioned before, even without this config toggle, the UI will still show the inherited doc types the same as before... you just cannot create new ones. With this config toggle, you will also be able to create new ones.
All this passion about compositions and doctype inheritance made me finally build a package I've wanted for a long time.
Behold I give you "Back Office Visualisations" https://our.umbraco.org/projects/backoffice-extensions/umbraco-backoffice-visualization/
Shows all the relations between doctypes and compositions in once nice place.
Thanks to the wonder of having several staff and a tradition that near Christmas we get to work on fun stuff and that we all consider "fun stuff" to be working on Umbraco packages (its not just us is it?) we managed to get this cranked out in just over day.
If you have any more ideas as to what we can show in it let me know but install it on a busy site you have and let me know if you like it. Feedback welcome.
Merry Christmas you lovely people.
Pete and all at Offroadcode.
Nice package Pete !
I bet he hears that a lot
Real funny to see this change. I used doctype nesting as folders only. I used the doctype compositions since it was possible. The nesting always seamed to rigid to me.
Well everybody is used to there own ways I think :P
I think the discussion is a bit off.
We won't really miss classic inheritance with base doctypes.
We'll miss the ability to compose compositions.
The question should really be "when is nested compositions done?".
(Ain't very composite with one level, it's a basic list. ;) )
Please explain, cuz you lost me
Pretty sure he's talking about this: http://issues.umbraco.org/issue/U4-7596
In short, if I create "BasicPage", I can have it composed of "Composition: SEO" and "Composition: Text Page". However, I can't have "Composition: Text Page" composed of "Composition: SEO" and then have "BasicPage" be composed of "Composition: Text Page". The reason I can't do that is that the Umbraco 7.4 beta does not allow you to compose a document type of a composition that is itself composed of another composition.
In other words, compositions are like single-level inheritance. In C# terms, it would be like making all of your classes that inherit from another class also be sealed.
Nested compositions is definitively something that we should support.
In fact, technically speaking, they do work already already. When a content type is a child of another content type, it means (a) there's a "tree" relation between them and (b) the child is composed of the parent. And since you can have nested parent/child, nested compositions have to work.
So we do support a (direct, acyclic) graph of compositions.
However, they have been disabled in the content type editor (ie at UI level) because we were missing some checks, error reporting, etc that were needed to prevent users from creating a graph that would not be direct nor acyclic.
You could create cycles (loops in the compositions), or set compositions that would imply duplicate property aliases on some content types, etc. These situations would just kill Umbraco entirely until you fix them by tweaking the database.
We now need to look into the UI & checks part to assess what amount of work would be required to enable nested compos in a safe way.
Perhaps it would then make sense to have "Composition" as an option in the "Create dialogue" so it's clear in the UI that one is creating a composition and not a regular document type? Basically compositions and document types will of course still work the same but perhaps it would make sense to have different names for it so in the option context menu when right clicking the "document types" section would be
Then the composition type could have a different icon so it would also be easy to distinguish.
Just a thought :)
Merry christmas and happy holidays everyone!
Making the choice up front might give the impression that you cannot change it later?
And then what happens if the doctype is no longer used as a composition on any other doctypes. Will it then revert to a normal doctype?
Good point Morten - Maybe it can lead to more confusion in the end - Just a thought that popped up.
Don't know if it could just be possible to simply change the icon? Since it's the same thing still just with another icon and probably placement in the folder structure the way I'm thinking about at least :)
They're not all that different. You can still create pages using a doctype that is used to compose other doctypes?
You could easily have a TextPage type, and a VideoPage that is composed of the TextPage? And then use both types in your content tree?
Jan, we discussed that... someone said, "when picking compositions I don't want to see all my content types, just those that are to be used as compositions". The correct answer would be: when picking compositions, you don't see the flat list of content types but the actual tree. And you would put all your "to be used as composition" types in a folder.
That way, we don't add another level of abstraction - we just re-use the folder concept.
Hmm, my memory is not what it has been but yes I vaguely recall that. But from a newcomers perspective it might be a bit easier to learn about compositions (document types) if there was an option to simply create a document type to be used as a composition from the context menu (Even though it's in fact just a document type with a different icon).
I don't see why folder would exclude that option since I imagine folders will be used for organizing more things - I think that people will of course probably organize compositions in a compositions folder, document types meant for page content (Document types with templates) in a "Pages" folder and document types meant for reusable content elements in an "Elements" folder for instance.
Maybe even a "Partials" folder for document types that are partials when being used together with a 3rd party package like nested content for instance.
And many more ways depending on how people use their building blocks for the sites they're doing. Perhaps some people will also create folders pr. site if they're going to host multiple sites within the same installation for some reason.
Just my 2 cents - I like the way it works currently and with nested compositions coming I'm very happy with the current and upcoming state of things.
Looks like inherited documenttypes are back :-) https://github.com/umbraco/Umbraco-CMS/commit/e509099cdbfb4fbb88835b6a3806d115155bc18a
Hmm in the comments it says "This feature will be deprecated in v8" and "Inherited document types will not be supported in v8.". I'm currently working on a big project on 7.3 and I'm happy that we'll be able to upgrade to 7.4 because it also supports inherited documenttypes, but it's possible that one day this project will also be upgraded to v8 (because we want NuCache).
Is there a way that we could also support this in v8?
v8 is a long time away and comes with lots of it's own breaking changes. Please don't take the notes in the core code as what is actually going to happen. You'll be notified on the tracker if we decided to remove this functionality. It will probably remain for v8.
ahhh... i see it's a note in the config - this hasn't been reviewed and pulled in yet... again, best not to believe notes in the core until things are merged.
Thanks for the update Shannon. Maybe I shouldn't read PR comments ;-).
Just tested Umbraco 7.4 beta2 and really happy to see that inherited Document Types are back. Especially since beta2 also has the Models Builder in which it can be useful :-).
There was a small refresher of this discussion on slack today. I'll summarize here and on the tracker for record's sake.
The thing is you can't compose a type that has been composed. So any base type cannot be given new compositions the moment you've derived it.
What's stopping us from being able to do it from the UI is that HQ haven't discovered a friendly enough feedback when you create cyclic references yet.
I just skimmed this thread, and I also found this duplicated issue that isn't linked to any duped issue:
The latter has a really good suggestion from @andybutland on how to solve it.
In any case, both show that there's a real need to keep flexible inheritance, although we are able to make due with the current state.
I checked the errors from the .net compiler for reference. Here's the exceptions it'd generate:
Circular base class dependency involving 'Class1' and 'Class2'
Inherited interface 'Interface1' causes a cycle in the interface hierarchy of 'Interface2'
Dunno if maybe "Doctype B is already composed of Doctype A, so Doctype A cannot be composed of Doctype B" might be a clear enough message. Given we're in a browser, a link to wikipedia's article on cyclic references could be added as a bonus. ;)
I for one hope we're looking at a shorter discussion this time, and that this'll be fixed sometime before v8.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted