Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Stephen 767 posts 2268 karma points c-trib
    Nov 12, 2014 @ 17:08
    Stephen
    0

    We need to talk about Compositions

    Hey,

    I am currently working on fixing document type compositions in v7. And I hit some questions that require... community input. Here goes the first one:

    Assume I create

    • content type WithMetaTitle that has a tab named Meta that has a property MetaTitle
    • content type WithMetaKeywords that has a tab named Meta that has a property MetaKeywords
    • content type MyContent that is composed of both WithMetaTitle and WithMetaKeywords
    • and content type MyContent adds property Whatever to the Meta tab

    Of course... we all assume that when editing a content of type MyContent, we'll see one tab named Meta with two properties, MetaTitle and MetaKeywords. So far, so good.

    Question: what-if I edit content type WithMetaTitle and change the tab's name to NewMeta? When I go and edit my content, what's the name of the tab (or is it tabs...)? Where is the Whatever property? What makes most sense from a user's point of view?

    Cheers,
    Stephan

  • Nicholas Westby 1996 posts 6829 karma points c-trib
    Nov 12, 2014 @ 17:14
    Nicholas Westby
    0

    From my perspective, MyContent would still include a composition (namely, WithMetaKeywords) that has a Meta tab, so the Whatever property could stay there (in the Meta tab).

  • Andy Butland 372 posts 2036 karma points MVP 4x c-trib
    Nov 12, 2014 @ 17:18
    Andy Butland
    0

    Most logical to me sounds two tabs:

    • NewMeta - with the MetaTitle field
    • Meta - with the MetaKeywords and Whatever fields
    Andy
  • Matt Brailsford 2933 posts 15509 karma points MVP 7x c-trib
    Nov 12, 2014 @ 17:23
    Matt Brailsford
    0

    +1 Andy

  • Stephen 767 posts 2268 karma points c-trib
    Nov 12, 2014 @ 17:24
    Stephen
    0

    @Andy, @Nicholas: so option 1 would be, do not rename an "inherited" tab as long as it still can inherit from a tab with its name. In our case, renaming WithMetaTitle.Meta to WithMetaTitle.NewMeta does not rename MyContent.Meta - but then if I rename WithMetaKeywords.Meta to WithMetaKeywords.DingDang, it would rename MyContent.Meta too. Makes sense and is consistent...

  • Stephen 767 posts 2268 karma points c-trib
    Nov 12, 2014 @ 17:28
    Stephen
    0

    Derived question:

    • create root type MyContent1, tab MyTab, ppty MyProp1
    • create root type MyContent2, tab MyTab, ppty MyProp2
    • add type MyContent1 as a composition to MyContent2
    • rename MyContent1.MyTab to MyContent1.SomethingElse

    I would assume that MyContent2's tab name changes to SomethingElse too?

    So it's all done by name - soon as tabs with same names are composed, we assume they are related.

  • Andy Butland 372 posts 2036 karma points MVP 4x c-trib
    Nov 12, 2014 @ 17:36
    Andy Butland
    0

    Yes, that sounds sensible to me too.  As you say, once you've made a decision to set up a composition, you've linked the two items, so - in the absence of another matching name as per your first question - renames should cascade down.  

  • James Jackson-South 489 posts 1743 karma points c-trib
    Nov 12, 2014 @ 17:38
    James Jackson-South
    0

    My brain goes straight into classical inheritance mode when I think about this.

    If the properties on the base type are specified in a different tab to the inherited type then the inherited type should have two different tabs.

    MyContent should have two resultant tabs.

    • Meta which contains the composite of inherited property MetaKeywords from base WithMetaKeywords and the instance property Whatever

    • NewMeta which contains the inherited property MetaTitle from the base WithMetaTitle

    Anything else could lead to confusion and some messed up compositions.

  • Morten Bock 1867 posts 2140 karma points MVP 2x admin c-trib
    Nov 12, 2014 @ 20:56
    Morten Bock
    0

    I just wrote a long reply, but I realized that i dont actually know how the composition works exactly.

    If I have the doctypes from the original post:

    • content type WithMetaTitle that has a tab named Meta that has a property MetaTitle
    • content type WithMetaKeywords that has a tab named Meta that has a property MetaKeywords
    • content type MyContent that is composed of both WithMetaTitle and WithMetaKeywords
    • and content type MyContent adds property Whatever to the Meta tab
    Does the MyContent actually have it's own Meta tab, or is it truly inherited? What happens if I explicitly create a Meta tab on the MyContent doctype? Will there be a difference from a database perspective?
  • Phill 115 posts 288 karma points
    Nov 12, 2014 @ 21:18
    Phill
    0

    To start, I find the fact that you use Content Type interchangably with Document Type confusing. In the backed under Document Types there are many references to things like "This Content Type uses as a Master Content Type." So I think that there should be a consensus to stick with a single terminology and not mix them up.

    As for compositions, I think I understand the idea behind this but I'm not sure if I agree with the approach. It's almost like looking for a problem that isn't there or it's a solution for a different problem. I see compositions almost as a way of working with grouped or shared data types and avoiding having to have complex tree's of Document Types. The approach I would recommend would be the ability to create Document Type Elements which would be groups of data types that are created independant of a "Tab" name. This way you could great a "meta" group, that has elements like MetaTitle, MetaKeywords and you could add it to any tab of any Document Type. Changing a tab name wouldn't affect MetaTitle but changing MetaTitle (from maybe text to text multiline) would update all document types that use it. 

    I'm not sure if that makes sense or if I'm totally misunderstanding the purpose of Compositions. Either way I think it would be a handy feature.

    Phill

  • Alain 73 posts 520 karma points c-trib
    Nov 13, 2014 @ 16:41
    Alain
    0


    "Derived question:
        create root type MyContent1, tab MyTab, ppty MyProp1
        create root type MyContent2, tab MyTab, ppty MyProp2
        add type MyContent1 as a composition to MyContent2
        rename MyContent1.MyTab to MyContent1.SomethingElse
    I would assume that MyContent2's tab name changes to SomethingElse too?
    So it's all done by name - soon as tabs with same names are composed, we assume they are related."


    I would have two different tabs: MyTab and SomethingElse. If users want the same tab name, they have to rename explicitly MyContent2.MyTab to MyContent2.SomethingElse. And if at some point they decide to undo the composition, each tab would keep its original name, except if they have explicitly changed (renamed) it.

    Another example could be:

    Content Type: SEO
        - Tab: SEOFields
            * Property: Title
            * Property: Description
           
    Content Type: NEWS
        - Tab: Data
            * Property: NewsSummary
            * Property: NewsContent

    Content Type: BLOGPOST
        - Tab: Data
            * Property: BlogSummary
            * Property: BlogContent
           
    Add type SEO as a composition to NEWS
    Add type SEO as a composition to BLOG

    When creating contents for NEWS and BLOGPOST:

    Content: Blog01
        - Tab: Data
            * Property: NewsSummary
            * Property: NewsContent
        - Tab: SEOFields
            * Property: Title
            * Property: Description

    Content: BLOGPOST01
        - Tab: Data
            * Property: BlogSummary
            * Property: BlogContent
        - Tab: SEOFields
            * Property: Title
            * Property: Description

    What happen if someone renames the tab "SEOFields" to "Data" for the content type SEO?
    All properties would appear in one tab named "Data" for both NEWS and BLOGPOST, wouldn't they?

    Content: Blog01
        - Tab: Data
            * Property: Title
            * Property: Description
            * Property: NewsSummary
            * Property: NewsContent

    Content: BLOGPOST01
        - Tab: Data
            * Property: Title
            * Property: Description
            * Property: BlogSummary
            * Property: BlogContent

    They realize that it was a mistake an rename back the tab "Data" to "SEOFields" for the content type SEO.
    Properties should appear as initially, shouldn't they?

    Content: Blog01
        - Tab: Data
            * Property: NewsSummary
            * Property: NewsContent
        - Tab: SEOFields
            * Property: Title
            * Property: Description

    Content: BLOGPOST01
        - Tab: Data
            * Property: BlogSummary
            * Property: BlogContent
        - Tab: SEOFields
            * Property: Title
            * Property: Description
           
    What do you think?       



    I got the following error In Umbraco 720 Beta 2 when there is a clash between property names in the composition:
       
        Server error: Contact administrator, see log for full details.
        Failed to retrieve data for child nodes undefined

        LOG Error:
            System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> Umbraco.Core.Exceptions.InvalidCompositionException: InvalidCompositionException - ContentType with alias 'T1' was added as a Compsition to ContentType with alias 'T2', but there was a conflict on the PropertyType alias 'p2'. PropertyTypes must have a unique alias across all Compositions in order to compose a valid ContentType Composition.
           at Umbraco.Core.Models.ContentTypeCompositionBase.AddContentType(IContentTypeComposition contentType)
           at Umbraco.Core.Persistence.Repositories.ContentTypeBaseRepository`1.ContentTypeQueryMapper.MapContentTypeChildren[TRepo](IContentTypeComposition[] contentTypes, Database db, TRepo contentTypeRepository, IDictionary`2 allParentContentTypeIds)
           at Umbraco.Core.Persistence.Repositories.ContentTypeRepository.PerformGet(Int32 id)
           at Umbraco.Core.Persistence.Repositories.RepositoryBase`2.Get(TId id)
           at Umbraco.Core.Services.ContentTypeService.GetContentType(Int32 id)
           at umbraco.cms.businesslogic.web.DocumentType.setupNode()
           at umbraco.controls.ContentTypeControlNew.LoadContentType(Int32 docTypeId)
           at umbraco.controls.ContentTypeControlNew.OnInit(EventArgs e)
           at System.Web.UI.Control.InitRecursive(Control namingContainer)
           at System.Web.UI.Control.InitRecursive(Control namingContainer)
           at System.Web.UI.Control.InitRecursive(Control namingContainer)
           at System.Web.UI.Control.InitRecursive(Control namingContainer)
           at System.Web.UI.Control.d__0.MoveNext()
       
    To reproduce the error:

        Content Type: T1
            * Property: p1
           
        Content Type: T2
            * Property: p2

        Add type T1 as a composition to T2
       
        So far everything works properly
       
    Now, if you add a new property named 'p2' to the content type T1 you get the error. You should get a user friendly message error saying that you cannot have two properties with the same name in a composition. So far it is not a big deal. The real problem here is that you can't modify any content type to undo the change. You need to fix it through the database!
     


    Alain   
       

  • Stephen 767 posts 2268 karma points c-trib
    Nov 13, 2014 @ 18:10
    Stephen
    0

    @Alain "What do you think?" => your example makes sense... so when you rename the tab back to "SEO Fields" you want to keep the local "Data" tab. The child "Data" tab would not be renamed because it is a "local" tab that existed prior to being merged with the parent tab (when it got renamed to "Data"). Interesting ;-)

    About the error: can reproduce, workingo n it.

  • Alain 73 posts 520 karma points c-trib
    Nov 13, 2014 @ 19:33
    Alain
    0

    Great! :)

    I have a suggestion regarding the fact that compositions are done through "Checkboxes".
    There is absolutely nothing wrong with it, but normally when users see a checkbox, they understand that it is something you can activate/deactivate, and that normally means that if they change the state of a checkbox, by returning this checkbox to its previous value any change will be undone. That is exactly what happens with "Allowed child node types" checkboxes (just above compositions). You can tick one checkbox and save, and if you change your mind and you untick the checkbox and save, you are back to the previous state.
    In the case of compositions, if you untick a composition checkbox, you are removing one or more properties of a document type, what means that you are deleting the data contained in these properties for all the nodes using this content type. And that could be a lot of data with only one untick!
    My point is (sorry for the long explanation) -> before saving the changes, a message box should be displayed letting users know that they could lose data and they need to confirm the action. This could save some tears ...

  • Heather Floyd 531 posts 786 karma points MVP 2x c-trib
    Oct 07, 2015 @ 14:42
    Heather Floyd
    0

    Hi Stephen, I'm not sure if you are still working on Compositions... but came across this post while having my own issues with them.

    My main concern is Ordering Tabs & Properties. I've found that when I add compositions to certain doctypes, the tabs and property order work as I'd expect, and inexplicably, on others it is inconsistent.

    What I'd expect for Tab Order:

    Tabs can be explicitly set with a Sort Order number. If this is changed, it should apply to all doctypes the composition is on. As stated here: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/53729-tab-order-in-umbraco-711 sometimes this isn't the case.

    In my own experience, I have a Composition called "CompPageSettings" which includes two Tabs: "Page Settings" with an order number of 15 and another named "SEO & Meta" with order number of 90. On most of the Doctypes that use this composition, the "SEO & Meta" tab displays far to the right, but on one (Homepage) is it displaying as the second visible tab. This is in spite of the "Homepage" DocType including other compositions (with Tabs with lower order numbers) and three of its own "local" Tabs with order numbers of 1, 11, & 12. Changing the order numbers - on the local tabs, or on the Composition doesn't alter the order. Also strangely, the tabs are displaying in the proper order on the DocType's "Generic Properties" tab, but on the Content Node itself, they are displaying in a different order.

    What I'd expect for Property Order:

    I'd expect that Composition properties would be at the top of the Tab, and if DocTypes added their own "local" properties onto the same Tab, those would be displayed below the "inherited" properties.

    My experience is once again, inconsistent. In most cases, it seems to behave this way, but in other cases, the Composition Property on a Tab is at the BOTTOM of the Tab. I have a Composition named "CompPageContent", which includes 1 Tab named "Content" and 1 Property on that tab named "PageHeadline". For any DocType I add this to, I then tend to add local properties to that "Content" tab. For many Doctypes, "PageHeadline" remains at the top of the Content tab. For a few, however, it is displaying below the local properties. Also, I can't seem to get it to "move" to the top of that Tab. I have tried shifting the local properties over to another tab, then saving the DocType, then moving them back and saving again, but it didn't change anything.

    I'm unclear about how the order data is stored in the database, but it seems that it isn't getting consistently updated when individual elements change.

    Also, if anyone know how I can "kick" these items into their proper places, I'd be glad of the info.

    Thanks ~Heather

  • Janae Cram 55 posts 385 karma points MVP 4x c-trib
    Oct 07, 2015 @ 15:00
    Janae Cram
    0

    @Heather,

    Regarding property order - I agree with you regarding what you'd expect, that the composition properties would be at the top of a tab and the other additional properties at the bottom, but I have to say that what I would like is to to be able to edit the order of properties so that non-composition properties could appear first if possible. I just like absolutely granular control ;)

  • Heather Floyd 531 posts 786 karma points MVP 2x c-trib
    Oct 07, 2015 @ 17:10
    Heather Floyd
    0

    @Janae - Perhaps what might work is if Compositions don't really have "Tabs" at all - if they just represent little groups of Properties, then instead of checking a box to include Composition Tabs on a DocType, you could actually add a Composition inside the Generic Properties Tab to whatever Tab and location you'd like - almost like its a property it itself...

    @All - So, I managed to solve my initial problem with the following steps:

    1. Backup Database
    2. Run SQL like this:

      UPDATE [dbo].[cmsPropertyTypeGroup]
         SET [sortorder] = 90
       WHERE [text] = 'SEO & Meta'
      GO
      
    3. This fixed some of the problems, but that Homepage was still misbehaving. Luckily, there is only 1 Homepage in the current install, so I copied the data out of the properties on the "SEO & Meta" tab to Notepad, removed the Composition from the Homepage DocType, then Saved.

    4. Next, I noticed that on the "Tabs" area on the "Homepage" Doctype, there was now an "SEO & Meta" tab with sort order 2 displayed. Hmmm.... Interesting. It didn't have any properties, so I deleted it, Saved again, then re-added the Composition, saved again, and NOW it is displaying in the right location. Phew!

    5. I noticed that regarding the "Content" Tab "PageHeadline" displaying at the bottom of the tab, I followed a similar process. First, I moved the "local" properties from the "Content" tab to "Generic Properties", removed the Content Composition, saved, deleted the "phantom" Content tab which appeared on the "Tabs" tab, saved, re-added the Content Composition, then moved the properties back to that Tab, Saved again.

    My theory is that since the "Homepage" type was created early on in my development process. I likely had those Tabs originally on the "BasePage" (parent of "Homepage" - which now has no Tabs or Properties of its own). I decided to move them to separate Compositions, removing them from the BasePage. But perhaps when I removed them from BasePage, they were still "present" as inherited on the child "Homepage" doctype. When I then added the new Compositions to the Homepage, they were essentially "hiding" the original ones, but those original ones were being used for the Sort Order.

    Seems the solution is that when Tabs are being removed from a DocType, the code needs to make sure it is removed from child DocTypes.

    Most Relevant Related Bugs:

    Other Related Bugs:

  • bhagirath pancholi 19 posts 88 karma points
    Mar 09, 2018 @ 13:16
    bhagirath pancholi
    0

    in seo control i put high number(200) so. whenever you composite seo control in pages. seo control will appear right most side(second last).

    i set generic propety control to 201.by that whenever you composite this control. this will appear last. see image you can not ordering in child page.you should reorder in control which you will going to composite

    enter image description here

Please Sign in or register to post replies

Write your reply to:

Draft