EPiServer Composer layouts should not replace mark-up

I’ve been using EPiServer Composer (formerly X3) for over a year now. EPiServer Composer can allow you to develop a very nice drag and drop interface for your editors, essentially allowing them to layout areas of new pages as and when they’re created. The temptation here, is to develop a series of functions (droppable objects like controls) which are so generic in nature, that you could allow your editors to layout the entire page. This might seem like a good idea at first, I mean, why limit the control that your editors have? Surely it’ll mean less development effort in the future?!

The problem is that Composer is not template based like ASP.NET is. It works on a per-page basis. Function properties (which includes layout functions) are all stored on a page. This means that it is impossible to give the editors the ability to make changes to page layouts globally.

Composer does have a system for allowing editors to define templates, which are useful if they want to create a series of pages which all have the same layout, however, once a page has been created using a template, all ties to that template are lost. Editing the template will not cascade the layout changes to the pages created from it.

It also has a feature called Global functions, which are functions whose properties are managed centrally, allowing site-wide changes where they are used. The problem here is that global functions do not (for implementation reasons) support layout functions.

No, Composer is much better suited for use in designing smaller areas of the page (the page body for instance where the layout will be different on each page anyway), where the surrounding controls (header, footer, navigation menu etc.) are all hard coded within the ASPX. This gives the developer a measure of control over the more important layouts, as well as the ability to make site-wide changes through simple code changes. As a rule of thumb, use Composer content areas where you might normally have used an XHTML property and Dynamic Content. Essentially Composer does the same job as Dynamic Content, but it’s so much easier for non-developers to use to layout the page.

Another of the reasons using Composer is so attractive, is that allowing pages to be changed without new code, means cutting out complex release management processes in larger businesses. However, if deployment of new code is a time consuming issue, and is something you’re trying to avoid, then consider using an EPiServer unified virtual path provider to allow developers (maybe even editors) to upload new ASPX templates at runtime, rather than flooding your pages with Composer functions where they shouldn’t be used, and potentially losing the manageability of your site.

At the end of the day, if you’re really intent on using Composer to the extreme but need to maintain a certain control over site-wide layout, then there is one suggestion I can make. It can be done using an elaborate system of url providers to point to a single Composer-designed page (a kind of template page) together with functions which fetch data from other pages or an external system, based on the requested URL. The problems with this though, are numerous. The development effort is huge and the performance impacts (unless you implement an equally convoluted caching strategy) will be nothing short of disastrous. I only mention this so that you can consider all possible solutions that might work for your business, but in general I would only recommend using Composer where layouts really do change on a per-page basis.