This is the fifth post about display options and Episerver.  In today's guide, I'm going to talk about disabling different display options for different views.  At first, you may think this topic is pretty easy, but, unfortunately it's a little bit more complex than first appearances.  When we work with Display Options and Episerver we may want certain blocks to only be rendered in certain views.  

If you only need to display your block one way, like full-screen then life is pretty easy.  Life becomes a lot more tricker when you only want to display a block with a full and half width only but nothing shorted.  

As mentioned in, How To Set A Default Display Option View For An Episerver 10 Block you have a few common-sense approaches to prevent this from happening, trust your content editors to not do something silly, or, write your HTML code to not use the display option tag.  In some of the companies that I've worked for, they have needed to go one step further and lock things down completely.

Can't I Just Filter My Display Options Based On Content Type?

There are two main ways of preventing content editors from adding blocks in the wrong display option sizes.  The best option in terms of usability is to only show the correct display options to the user in the display menu in the editor editor:

If you strip out the invalid views then they'll never be able to set it to display in a silly way in the first place.  As Episerver works with Dojo and all there isn't a built in API to hook into, if you try and go down the route of filtering out the context menu, you will have upgrade issues later on.  

To do this sort of filtering, you need to copy the core Episerver display option.js file, clone it and then write some Javascript to call a web API to get the list of available display options for a block.

 My issue with this approach is that whenever I've modified core files I've paid a price later down the road.  If Episerver change that displays option menu js file, you won't get that chance in your custom code.  When you upgrade and the file changes, your website will suddenly break, which is not ideal!  

For this reason whenever I've implemented this type of functionality for clients I've always worked with the system and the API.  In the other approach, we create a custom validation attribute that prevents the user saving the page if it contains a block set with an unsupported display option.

Should I Disable or Enable Display Options?

When we work with security and permissions there are two approach, block everything and then specifically allow certain things, or, we can allow everything and then disable certain things.  From my experience, most clients only ever need to lock down a handful of blocks and most people are happy to trust content editors.  

Based on that I tend to work in allow all display options, except the ones I specify approach.   To get started we will need an interface.  When we work with Episerver I always recommend using composition over inheritance:

As I've mentioned in the previous posts, when I work with display options I like to use Enums to represent the different views:

To set which display options we want to disable on a block, we can then use this code:

Next up is the attribute code:

The code is pretty simple, we get passed in the content area items, loop through each item, check if the block implements the IDisallowDisplayOption interface. If it does get the display option the content editor is trying to set against it. If it's contained within the DisabledDisplayOptions list, then return false. In this way it's now impossible for content editors to save blocks that have been set with invalid display option views!  To use the new attribute, we simply set it like this:

Now when you try and save your page or block with an invalid display option, you'll see this error:

Obviously the main pain of this approach, is that you have to remember to add the attribute whenever you need it... asides from that enjoy!