Eval Criteria # 1

What is the built-in content model?


    In college, I read a textbook about communication that said:

    There is no opposite of communication. You can’t not communicate anything because even the absence of communication in itself communicates something.

    The same is true of a content model. A CMS can’t not have a content model. If it stores content in any way (which it would have to, being a “CMS” and all), then it has to store it according to some rules and structure, no matter how simplistic.

    Consider a wiki. The most basic wiki in the world has two fields: (1) a title, and (2) a body of text.

    Simple as it is, a wiki has content model. What you type in the @attr:Title field is the…title, and what you type in the @attr:Body field is the…body. The title isn’t the body and the body isn’t the title, and we know this because there’s a declared model behind it. Simple as it is, those two things are distinct, named attributes.

    We’ll call this the @term:"built-in model”. This is the model the CMS uses internally, and enforces at some level.

    It’s common for most systems to require every object to have a @attr:Name or @attr:Title attribute. Often, every content type gets that by default. Many systems will also have another text field for @attr:Body or @attr:Content or @attr:Text. While it stores characters just like the @attr:Title it’s generally a larger field, accommodating more text, such as a raw textarea or a rich text editor.

    The Default Editorial UI Often Reflects the Model

    The easiest way to discuss a content model is to visualize the editorial interface, because, in most cases, all the attributes of a built-in model are reflected in the user interface (UI).

    In addition to the @attr:Title and @attr:Body, the Movable Type interface above also shows some built-in attributes that might get classified as “metadata,” or “data about data,” which we’ll talk about in the next chapter. These are attributes such as:

    • @attr:"Publication Status”
    • @attr:"Publish Date”
    • @attr:"URL Segment” (“Basename” in the image above)
    • @attr:Categorization
    • @attr:"Change Note/Comment”

    These are properties that will never display to the public – so they won’t be directly consumed by a human – but which exist to change the behavior of the content.

    Now, remember back to our discussion of theory – our simple wiki content model and the default Tumblr model shown above still provide us with some benefit:

    1. We have names and labels, so we can separate the @attr:Title from the @attr:Body
    2. We can tell the editing interface that the @attr:Title should be a single-line textbox, and the @attr:Body should be a multiline textarea (perhaps even a rich text editor)
    3. We can ensure that every content object has a @attr:Title by refusing to create or update an object unless a @attr:Title has been entered

    So no matter how simple, a content model gives us some advantages.

    Knowing the built-in model is helpful because you need to know what you have to work with and how you might need to extend it. Additionally, knowing the built-in model gives you some insight into functionality – if a system is managing @attr:"Start Publish” and @attr:"Stop Publish” dates, then it clearly allows scheduled publishing and expiration; if it manages @attr:"URL Segment”, then it must allow URL management.

    In most every situation, the built-in model won’t encompass all of your requirements, and you’ll need to change or extend it. Let’s talk now about whether/how that’s possible.

    Evaluation Question

    1. What is the built-in model – what content types are in the product as installed, and what attributes do they possess?

    This is item #5 in a sequence of 35 items.

    You can use your left/right arrow keys to navigate