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?
If you're looking to create content items which don't have a URL then I'd use blocks.
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?
In my experience, global settings are usually grouped together in a tab on the start/homepage. Then available globally from ContentReference.StartPage.
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.
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.
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:
public class MyBlockUIDescriptor : UIDescriptor<MyBlock>
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.
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.
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: