A collegeau CMS developer asked me a maybe general but very important question the other day. Q; ‘When creating blocks, do you tend to put ‘structure’ markup in block views?’ My answer is it depends!
The Question
I’ve got an EPiServer best practice question, if you don’t mind.
When creating blocks, do you tend to put ‘structure’ markup in block views, put it in the template or is there another solution?
For example:
<section class='text-section'>
div class='column-10 push-1'
<p>This is the block markup</p>
/div
</section>
If we just put the <p> in the block view then it can be used in another page with a different layout (other than ‘column-10 push-1), but then we need to put the ‘structure’ markup in the template making it less flexible.
If we put the whole <section> in the block view then it would need extra options for how the ‘structure’ markup/classes are used, but the template can just contain a content area.
There are pros and cons of both. What do you guys find works best?
The Answer
As we say in dutch; ‘There are more ways that lead to Rome’. And for all there can be a valid reason. There is no such way as the best way for this. Best to know is that Episerver doesn’t force you to use certain HTML markup. In Episerver you can choose to put it in the blockview, the template or customize the rendering. All can be valid. With that in mind I want to share some features which you can keep in mind when you have to make a decision.
AllowTypes
If, for some reason, the amount of blocktypes is growning, an important feature an Episerver CMS developer has to be aware off is that the CMS has the possibility to block the use of certain blocks on certain parts of the website. With the ‘AllowedType’ feature you can make sure a block is never used in an area or part of the website where it doesn’t ‘fit’. Read more on Episerver World.
Besides that the 3 most important features to know more about for this use case are;
Content area renderer
My advice is you start to know about the Content Area Renderers. Here is a link to the Alloy example of it. A Content Area Renderer is what is say it is; a renderer for content areas. With this feature you can manipulate the html output of the rendering of this propertytype and every item (block, page, asset, etc) in it. We have done plenty of more complex examples of whats done in the Alloy website. But the Alloy website is a very good start to learn more about this feature. The Content Area Renderer gives you really a lot of flexibility.
Display templates & PropertyFor
Episerver does also make use a lot of the DisplayTemplates functionality which is part of Asp.net MVC. There are already plenty of blogsposts written about this subject. And an old articile about how propertyfor works written by Joel Abrahamsson is still very valid.
Display Options
Last but not least it’s important to know about display options. An editor can select which display option is used for rendering that block. The display options are available in the Content Area Renderer, so you can use them to create your rendering logic. The default content area renderers also make use of it.
Conslusion
I started this article with the fact that more solutions can be valid. But remember! Every Episerver project (or CMS project in general) starts with a good ‘datamodel’. The process of data modeling is something where you have to find the best balance between, editors flexibility and rendering output. That’s why it’s sometimes valid to re-use the block (f.e. generic for more than one use case and with a smaller HTML footprint for the blockview itself) and sometimes introduce new blocks (f.e. more close to a specific use case and with a bigger HTML footprint for the blockview). Hopefully this article gives you a little of a direction and a good understanding on how flexibel Episerver is on HTML rendering, and still make assure your editors have the right experience as well.
Codevelo.us 