What is the best practice for editable setup items?

Vote:
 

There are some items I need to setup globally for my site that I need editors to be able to maintain. These items need to be able to be referenced from other pages in my site since they drive functionality. What is the recommended practice and structure for items that need to be maintained from the content tree, but are not pages. They should not addressable directly but have properties with data needed for that functionliaty. I looked into dynamic data store, but those items do not show up in the content tree and do not have an editing interface out of the box. Do I simply create a folder structure at the root using container pages, and then create a content type for that item that inherits from PageData? Is that the recommended way?

#203679
May 02, 2019 17:24
Vote:
 

Hi Jason,

If you're looking to create content items which don't have a URL then I'd use blocks.

#203680
May 02, 2019 17:28
Vote:
 

What are the advantages vs disadvantages for using blocks in that scenario? Feels odd to do that since its not the ideal editing solution for my content creators. It would be hard to teach them that certain setup items are blocks on the right side of the admin, which is counter-intuitive to their perception of what blocks are used for. Plus there is no UI for them, can you have a block without a controller and view without getting a server error? What have others done in the past? This has to be almost all EPiServer developers have crossed in the past. I doubt they are creating DDS classes for them and having to build their own custom UI to edit them. While that may make sense in some cases for things that are "under the hood", what do you in this case where it needs to be editable?

#203684
May 02, 2019 18:17
Vote:
 

In my experience, global settings are usually grouped together in a tab on the start/homepage. Then available globally from ContentReference.StartPage. 

#203685
May 02, 2019 18:38
Vote:
 

For settings comprised of simple data types, that is how I have done it so far. What I am talking about is lists of things such as cities, states, countries, lookup lists and various complex types with more than just a name that also have media assets tied to them. 

#203686
May 02, 2019 18:47
Vote:
 

For that, sounds like you want both. You would use a block as a property (on the startpage). Editors would still go to the tab on the startpage but all the fields of the block are grouped together with a label.

https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Properties/using-a-block-as-a-property/

#203687
May 02, 2019 18:53
Vote:
 

The advantage of using blocks is that it gives you a content item without a URL and, if the items you're editing need to be used on pages, editors tend to be more comfortable dragging blocks into a page than other pages. You certainly can create a block without a view/controller though, if you want to stop the CMS trying to offer on-page editing you'd need to use an editor descriptor like this to remove that view for your block type:

    [UIDescriptorRegistration]
    public class MyBlockUIDescriptor : UIDescriptor<MyBlock>
    {
        public MyBlockUIDescriptor()
        {
            AddDisabledView(CmsViewNames.OnPageEditView);
            DefaultView = CmsViewNames.AllPropertiesView;
        }
    }

The disadvantage of blocks is that you can't use them to create a heirarchical structure in the way that you can with pages and, as a consequence, it's more difficult to limit the types of blocks which can be created in a given folder.

If you wanted to use pages to represent your data items you'd have the advantage that you could create structures of data and control the type of content in those structures but, if you're storing items like countries you'd need to be careful not to put too much in a given node as performance of the tree in the CMS can be adversely affected if you've got too much content. There are also more properties included on a page by default which may be irrelevant if you're storing just a property or two so blocks would be a more lightweight approach.

#203692
May 02, 2019 19:28
Vote:
 

So it boils down to three choices it seems: use pages, use blocks, or use PropertyList<T> on the start page. All have their strengths and weaknesses, but none of them seem like a very good fit. I almost wish there was an additional content type specifically for this. I like the page approach since I can control types of content and organize it into a tree. The block approach is less appealing to me. The PropertyList approach may work well for things that you do not need to hold a reference to. I am now curious what most people have done in the past now that I have seen the choices.

#203695
May 02, 2019 21:00
Vote:
 

Hi Jason, there are good tips/ideas already from others but I'll add my 2 cents here to.

We've used a page type(s) for different site settings. Basic setup would be something like this:

  • on the site start page have a content reference property that will point to your sites settings page type
    • limit that only the site settings page type can be used here, use the AllowedTypesAttribute here
    • also limit that only users belonging to certain "security" group can edit this property, not all editors should be able to change site settings
    • this way you also get the benefit that when the start page content is changed your site settings don't seem to get updated (assuming you will implement a service to get site settings instead of always getting the start page and reding the settings from there)
      • if you have your site settings on the "start page" it means that every time you change site settings you also change the start page content and cache is cleared for it and same goes for your site settings when content is changes so will be your settings - you get the point, when start page changes you don't know did your settings change or content, so having your settings on its own type / instance makes sure that updating content doesn't "change" your settings and vice versa
  • have your custom site settings page type which contains your various settings
    • implemment a service to get the site settings and register the service with IoC
    • ensure that the site settings is not searchable (depends on your site implementation), not visible in the menu
    • register UIDescriptor, where you disable onpageedit and preview views (see post above by Paul)
    • ensure that it will not have a template
      • we usually have used some custom marker interface like: ITemplateless
        • and then we have a custom initialization module that attaches a handler to the TemplateResolver.TemplateResolved event and if something has resolved a template for the site settings then we set the template for it to NULL
        • have a look at the Episerver Alloy MVC sample site: CustomizedRenderingInitialization and TemplateCoordinator classes
#203739
Edited, May 05, 2019 10:59
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.