Some points about what we think about CMS - Part 2

This is the second part of this former post : Some points about what we think about CMS.

After few projects and few architecture designs, we're up to deliver the second part of our mastering of content management with eZPublish.

Different ideas and concepts

Here are the following concepts you should know about before going on.

Content, messages and settings

eZPublih as all kind of software is made to store a lot of information regarding its source. We can distinguish several types of information :

• Contents : information used in the website pages, owner of the real value of the website. It can be text based pieces of information or pictures, or videos...
• Messages : information used in the website to deliver messages. It could be a label or an error message, something nearly static but which can change.
• Settings : technical information globally used in the website to structure the content.

Those types structure each website and each type must keep its original aim.

Use contexts

Use context are very important in a solution. The aim of a context is to ensure that users can do only what is coherent to do. It's a main principle that must be declared during the design phasis of any product and it allows the mapping between events and actions. More information about this on the spectacular book The Psychology of  Everyday Things by Donald A. Norman.

In eZPublish, such contexts are defined inside the back office : browse, edit, search... For example, if you are editing a content, you cannot edit another content or browse something. However, it's possible to switch from one context to another with a controlled input (Online Editor dialog box, for example).

The closest thing in eZPublish could be the navigation part used in menu.ini.

Aggregates

As explained in the former post, the aggregate is the concept that allows you to use different contents so it can be mashed up in one page. The edit of this kind of content has to respect the aggregate context : if you are aggregating, you can not edit a content. It also means that you have to prepare all the content you want to aggregate before aggregate it.

Composition and layout

The composition action relies on several axis :

• Definition of placeholders in the page : you shape the layout of your page, preparing the page to receive different contents, adding constraints to it : columns, height, width...
• Definition of widgets : you shape a bunch of independent blocks implementing different features : main story, google map, search box, gallery and so on... You may set each widget depending on its type.

Currently, this is mostly implemented in ezflow's eZPublish extension.

Dealing with complexity : content structure is not monolithic

Now that we're equipped with some concepts, we can approach complex needs of our customers.

The rule of thumb that should be learned is the following : each use context deserves a separate content structure. Currently eZPublish is coming with already set content structures (Content Structure, Media, Users and Settings) that could be extended so you can provide your own. As a matter of fact, we should always try to keep the solution genuine and only add things to it. We should also try to not replicate old ways of thinking like those used in DBMS but rely on what the software can do.

Case 1 : Dealing with messages

The case : your business team would like to manage some of the message shown on the website, for example, the small explanation on the confirm page of the shop or the next steps on the zero result search page. Their aim is to be self-sufficient on this part.

The solution : you can just do a smart class to store your messages and then organize it in one of the provided content structure. The point is to define a sub content structure dedicated to a use context, it's still not following the rule of thumb entirely but it's ok.

Solution 1.1 : Adding a hidden folder

You can create a folder and set its visibility to hidden. Then create a class called Message containing 2 fields : id (Text Line) and description (Text Block).

In your different templates or modules, just fetch the object of the class Message with the corresponding id.

Solution 1.2 : Adding a folder in the Media content structure

You create the folder like in the solution 1.1 but in the Media content structure. The benefit is that the Media content structure is visible but not simply reachable. Ok, you may access it by typing it's url directly.

Other solutions that could work but that are too complex considering the need

We could also store all the messages using other storage facilities like the translation file or a specific database table. We can reach the same goal but with a lot of development or worse, strong constraints for the user. I strongly think than using a content is still more efficient than modifying an XML and cleaning caches...

Case 2 : Dealing with settings

The case : your business team would like to make links between pages and mutualized contents. The aim is to manage reference data that don't need a page (reference to the one node = one page rule) but that is not changing very often.  To be closer to reality, let's take a real example. We have a company with a lot of departments. A department is just a part of a corporate body, so it doesn't really need a page for itself but it stores some typical data (address, logo, boss, etc.). In other pages, you will have to specify a department among the full list of departments.

Solution 2.1 : INI files+ Specific Datatype

In a typical application server based solution, you would use some reference tables declared as application variables, but with PHP, you don't have application variables. Instead we will use INI files that will be called from a specific datatype to generate a specific list.

The main limits are that you are limited to the INI file way of storing data. It means that you could not store complex objects but just key / value elements. The value must also be text based (no pictures or other media).

Solution 2.2 : Selection

The Selection datatype is very powerful and should be used very often to solve this kind of need. In our case, you can create a class department with all the required attributes. Then you create a folder called Administration (not in the sense of Set up, in a business way), and eventually sub folders if needed. In a folder, you create all the departments you need. In your other content class, you set the Selection attribute to use : the Administration sub folder previously created. That's done.

In order to have a clear back office interface, you way want to distinguish your use contexts. This can be done by adding specific RootNode and block settings to the menu.ini file.

Case 3 : Dealing with a reference

The case : your business team would like to organize a reference, like a catalog of product, and in the meantime have the flexibility to organize pages of the website. Their aim is to be flexible and shorten the time to market for the product marketing materials. We're talking of a lot of products, let's say 20k so the list approach described above is not useful).

The solution : Follow the rule of thumb by defining two use contexts : the first is obviously contribution for all the content you've already set. The second use context, less obvious, is the aggregation. It means that people would like to change some things that are not pages, because in eZPublish, each node is a page.

Solution 3.1 : Original eZFlow content structure

If you have just installed a fresh install of eZPublish, you will see the original content structure provided by eZSystems. Their main approach is to demonstrate the power of their solution so they have mixed contexts. eZFlow, an extension of eZPublish, allows you to aggregate content through the selection of already filled contents.

The content structure is designed so the FrontPage used by eZFlow contains classic content (Folders, articles, Galleries...).

This structure is efficient enough if you don't have so much content but has some limits. Indeed, the parent-child relation implies a 1-to-n relation between the main parent FrontPage and its children (understood that you will aggregate only content that are under the FrontPage).

Solution 3.2 : Separate use contexts and content structure

To go further, you may organize strictly your content structure to have two content structures :

• Global Fund : structure containing all the content, independent from the storyboard of your website.
• Sites : structure containing all the FrontPage based content, implementing the storyboard of your website.

By this way, you will have a n-to-m relation between your aggregation content and your classical content. You also separate totally your use contexts by telling user that if they want to put content in the system, they have to use the first content structure and if they want to compose pages, they use the second one. Then, it's easy to set up rights, sections, workflows and so on.

Think before !

We have seen different cases with different solutions all implying content and content, respecting or not the rule of use context separation. My recommendation is to carelly design you content structure before implementing it in eZPublish (or other systems by the way).