Multiple Child Types in Module Builder for Sitefinity 7.1 - Feature Previews & Betas - Feature Previews & Betas - Progress Community
 Feature Previews & Betas

Multiple Child Types in Module Builder for Sitefinity 7.1

  • Multiple Child Types in Module Builder for Sitefinity 7.1
  • Hi all,

    We’ve been getting a lot of requests to allow the building of Dynamic Modules where a parent content type can have multiple child types. Currently, a parent content type can have one child only, and this is rather restrictive.

    So, we decided to include Multiple Child Types in Module Builder in Sitefinity v.7.1. coming in July (on the place of the planned improvements in related content).

    As a result, you’ll be able to create a content type (say “Locations”) and set it to have two or more child content types (say “Bars” and “Restaurants”). In the backend you’ll be able to created Locations and their relevant “Bars” and “Restaurants” in one section w/o going to other sections or using categories to hack relations.

    We are working on versions for the Backend which will be posted in this forum thread soon.

    What we have not decided yet is how to handle the content widgets for such hierarchical content types. There is a risk that the widget designers might get too complicated once there are many child content types in place.

    So, our question to you is: when you have dynamic content types in hierarchies (say “Locations” and “Bars”), how do you go with creating the pages:

    • Do you create a page for each content type: Locations and Bars and place the respective content widgets on them, or
    • Do you create one page (“Locations”) and place the Locations widget on it while set it to auto generate the child pages (with Bars)

    Other considerations regarding this feature are welcome.

    We look forward to seeing your real case scenarios!

    Sitefinity Team

  • Dropdown for Mode - Automatic, Master, Details

    If Detail selected then a checkbox list to select the types of items to display on this page (actually this could be good for master lists too)

    Separate control templates per type

    Separate details pages per type - although it really depends on the site design this probably is needed.  Honestly 99% of the time I never use the same page to display both master and detail view for any content.


  • @Kali

    ...will we be able to assign multiple children at every level?

    - Profile
        - Undergrad
            - Faculty
        - Postgrad

     ...or whatever

    Oh...and I don't much use the autogenerated functionality on bigger sites...the requirements for a browser and detail view are often too different.
  • Hello Kali,

    Using your example I will try to outline where there is a major limitation for how we use a hierarchical module with the to-date existing functionality of module builder.

     So let's say we have 1 bar and that bar has 10 locations.  As it stands now we have had to wire up this relationship by use of related data fields (both legacy and the new 7.0 approach).

     So I can go in under Content -> Locations and then create new locations.  On a new location and I use a related data selector to assign it to a bar.  Then on front-end widgets I can either use the new extension methods or write my own code using the API to get that relationship to present the data.  The real issue from an organizational standpoint is that backend users potentially are looking at a grid of locations that may (in our case DO) have thousands of locations and no way to hunt down quickly which ones are for a particular bar.  

    There needs to be a better mechanism to  be able to add that related column into the grid for filtering. 

    Now another approach one might say is to just add a related field onto Bars where you assign all locations and manage it that way.  That is plausible, but there are times where you may want to un-assign a location from a bar.  You still need a way to quickly view that location that is not assigned via the locations grid.  The scenario that this would happen in might be when a bar goes out of business and there is the potential that it will be bought by another company.  You want to keep that location around until you know for certain so that you do not re-key all that information.

    Note:  I am using the bar example to help us all stay on the same page of terminology, but the reality is that I have a client that we put a module together that really needed to have 3 child content types.  So in a more complex example we are looking at multiple content types all needed to be able to easily show who their parent is in all administrative views in my opinion.

    It probably also make more sense to people if you replaced bar with restaurant.  You are more likely to see restaurant chains that would have multiple locations rather than a specific bar. with numerous locations.

  • d4164f1e-37c1-6deb-a958-ff0000446526_widgetexample.png


    Here's a good example of the frustrations with the massive one-size-fits-all-super-dynamic-widget-izer

    (see image)
    Module is:
    - Program
         - Rotation
               - Week

    Okay so I have a page...Hematology Home

    On that page I want to put a widget into a pod that lists all the rotations under the hematology program.

    So if I drop the CURRENT autogenerated widget there I can pick Program, select Hematology...but there's two immediate issues

    1) It gives me the Parent program type as a Header on the rotation list...not editable IN the rotation list, I have to go set Visible="False" on the program template

    2) I have no way in that widget UI to set the detail page for the listed rotations...I can only set the detail page for the Programs type...of which I have already kinda said "THIS is the detail page for THIS program".  The annoying fix is to set it TO rotation mode, then drilldown into the advanced settings and tweak the filter to check the parent ID or UrlName or something to the proper program.


  • FYI another odd thing in the above example is that the name of the widget generated in the toolbox is the first content type, not the module name...which is odd. 
  • Hi all,

    and thanks for the ideas! You can see the backend interface for a parent content type with multiple child types here:

    The wireframes illustrate the behavior of the following content type hierarchy:
    - Locations
    - - Hotels 
    - - Restaurants
    - - Events

    In the grid with Locations,
    >> Next to each location, there is Edit option which opens the edit screen of a location;
    >> Under each location, there are quick links to all child types: Hotels, Restaurants, Events.
    >> A click on location (i.e. "New York") opens a grid with child items (Hotels). User can switch to other child types from the drop down on top (next to Hotels) .

    Some of you've requested that the parent (New York) opens on click itself for editing .
    However, in our view it is more common to edit the children they change more often. However, we eased the editing of the parent by making the Edit link more visible .

    Please, review and let us know what you think!


  • Is there any way it could be "toggled"? as an option?

     In my case of Recipes (parent)-> Ingredients (children) it's just messed up functionally

    So the MEAT of the dataItem is in the Recipe...99.9% of the editing is on the recipe.  So when I go to the backend (even now, months later) I intuitively click on a recipe to edit it...but end up on the ingredients list then have to go back, and click Actions->Edit.  The new "Edit" icon is sweet, but I still would click the recipe name I think.

     ...just wishlist anyway :)

     (FYI. dropdown on the child type is a great idea!)

  •  Here are a few suggestions and questions I have for this new feature.  

    First, can we have some sort of bread crumb for navigating these content types in the back-end.  There are many times where I have three levels of content types to the module and by the time I navigate the content to the third level I forget the other levels I was on.    


    Second, will there be one configured dynamic widget per content type or one dynamic content widget to rule them all?  I am OK with one dynamic content widget so long as it is flexible and that I can link to any of the child content types.


    Third, when linking to any of the child content types I would like to specify a separate widget template for each of the content types.


    Fourth, one of the things that annoys me about specifying a detail page for a content type is that people could just go direct to the detail page.  For example...

    someone could just go to the url below, in fact Google will index these urls...

    Ideally it would be nice if the user would get redirected to the parent page as shown below...

    Or even better, the detail page does not show up in the URL at all, as show below...


    And finally, how would URLs work and what would happen if there are two urls that are the same for two different content types?  Would this not be allowed?

    I would love to hear everyone's thoughts on the questions and ideas I have stated above.  Thanks.


  • One more item I would like to mention, will it be possible to add custom filters (that show up on the right in the back-end) for content types using some sort of UI and possibly the ability to set the default filter to display?

    Please let me know your thoughts.


  • @Craig

      I agree with both your last posts...custom filters are such a pain to add now, and any change to *any* model just outright wipes them all out.

  • WOO HOO ON #3!
  • Hello Craig, 

    Thank you for your questions. Please read my answers below:
    1) Breadcrumb - no, it is not planned to have a real breadcrumb but with the new way of presenting parent/child items (shown in the wireframes posted above) and the dropdown navigation we have added, I believe it will not be needed. You will be able to see the type, its child types and you will have the ability to switch between child types;

    2) No, filters are not planned for this release;

    3) The widget will be changed and you will be able to choose different templates as you will have separate widgets for the different content types, it will not be one widget for all types anymore;

    4) the URL's will be unique per content type and when generated they will contain the parent URL in them;

    If you have other questions or concerns please. let us know.




  • Craig and Steve,

    can you provide examples of the filters in backend that you want to be able to achieve ?