U4-112 - Content Type Editor Enhancements

Created by Morten Christensen 12 Jul 2012, 12:53:32 Updated by Sebastiaan Janssen 11 Feb 2016, 18:49:43

Parent for: U4-133

Parent for: U4-134

Parent for: U4-156

Parent for: U4-157

Parent for: U4-158

Parent for: U4-159

Parent for: U4-160

Parent for: U4-6826

Parent for: U4-6828

Parent for: U4-6829

Parent for: U4-6837

Parent for: U4-6839

Parent for: U4-6876

Parent for: U4-6877

Parent for: U4-6889

Parent for: U4-6890

Parent for: U4-6905

Parent for: U4-6906

Parent for: U4-6911

Parent for: U4-6979

Parent for: U4-7058

Parent for: U4-7119

Parent for: U4-7134

Parent for: U4-7138

Parent for: U4-7140

Parent for: U4-7149

Parent for: U4-7172

Parent for: U4-7173

Parent for: U4-7174

Parent for: U4-7205

Parent for: U4-7212

Parent for: U4-7224

Parent for: U4-7240

Parent for: U4-7241

Parent for: U4-7242

Parent for: U4-7259

Parent for: U4-7281

Parent for: U4-7282

Parent for: U4-7288

Parent for: U4-7292

Parent for: U4-7347

Parent for: U4-7351

Parent for: U4-7363

Parent for: U4-7364

Parent for: U4-7371

Parent for: U4-7449

Parent for: U4-7519

Parent for: U4-7554

Parent for: U4-7641

Parent for: U4-7683

Parent for: U4-7691

1 Attachments

Comments

Jason Liveston 14 Jul 2012, 02:15:09

One of the most helpful packages I use is the embedded content package, hopefully its functionality can be added to the base data types. The ability to have repeatable data types under one data type is very helpful, saving time, effort and keeps site structures much cleaner, no massive sub-nodes needed. An example would be if I need to display twenty features of a product with each feature needing an image, RTE and content picker I would have to build twenty documents under a product. With the embedded content data type I can create a data type with those three data types then the use can create as many features as needed under one section in a document. The embedded content package does have some limitations currently, doesn't support all data types, so that would have to be updated. Thanks Jason


Funka! 18 Jul 2012, 22:11:47

