Multiple Child Types in Module Builder for Sitefinity 7.1

Posted by Community Admin on 05-Aug-2018 16:32

Multiple Child Types in Module Builder for Sitefinity 7.1

All Replies

Posted by Community Admin on 26-May-2014 00:00

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!

Regards,
Sitefinity Team

Posted by Community Admin on 26-May-2014 00:00

@Kali

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

Ex:
- Profile
    - Undergrad
        -Student
        - 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.

Posted by Community Admin on 26-May-2014 00:00

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.

 

Posted by Community Admin on 28-May-2014 00:00

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.

Posted by Community Admin on 28-May-2014 00:00

@Kali

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.

 

Posted by Community Admin on 30-May-2014 00:00

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. 

Posted by Community Admin on 04-Jun-2014 00:00

Hi all,

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

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!

Regards,
Kalina

Posted by Community Admin on 04-Jun-2014 00:00

Is there any way it could be "toggled"?...like 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!)

Posted by Community Admin on 09-Jun-2014 00:00

 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...

www.mywebsite.com/.../my-product-detail-page

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

www.mywebsite.com/.../product

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

www.mywebsite.com/.../category-page

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

www.mywebsite.com/.../my-product-detail-page

  

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.

Craig

Posted by Community Admin on 11-Jun-2014 00:00

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

Posted by Community Admin on 11-Jun-2014 00:00

@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.

Posted by Community Admin on 12-Jun-2014 00:00

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.

 Regards,

Antoaneta 

 

Posted by Community Admin on 12-Jun-2014 00:00

WOO HOO ON #3!

Posted by Community Admin on 16-Jun-2014 00:00

Hi Steve and all,

we have modified the backend grid a bit so that the option to edit the parent item is more visible.

You can see a preview here:
1bg32c.axshare.com/

In this example, clicking on "New York" will open a grid with the first child type, in this case "Hotels".
Clicking on link "Edit" next to "New York" will open "New York" for editing.

Hope this works better for your scenario. 

Best,
Kalina

 

Posted by Community Admin on 16-Jun-2014 00:00

@Kali

I like the direction the new Grid is heading.

Posted by Community Admin on 16-Jun-2014 00:00

Kali,

Will we still see the publishing icons in the parent grids?  For example, the round green checkmark for published and so on.  These are great visual indicators.  Otherwise I like the updated grid.  Thanks.

Craig

Posted by Community Admin on 16-Jun-2014 00:00

Craig and Steve,

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

Thanks,
Kalina

Posted by Community Admin on 16-Jun-2014 00:00

Hi Craig,

I confirm that the publishing icons will be visible.

Best,
Kalina

Posted by Community Admin on 16-Jun-2014 00:00

Kali,

We have allot of cases where we create a field in the content type called "Archived" and when this value is true we do not want it to be visible in the filter any more.  Instead we want to create a separate filter that will display the archived items.

On that same note, it would also be nice to switch which view is the default one, to be able to change the default views filter parameters.  In this case, maybe I just want to see all non-archived items in the default view.

Another case I can think of is that a content item could have many states and I want to view for each one.   In this case I could have a field called "State" and the possible values could be "Open", "In Process", "Closed", and "Cancelled" for an Issue log or something.  Here I would like to create a view for each state.

Hope this helps.  Thanks.

Craig

Posted by Community Admin on 16-Jun-2014 00:00

Hi all,

Internally, we are experimenting with two approaches for the content widget and will need your opinion as to which one you'd prefer.

Let's say we have dynamic module with the following hierarchy of content types:
Countries
— Cities
—— Hotels
—— Restaurants
—— Museums
—Resorts
——Bars
...

There are two options as to how the content widget can look:

Option 1: One content widget for the whole hierarchy
wireframes: t7goyt.axshare.com/
In this option, users work with one widget. When they drop it, in the widget designer they see option to select the content type to display from a drop down. Once a selection is made, the filter options change accordingly.

Option 2: Content widget for each content type in the hierarchy
wireframes: t7goyt.axshare.com/
In this option, a content widget is generated for each content type, i.e.: "Countries", "Cities", "Hotels", etc. All widgets are grouped in a section in the toolbox: t7goyt.axshare.com/

We are discussing internally as to which approach will be easier to use since each has pros and cons.

Based on your experience, what option would you prefer ?

Regards,
Kalina

 



Posted by Community Admin on 16-Jun-2014 00:00

I kinda like option 2...I like the idea of clearly separate widgets for each type.  I also like that they're by default in their own category instead of me yanking them out to their own myself (which I do manually anyway)

The blue edit bar structure of <module>: <type> would be missed :)

So I notice here that you have "Selected CitIES" or "Selected CountIES"...instead of the current "One particular <type> only..." does this mean we'll FINALLY be able to just pick some to show instead of needing to categorize everything (bloats the taxa for purely presentation purposes)?

Posted by Community Admin on 16-Jun-2014 00:00

Hi Steve,

to clarify on the content widget filtering. In the case above, if you drop a "Hotels" widget, you will be able to set it to display Hotels:

>> From all cities- that is to say, all Hotels
>> From selected cities - only the Hotels listed under the selected cities
>> From the currently open city - only the hotels from the city currently opened on the page
>> Selected hotels only...  - only selected Hotels

 So basically, you'll be very flexible in regards to filtering content including the option to filter by parent.

Hope that makes sense.

Regards,
Kalina

 

Posted by Community Admin on 16-Jun-2014 00:00

@Kali

  So this is something we don't have no, which we need...and we'll get it in 7.1...yes?  Ability to pick specific content items to render.

IF YES:
...make sure to handle the scenario where if we only pick one, and ContentDisplayMode is set to Master...its gonna render the thing in list mode....god if only the UI exposed that somehow too.

Steve

Posted by Community Admin on 25-Jul-2014 00:00

It looks like #2 was chosen. I've added 2 new types under my existing module and cannot figure out how to display the new types whatsoever. Is there any documentation on this?

Edit....Figured it out, you could really do with warning people of these changes :)



Posted by Community Admin on 29-Jul-2014 00:00

Hi,

Here are the documentation links about this feature. Dynamic content types and Create Travelling Agency site.

Regards,

Nikolay

This thread is closed