EPiServer 7 was released recently. We’re accustomed to using a new product version every year so it’s right on schedule. However this one is different. Version 7 is a redesign of a great product. Content editors are empowered with a more intuitive user interface and developers are treated to better ways of building the solution. I’ll save the content editor perspective for a later post and concentrate on the development side.
With EPiServer 7 we’re finally able to move from legacy Web Forms to MVC. Web Forms has never felt the right way to build dynamic web sites. So, we’re now up to date with MVC and Razor markup.
What does this mean for the development team? We achieve a better separation of concerns. View templating is cleaner and more compact. The team will be more productive for sure.
Rendering of content
Previous versions of EPiServer tied a template to a page type. Now we are able to create renderers to be used with multiple models and to vary the renderer according to the context the content is displayed in. Of course we have hacked together similar functionality many times before. It’s a nice thing to be supported by the product.
EPiServer’s Johan Björnfot has written a thorough introduction to content rendering in EPiServer 7.
Page type definitions
The previous versions of vanilla EPiServer CMS made you define the page types using Admin web interface. It’s a pain during both development and deployment. In theory you could add new page properties on a live site using the Admin interface but these wouldn’t be rendered on the pages without deploying new page templates. PageTypeBuilder has been the de facto way of defining page types in EPiServer projects. At Solita we haven’t built a single EPiServer solution without PageTypeBuilder.
EPiServer 7 has built-in support for defining page types with code. Pages are strongly-typed first-class citizens. Hooray! Less dependencies for the solution is always a good thing.
The EPiServer content model has been built around pages. Up until now everything has been a page in the page hierarchy – or a file in the file manager. To reuse content across pages you had to model the shared data as a separate page with no template for rendering. The shared data still lived in the same page hierarchy. The new content model is built on a generic IContent interface. The product ships with page and block content types. Block is a new content type to share and reuse content across pages.
You can find a great and detailed introduction to the CMS 7 content model on Joel Abrahamsson’s blog.
Comparison of CMS 7 Blocks and Composer Blocks.
It seems that one purpose of the CMS 7 Blocks is to replace the EPiServer Composer extension. Unfortunately there’s still a major gap between the new Block model and the previous Composer extension. Composer has support for three different types of blocks: content, layout and personalization. EPiServer 7 has real support only for content blocks. Getting rid of layout blocks is probably the right thing to do with the current trend of fluid layouts and the support for multiple block renderers. I haven’t seen a single reference to Personalization blocks in CMS 7. Personalization was one of the most powerful features in Composer and will be dearly missed if it’s gone.
Composer defaults to page-local Block instances with support to share Global blocks. EPiServer 7 supports shared blocks that are similar to Global blocks in Composer. The page-local Block instances of a Composer solution are not convertible to Local blocks in CMS 7. These are entirely different concepts.
I’m afraid the new Block model will end up a mess on a large-scale site without good governance and a change of habits. Upgrading a Composer site to CMS 7 is not yet supported. There seem to be quite a few obstacles before Composer customers can upgrade to CMS 7.
EPiServer 7 is great. It really is! The developers are treated to modern tools such as ASP.NET MVC and Razor markup. The content model gives us built-in strong typing and clean APIs.
If your site is using Composer I recommend you to wait patiently until EPiServer provides a supported migration path. Blocks aren’t ready for the prime time as a replacement of a full-blown Composer solution. The new Block model is a fresh way of thinking.