- Separation of Presentation and Content
- The Basics of Content Management
- The Rules Engine
- The Database Layer
- The User Interface (UI)
- Putting It All Together
- The Proposal
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Basics of Content Management
Al drops by Sam's office. Teri is next door, hears them chatting, and wanders in. Sam tells her to grab a chair and says, "So, who wants to talk content management?"
Sam draws a sketch on the whiteboard (see Figure I-2.2). Teri says his drawing looks like Mark's and accuses him of plagiarism.
)
I-2.2Sam explains his drawing. At the center of any content management system is the actual content, articles. Content can be rendered in all sorts of ways and so presentation is never tied to content. Al is thankful that he took the time to browse that cfc file.
Sam continues, "Articles are just records in a database, that's the easy part. Where it gets tricky is designing underlying data structures so that they are flexible enough to allow data to be used as needed."
Al asks "So why not just store each article in a database table, and then have a screen that allows people to pick from a menu selecting which articles they want displayed on a page, and then render the page dynamically?"
"That won't scale," Teri objects. "If you have hundreds or thousands or even tens of thousands of articles you'd never want to select them individually. You need to group them and allow a group to me selected, if group A is used in a page then articles in group A are displayed."
"Correct," says Sam. "But there is a more important reason to group data. Content management almost always involves some form of access control – restricting or allowing access to data based on security clearance, job, department, membership, or whatever. You'd never want to assign access on a per article basis – you'd do it by group and then put articles in groups."
He walks back to the whiteboard and writes this list:
Article. Actual content
Category. Logical grouping of articles; articles go into categories
Page. A page as seen by the user, made up of one or more categories and laid out as needed
Al asks if an article can be in multiple categories. Teri shakes her head vehemently, and Sam agrees: "It's much too hard to explain that to users. They'll never understand why content is displayed when they remove it from a category, not realizing it is in another. Plus it makes access control an absolute nightmare."
Al suggests, "I guess they could always create additional categories as needed."
As has been discussed, users request pages that are rendered on the fly. Pages contain articles from one or more categories, and exactly what the page will look like will thus depend on the categories included, the articles within a category at the time of the request, and any access control associated with categories.
The discussion moves to articles—what they actually are and how they are stored. Teri explains that there are two basic approaches to data storage:
Highly structured. Define fields for all types of data, store headers body, images, and so on in their own fields.
Free form. Save the whole article as a block of text.
As Teri explains, there are varying degrees between these two extremes, but the basic question to ask is this: Will all content be so consistent in layout that a tight structure can be used, or will content vary so dramatically that a tight structure will get in the way? The group looks through the samples that Maria gave Sam and unanimously agree that content will have to be free form. Sam notes the following:
Data is free form; we will basically store content as a big text field.
This allows greater flexibility but makes applying formatting trickier.
Need to revisit this one.
Al asks about user preferences and how they are stored and used. The group has differing opinions in this area. Teri says that the only way to truly integrate users with a content-management system is to make users and user management part of the core content-management code. This way users can select desired categories, save preferences, and be tightly integrated with the content itself. Sam disagrees, and walks to the white-board again (see Figure I-2.3).
)
I-2.3Sam's diagram suggests that the user system and the content-management system are separate entities that are completely independent from each other. In fact, the underlying data store for users may be an LDAP server, while content may be in a database; there is no requirement that they have anything in common.
Teri disagrees: "They are not as separate as you imply, Sam. If a user sets a preference that says he or she wants Category No. 123, that information needs to be stored somewhere, either with the user or with the content."
They argue back and forth for a while until Sam gives in, kind of. Sam does not want user information stored in the content-management system itself, but user preferences pertaining to content do indeed belong there. So, User No. 10 will have preferences stored along with the content so that when he or she requests specific content, those preferences are taken into account. However, the content-management system will have no idea what a user actually is or who User No. 10 is; that kind of information wouldn't matter at that level. All the content-management system would need to know is that it is User No. 10 who is making the request so it can, for example, filter results appropriately.
Sam updates his whiteboard drawing (see Figure I-2.4).
)
I-2.4Sam's phone rings, and the tone of his voice tells Teri and Al that they'd better be off on the other side of his office door. They gesture and leave, and Sam fires off an email to Vijay while on the phone.