What features would you like to see in Sitecore MVC?

Add native support for Dynamic Placeholders

325 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Jason Wilkerson shared this idea  ·   ·  Admin →

    14 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  · 

        +1 majority of the projects I have worked on need Dynamic Placeholders

      • Anonymous commented  · 

        Request Sitecore to address this as OOTB feature. We have been incorporating multiple variations of solution from 5+ years now. As this is a modular solution from community, we have to consider this on every migration we did for Sitecore. @Sitecore your turn.

      • Anonymous commented  · 

        Ready for this to become a reality!

      • Nick Wesselman commented  · 

        Please please please make this a feature (for Webforms too). It's been too long. When every Sitecore implementation includes some form of this (which they do), you know it needs to be made native. Do something similar to what's already been done in SPEAK.

        http://www.techphoria414.com/Blog/2011/August/Dynamic_Placeholder_Keys_Prototype
        ^^^ August 2011!! Four and a half years. Please make my next update to this article the announcement of native support. :)

      • Andy Thompson commented  · 

        To add an extension for this when adding in dynamic placeholders dyanmically

        I can happily set

        @Html.Sitecore().Rendering("{DE03C1EE-5016-4A66-AE14-70E56AD470AD}", new { DataSource = teaser.ID.ToString() });

        Which sets a sublayout and datasource to the page but I cant see a way to define the rendering and datasource but make it switchable by the user.

        @Html.Sitecore.Placeholder(“teaser”)

        And set the default sublayout and datasource, so it doesn’t require you to go into the experience editor or set standard values

        Something like

        @Html.Sitecore.Placeholder(“teaser”, new { DefaultRendering = "{DE03C1EE-5016-4A66-AE14-70E56AD470AD}", DefaultDataSource = teaser.ID.ToString() });

        The use case is that you might want to add X amount of placeholders using dynamic placeholders, and make it so they can be modified, but set a default value in them if they haven’t already got something set.

      • Martin Davies commented  · 

        Totally appreciate that MVC should be the priority for this, but it would be great if the solution you settle on could include web forms. We have so many legacy applications that would benefit. but we can't easily transition them to MVC.

      • Pavel Veller commented  · 

        Short Version:

        The approach that uses parent rendering unique id has a distinct advantage of adding an extra metadata - the rendering that emitted the placeholder. It enables some very interesting advanced scenarios. The disadvantage is not being able to build placeholder paths by hand for Device Editor's Add Control.

        TL;DR Version

        The hierarchy of components on the page is technically, well, a hierarchy. Page Editor's chromes know it - they are stacked this way: rendering -> placeholder -> rendering -> placeholder. __Renderings XML flattens it out into a list of <r /> elements with a simple @before. The knowledge of who emitted what placeholder is lot. It's now a runtime-only fact. Some advanced scenarios like elastic renderings and rendering transformations and macro components - you guys can watch some of BrainJocks SCORE videos on youtube if you haven't - need that piece of metadata. I would in general like to have it "statically" on the presentation details XML. A placeholder is not recorded in the presentation details unless a component is added to it. Page Editor knows the missing metadata, Device Editor does not. In Decide Editor a component is added to a placeholder path - a very technical way of looking at it. I am not sure how to bridge this gap really.

        If "native support" goes by rendering position (or any other strategy that keeps placeholder paths "simple" and editable but doesn't record the extra metadata about the parent rendering) implementation teams may still continue to use their own implementations. The stock version will then only support multiple instances of the same component but won't enable advanced editing scenarios.

        An alternative way would be to maybe implement placeholder naming as a strategy - a pattern that we will probably see more and more after areas in 8.1 - or otherwise allow to customize it.

        Anyway. Just thinking out load and making sure the "parent rendering metadata" aspect of the UniqueId approach is acknowledged.

      • Michael Robbins commented  · 

        Sitecore SPEAK has a way of handling dynamic placeholders. You basically give each component and ID when you drop it on the presentation details. You can then choose a placeholder from a drop down with {ID}/PlaceholderName.

      • Richard Seal commented  · 

        I have used both the number generation and editor defined - both work, both can be a little confusing if you are not using the experience editor. Maybe if the presentation details screen would calculate what the placeholders are like Sitecore Rocks does and present that it would make it simpler.

        In the experience editor, both would be straight forward to use, although some indication of the placeholder names on screen would help to not create duplicates.

      • Nathanael Mann commented  · 

        In the previous comment - you could autogenerate the rendering parameter if it was added via the page editor

      • Nathanael Mann commented  · 

        +1 for the number strategy, though I have tried to implement this before based on rendering order - it causes issues when renderings are deleted

        I think a much more simple rendering parameters solution may be ok - the default is the code defined one, then users can override for a second / third instance of the same rendering..

        Grab me if you need more info

      • Eduardo Moraes commented  · 

        Once a dynamic placeholder is added it could be named on the fly by the content author. The given name would be used as the key. A suggested default new name (with a sequential number added) could be displayed.

      • Robbert Hock commented  · 

        HI Kern,

        Add a SitecoreHtmlHelper for DynamicKeyPlaceholders or change the standard .Placeholder SitecoreHtmlHelper to support dynamic placeholders.

        Implement a GetDynamicKeyAllowedRenderings to determine the allowed/configured controls for a dynamic placeholder

        Maybe allow 2 strategies or even more to generate dynamickeys: GUId based (like in the Nick Wesselman original example) or Number based so for example it will generate: content-{11111111-1111-1111-1111-111111111111} or content-1/.....

        Maybe some kind of a random string, at least it needs to resolve back the correct placeholder key ;-)

        Maybe others have different opinions about it... then post them here

        regards

        Robbert

      Feedback and Knowledge Base