How Sitecore and the Modern CMS Follow the Object-Oriented Thought Process
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
As a developer, I had the opportunity to work with a good friend, Matt Weisfeld, author of The Object-Oriented Thought Process, and now we spend a lot of time discussing objects. My career has led me to work with a content management system (CMS) in various well-established formats, and I've found that in general the approach of all of them is the same, regardless of the platform: They focus on the page. Content is loaded into a page from a content repository, design templates are based around the page, and so on.
This methodology has worked for more than a decade, but I've always felt that this approach was forced, based purely on business requirements. From a publishing standpoint, this approach makes perfect sense, but from a development standpoint it feels like a legacy approach. However, pragmatism trumps principle, and I continued developing in the same manner, blissfully unaware that alternative products were gaining popularity in the market, and these alternatives provided a new solution that would appeal to business users who were less tech-savvy, as well as to object-oriented developers like me.
For a while, I'd been hearing about Sitecore from other web developers, as well as in job interviews, discussion forums, and even from employers who were looking to expand into other markets. I didn't get a chance to work with it until about a year ago. I was immediately smitten.
Sitecore probably isn't the first content management system to use this approach, but it was the first to which I was exposed. I've since encountered a few other products that take a very similar approach, but I'm still in love with Sitecore. For simplicity's sake, I'll use Sitecore as my example for the rest of this article, but these ideas aren't necessarily limited to Sitecore.
In my experience, the biggest problem with the page-based approach has always been that it doesn't scale well. To do e-commerce or interact with a CRM, ERP, or some other business system, you need a completely different approach. You can't simply treat a customer profile or a set of product information as more content…can you?
An Object-Based Approach
Instead of thinking of content and data separately, Sitecore treats content as data. This simple paradigm was incredibly liberating to me as a developer, and it resonated with my approach to the rest of my development work. In Sitecore, everything that's displayed (and most of what isn't) comes from data templates. A simple bit of text, a blog, a product catalog—all are derived from data templates.
Encapsulation
Data templates are a collection of typed fields, as well as the methods and rules for interacting with them, defining how the data is stored and modeled in the content tree. The template acts as a class that defines the data and its structure. These templates define rules about the type of data, format of the content, and where the content items they map out can be used. While not quite to the level of encapsulation, the data template is pretty close. The presentation of data is separate from the data itself, and rules can be set up per field to describe where the data comes from and how the content will be validated.
Inheritance
Content items (objects) can reference other content items (composition) and can inherit from other templates, deriving standard values and behaviors from their ancestors. Templates can be treated like anything in the spectrum from interface to concrete class, and can easily be extended by or extend from other templates. Content items can either use default values provided by their parent templates, or override them at the template or item level. Additionally, changes to an item are stored as template deltas, which allow changes to the parent template to be reflected in the child items without affecting the changed fields.
Polymorphism
The display of content items can change, depending on the context in which they are referenced. If they're viewed from a parent item, they can be configured to be rendered one way; but when addressed themselves, they can be rendered in a different way. Templates that inherit from other templates can inherit the parent template's behaviors or override them. Presentation rules inherit from parents, and with a little bit of code can be set up to use the template deltas as well. This means that general content can be rendered at the base template level, and additional content can be rendered at the child content level (or overridden entirely). This design allows for a very powerful and modular approach to displaying content.
Presentation
My instinct when working with other content management systems was always to start looking at layouts first: "What kind of content will I have to display, and how must I arrange it on the page?" In Sitecore, the opposite is true. My first thought now is, "What will the structure of my data be, and how can I model that in Sitecore?" Whereas other content management systems would have me interfacing with a DBMS to create tables to model my data, in Sitecore I can work in the same content tree that the business users use. This is a wonderful thing: Your business users can see an immediate visual model of the data as they're working with it, and you can give them the power to create, edit, update, and publish new data directly!
With the data defined, you can unleash the content authors and editors to work on creating content items—the concrete versions of the templates. The next object-oriented parallel is in the presentation. You define your layout mostly as a canvas on which to render content, similar to a template/skin/theme in a traditional CMS. Then, depending on what content is addressed by the browser and what type of device is addressing the content, the content is rendered according to the configuration and its developed sublayouts and renderings. If you're referencing a URL to an item with children from a print layout, the children can be listed in a way that's friendly to a printer. If you reference one of those children directly from a mobile device, it might display differently. The framework handles the context; the developer just handles the implementation.
Object Orientation in Practice
From a developer's point of view, the Sitecore approach is comparable to other familiar designs. What are the benefits for business users? The biggest benefit is the fact that all the data/content is immediately accessible in an intuitive way. Although the data lives in a database, no special tools are required to access it, and even product data can be readily managed in the same system as marketing content. Marketing and business content all have structure, so the consistency of presentation and format of data are improved. Data becomes far more searchable, including facets for specific parts of the data—not just the content in general. Because it's extremely easy to associate custom metadata to content, you can leverage that metadata with the power of search indexers like Apache Lucene or Solr.
Another benefit to modeling data and content in this way is that templates can serve as a middle ground between business users and developers. No developer should expect a business user to think of things in terms of string, float, integer, and object, but we can talk to them in terms of plain text, rich text, number, link, and so on. This fact allows for easy collaboration between developers or business analysts and business users to model relevant data effectively. It becomes a lot easier to visualize data when it's easily examined in the content tree.
Wrap Up
This type of solution might not be practical for every scale of project. Sitecore isn't economical for small sites, although Umbraco uses a similar model and is a popular open-source alternative to Sitecore. Any similar solution will be a bit more invested in the front end of a project, making it less attractive for smaller projects. The strength is how well these solutions scale to larger projects, where the model really becomes efficient both for development and for business users to maintain the data. Just as in cases where a structured programming approach is more suitable than object-oriented programming, this kind of solution isn't ideal for a simple blog or brochure site, but it's a good tool for a developer or business user to have, especially at the enterprise level. When evaluating solutions, consider whether the content and data would benefit from an object-oriented approach.
References
• Matt Weisfeld, The Object-Oriented Thought Process, Fourth Edition