When you're working on projects that have a lot of pages, it is critical for your site's performance to give a lot of thought about how to structure the websites page tree so your site works as efficiently as possible. Episerver is an enterprise-level solution that has been tested to work with huge amounts of content, however, you may find issues if you try and load several thousand page-types under a single node.
Hierarchy Is Key
On one project, I was asked to do an upgrade for the site in question had a news section. The client released 5-10 news articles a week, they also had about 200+ legacy stories.
After a few years, the 'News' section was a nightmare for content editors to use, they couldn't find content and it took a while for Episerver tree to load. In this case, it was easy to sort news articles by Year and then have an alphabetical folder structure underneath it to allow content editors to easily find the articles they wanted. To re-iterate, containers can be used for storing content like banners, news, configurations, comments, reviews, ratings, menu items, etc..
A container page is an extremely common CMS pattern. Instead of just having content pages, you create a 'container' type that should never be rendered directly by the website.
A container's job is to solely split the hierarchy into more manageable chunks, to make content editors live easier. When working with CMS 7 to create a container, you just define the page as normal, via a page type definition.
It will still need to inherit from PageData but you don't have to have a view for it. The code for a container might look like this:
Using this interface:
What happens if I create a container in my page tree?
So, now you know about container pages when you use them outside of your main page tree it will never be publicly visible.. however... what happens if you want to use one within your 'live' page tree... for example, if a website visitor loads a page under a container they will see the container in the Url:
If they then went ahead and erased the last part of the URL when looking, they would see a pretty dull ugly boring page. If you find yourself with this problem then you have several options.
The quickest and safest is to create a controller for your container that simply re-directs the user to its parent. As a container page is never going to be your start page, this means a user will always see something. You can then use your container page anywhere without having to worry about it
Another option is to define a custom MVC route to hide the container page. Setting up custom routing is a nicer way to solve the problem but is a bit more tricky to set up.
First, you would need to create a PartialRouter. What we can do is intercept all page requests for a certain page type and then modify the outgoing Url to then hide the container from the Url.
Today we've discussed the importance of managing your page hierarchy in order to design a system that has great performance and usability. As long as your container pages sit outside of your page tree, you have no issue.
To add a container page within your site tree, you will need to decide how you will deal with the blank container page that will show in the Url. The quick and dirty way is to create a redirect that redirects a user to the container pages parent, this solves the issue as no one will ever be able to view the page.
The nicer but more complex way is to create a partial router to intercept all incoming results and change the outgoing Url to hide the container part from the Url.