Anyone who uses the Ektron Content Management System (CMS) should be familiar with smart forms. They provide essential functionality for structuring data and providing consistent formatting across a site. When smart forms are implemented, content authors simply need to fill in the necessary fields when creating content, and Ektron will handle displaying the data in a way that fits the site’s visual design.
However, implementing these smart forms can be somewhat tricky from a developer’s perspective. As web programming standards change over time, different solutions must be implemented in order to ensure that websites function properly for all users. Let’s look at how these evolving standards affect the way developers work with smart forms:
The Old Way: XSLT
Smart forms consist of XML data, which is similar to the HTML code that forms the source of a web page. There are certain markup differences between XML and HTML, and in order to take the smart form data and convert it into HTML, Ektron uses XSLT, or Extensible Style Sheets.
XSLT is a fairly common method of displaying web pages, but it does present some issues for developers. The biggest problem is that it is an older technology that is not really supported by Microsoft anymore. Since they are no longer making any enhancements to their XSLT engines and do not have any plans to improve it, it is beginning to fall by the wayside.
In addition, XSLT presents a higher learning curve for developers. It is case sensitive, which can lead to programming issues that are difficult to debug. In addition, it is somewhat slow, due to a great deal of string processing. While XSLT will probably continue to be used in the near future, it is time to look for a different solution.
The New Way: Content Types
A few years ago, Ektron released a webinar that described a new way of handling smart forms: Content Types. Using this method, Ektron turns the XML data from a smart form into a strongly typed .NET class, which allows for the use of smart forms without needing to use XSLT. Pairing this capability with Microsoft’s XSD Utility, which creates a .NET class from a XML schema file, can provide an environment more friendly to .NET developers.
Ektron has encouraged the use of Content Types, but they have not yet provided any out of the box functionality to implement them. Developers currently need to install the Microsoft XSD utility, and they may also need to work with the Ektron developer community and install some custom enhancements in order to get them working correctly.
In addition, as we’ve worked with Content Types, we’ve found that they do have some issues. One problem that arises is that of optional content. For example, a smart form for a sidebar module might include a graphic, some text, and a button, but the graphic is optional. However, when .NET processes this module, if the graphic is not included, it can cause server errors, since it is looking for data that is not there. We’ve found that we need to write logic into the .NET controls to perform error checks for any missing data in the presentation layer in order to keep any optional content from causing these errors.
We’ve also found that Content Types do not provide a friendly way to display different types of data in a single template. The XSLT engine did not require multiple templates to display different types of data, meaning that one template could be used for a variety of different types of content, such as news articles, blog posts, or landing pages. Since Content Types use different .NET classes, they require different templates for each type of page.
The Diagram Approach to Content Types
As we’ve worked with Content Types, we’ve learned that a good solution for these issues is to create a model class that “wraps around” the Content Type class, centralizing the logic that performs the error checking for any optional content. This cleans up the presentation layer, removing the need to include error checks in every smart form. As a bonus, it also provides functionality for combining fields in a way that makes them easy to display (for instance, “first name” and “last name” fields could be combined into a “full name” field when displaying it on the page), and it allows for easy integration with external databases. This solution provides a great deal of flexibility and extensibility as we implement smart forms on the websites we develop.
Our years of expertise working with Ektron have given us a great deal of understanding of the underlying code that allows Ektron websites to function, and by keeping up with the ongoing developments and updates to the software, we can ensure that we are on the forefront of using this powerful platform to create websites that function optimally, provide a great user experience, and can be maintained by content editors without the need for constant developer intervention. Do you have any questions for us about how to implement Content Types to create smart forms for your Ektron website? Do you want to know more about our approach to Ektron development? Please contact us to speak with a Solutions Engineer, or share any ohter questions in the comments below.