Jason, the use case you describe is what I believe they hope to accomplish with the sub-task called "Tabular Doctypes". In fact I just found this Our forum thread here { http://our.umbraco.org/contribute/releases/490/rfc/33203-Container-Document-Types } which has much more in-depth discussion about this as well as some mockups showing what to possibly expect. I agree that Embedded Content is great to avoid the "sub-node glut" you describe, so I'm excited about a clever way to mask/hide that underlying structure but still having all of the power of individual sub-nodes which do support all data types, rollback & publishing, etc...


Chad Rosenthal 20 Jul 2012, 12:55:48

I believe this is all a feature in an add-on, but would also be nice that when creating tabs, you can have some default text that would display above the doc types. This would allow developers to leave better instructions for content editors.


Funka! 06 Aug 2012, 19:04:15

Chad, now that uComponents is part of the v4.8 core, take a look at the "Notes" datatype which will let you do exactly as you ask.


Chad Rosenthal 06 Aug 2012, 19:30:22

Maybe I'm just blind....but I don't see a 'Notes' datatype in my 4.8 instance. I see a 'no-edit', but that is just an empty datatype. I was more thinking that that the text would go across the full width of the box and be updateable via the tabs property. It would also be nice to have default text appear in fieldsets. In fact, if there was some in fieldsets, then you wouldn't need the 'notes'.


Funka! 06 Aug 2012, 19:48:57

(Sorry, I don't mean to clutter up this YouTrack issue with commentary on this!) Check out this link https://ucomponents.codeplex.com/wikipage?title=Notes&referringTitle=Documentation for info on the Notes datatype... I had been under the impression that uComponents was officially incorporated into 4.8 based on some release notes and/or blog posts I thought I had read somewhere, but now can't find anything anymore to support this claim so I guess I was mistaken. (However, you can always install it yourself I suppose!)


esunxray 20 Aug 2012, 02:16:57

There is better way to do this. You just need to set News as Tabular data no need to set Category as Tabular data. By this way, if one Category node has both Category nodes and News nodes as its children. You can let child Category nodes list at left tree view and child News nodes be shown at right as tabular table.

This way is slight different with original way that Niels Hartvig proposed. By his way, you should set Category as Tabular, then all child nodes includes both child Category nodes and child News nodes only can be list at tabular table.

So, I think my way is more flexible than original way. because it can give user a choice: Show some child nodes(like child Category nodes) at left tree if you don't want it be shown as tabular table.


esunxray 23 Aug 2012, 02:26:08

Or change logic slightly. Let All TDC show in tree even if they are children nodes of any TDC node.


esunxray 12 Sep 2012, 02:57:00

Tabular datatype should support bulk operation like delete, move, copy, change template, publish, unpublish,etc.


Casey Neehouse 13 Sep 2012, 01:01:18

Rather than having a custom type, extend the document type to specify child document types to be hidden from the tree (or shown if you want to go that way), and then also have a dashboard configuration that allows you to add the widgets you want, and even custom widgets. Thus, most of the changes are in the tree rendering, and the dashboard enhancements would be extensible. Setting this up as a Tabular Grid would be restrictive for things such as calendars other creative display methods.


Dan White 14 Sep 2012, 15:29:50

This may already be the plan, but I thought I'd mention it:

The news article mock up (http://our.umbraco.org/contribute/releases/490/rfc/33203-Container-Document-Types) is very simple (4 fields). Will the TDC support more complex docTypes (multi-tabs, properties, etc)? If not, I don't really see it being able accomplish the goal:

"To add even better flexibility to Document Types - which is the very heart of the Umbraco core - we need support for types of data which doesn’t belong in a tree (“Tabular data”) where you’d have a lot of children on one parent. For instance news, blog posts and galleries. Up until now we’ve compensated for this by adding subfolders - for instance “date folders” or “alphabetic folders”, but we need a better build-in core solution."


esunxray 19 Oct 2012, 15:41:58

I want to test tabular data container, when will it be released?


Sebastiaan Janssen 02 Nov 2012, 09:18:22

With the progress of the new UI ("Belle") it makes much more sense to build the document type changes into that as opposed to spending much time now to change the current interface and database.


Jeroen Breuer 11 Jun 2013, 00:07:04

Maybe this issue should be updated since belle is coming closer.


Nicholas Westby 06 Jun 2014, 16:32:02

This is "in progress", but hasn't been touched for 11 months. Are there still plans to support multiple document type inheritance (aka, mixins) via the UI? @sebastiaan ?


Shannon Deminick 27 Aug 2015, 08:41:15

I have changed this issue to be a category/category for 7.4 since 7.4's theme is content type editor enhancements


Jeroen Breuer 25 Sep 2015, 11:26:42

With all the content type editor enhancements coming in 7.4 will it also be possbile to change the master doc type? In some situations I use master doc types for grouping. Since 7.4 will support folders I no longer need some master doc types and would like to change the parent.


Shannon Deminick 25 Sep 2015, 11:31:58

The content type editor enhancements are for the actual editor... not really for the back end logic.

Changing this is a huge task as I'm sure you are aware. It would be a different task/feature to try to support his but considering that a 'parent' doc type is just a composition, you could imagine how difficult it would be to swap a composition.


Shannon Deminick 25 Sep 2015, 11:32:15

In 7.4... we will have folder for doc types, so that should solve your grouping issue


Priority: Normal

Type: Feature (planned)

State: In Progress

Assignee:

Difficulty: Normal

Category: UI

Backwards Compatible: True

Fix Submitted:

Affected versions: 4.10.0

Due in version:

Sprint:

Story Points:

Cycle: