Content Modelling - Step 4 - Identify relationships between classes

Capture the relationships between the classes which are stated as rules:

  • A Location is in a State (e.g. Brisbane is in Queensland, Gold Coast is

  • in Queensland)

  • A Business is located in a Location

These relationships create rules, set patterns, permissions, and define how the content will be entered, managed, and related. They set what belongs to what. They're fundamental. If a product can only belong to one variety, then this is set as a rule. Changing it later becomes problematic as changes are required on a number of levels, especially if content has already been entered. For instance, if you decide that a product can only belong to one variety then it's straightforward, you never have to display rules that could be associated with it. You don't have to worry about it coming up in a search for products listed by variety, etc.

These rules also inform the way that content is entered into the system. We need to take into consideration the people that will be entering and maintaining the content. They will not necessarily understand the model and it's not always apparent from the way things are structured in the administration interface. So making sure we capture the rules properly will help on this level. It will stop mistakes such as an editor trying to add an object to a part of the node tree where it doesn't belong and that has no custom template to display it. A simple example is that of nesting. Let's say we are dealing with a news item. It's a common object in a CMS. One rule could be:

  • News items can be added to folders

Another rule could be

  • News items can only be added to news listings

There doesn't seem to be much difference to these rules. Object can be added to parent object. When it comes to using the system, it can make a big difference. The "folder" object is a common object within most CMS platform. It can contain many different types of objects and there are standard displays associated with it. If you don't want to do anything special with the news item, this will work fine. But you are at the mercy of the editors to decide which is the appropriate content type to use when they are adding content.

The second rule is more specific. It means that a news item can only ever belong to a news listing. It means that the display of the news listing and news item are set in a particular fashion. It means that the "news item" object has a particular meaning because the rule won't let the object be used for different purposes. It will force the editor to consider the nature of the content being added.

From a programming perspective, it's also easier to manage as you don't have to consider the display of the item in different contexts. For example, if the rules allow different objects to be displayed in the same parent object, we have to think about the navigation in greater depth. Let's say the folder object can contain articles and news items. A typical approach to navigation is to have all the objects within a folder listed as links down the left-hand side of the page as links to the full view of that object. How will the user know which object is a news item and which object is an article? Do we have to write extra code to differentiate between the two? Does it matter what order they are displayed in? If the news item has a date, then do we need to order them differently from the articles, which are to be displayed in an alphabetical order by name? All of these questions arise if the rules aren't clear and precise.

If the rules are clear and accurate, then development and use of the end solution will be more straightforward with less possibilities arising. The more vague and open the rules, the more the problems that arise when content is entered and you discover there's a situation that hasn't been accounted for. And also, it doesn't make sense to the end user. Then, you have to superimpose rules, which could mean re-entering of content.

However, making the rules too strict can limit the flexibility that ez publish provides. Finding a happy balance is the key. The content itself will suggest the rules and then you need to confirm them with the client by considering the edge cases and posing questions such as:

  • Can a product ever belong to more than one variety?

  • What happens if a variety has no products?