A New Website - Featuring EPiServer Composer

This week had quite a noteworthy event - the Go-Live of Intergen's new public website, which I was significantly involved with in terms of development. What made this particularly unique was that it was our first project using EPiServer Composer - a fairly new extension to the core content management system (CMS).

This allows reusable components to be included in pages at the whim of content editors, which allows fewer page templates to be defined. So how does this compare with previous sites build using just the standard EPiServer CMS?

In the past, when developing such websites, our development team would determine the page templates that had to be built in order to deliver the functionality of each page in the site, as well as support different visuals for different sections of the site. This means that pages with similar layout (but different content) could use the same template (referred to as Page Types in EPiServer terminology). If the client required one of these pages to have an additional column or section, this would usually require a separate template to be built. As a result, it would be possible that many templates would be required, some with close similarities to each other.

With the reusable components created for a site using EPiServer Composer, the page templates can be simplified and made more generic. As an example, many sites have a media gallery feature. Traditionally, the gallery would be one template, each image item would be another. If the gallery also supported videos, each video item would need to use a third template.

In Composer, the gallery itself could be a component - which allows it to be placed inside a content block on any compatible page, whether a standard content page or section summary/landing page. This is exactly what has happened with the Intergen site, where an image gallery can be found on a standard content page.

Obviously, there are a few new things to learn when developing with EPiServer Composer. A reasonably good crash-course can be found here (if you're already used to the main aspects of working with standard EPiServer CMS). Here are a few things I also found out through experience on this project:

• Composer elements (content functions and layout functions) are technically defined as EPiServer pages themselves, which are stored in a page hierarchy below a page called something like '[Extension page container]'. All Composer elements in the entire site are stored under that single hierarchy.
• This single page tree is separate from the content pages that use the Composer elements. For global elements, this makes sense; for page-specific elements, they would be better suited to below the page itself. This is something to watch out for when migrating pages via export and import - the Composer structure needs to be migrated with the content.
• Because Composer elements could be potentially used on any page (despite setting composition rules), it is a good idea to keep the CSS classes defined according to the specific component, rather than rely on classes associated with page type. If components are styled differently for different sections of the site, such styles can override the default, but a style should always be defined so that it doesn't appear broken on particular pages.
• For different components that are effectively complex web controls, ensure the CSS class names do not collide, e.g. having general ".item" classes without a parent to distinguish between control, e.g. ".tabbedView .mapView .item".
• Since multiple components can potentially be used on the same page, avoid using (and relying on) HTML element IDs. There should be no CSS style with a '#' (unless it is specifically part of the page's chrome and can only appear once on any page).
• Because of the use of CSS classes for dynamic components, the jQuery JavaScript library becomes very useful - especially from its ability to select elements in the same manner as CSS. No need to rely on HTML element IDs.
• If multiple dynamic components of the same type exist on a page, writing custom jQuery plugins is very useful in separating each component's behaviour so that it doesn't affect the other components.

Meanwhile, feel free to explore the Intergen Blog for other perspectives on this project. Enjoy the new site!