The Flint Splint

So, Flint is not Plone. More specifically "Flint does not aim to compete with Plone, but to fulfill different needs".

An example of this kind of different need was recently given by Robert Gravina on the Grok-dev list.

....Most of [our clients] don't like the way content needs to be put in various folders either. One tried the Django admin out yesterday, and loves it, because they select the content type/object they want to edit (e.g. a news article) and they then can see all their news articles, search through them, edit the one they want etc. I can then display the news articles on various parts of the site in various ways based on object attributes or relationships rather than the folder they are located in.

One of the main differences from Plone we're currently contemplating is The Wall of Separation between Presentation and Content. This means that Flint, by default, will present two very distinct interfaces:

1. The Content Management Interface (CMI)
2. The Presentation Management Interface (PMI)
   

We're still fleshing out a lot of the details, but basically managing content, and getting this content to display in the "public" interface will be done through very different interfaces.

Of course, as is the case with Grok, there will be sensible defaults so that an out of box Flint experience will not require extensive configuration before some content is displayed. But the content management experience will happen in a space that does not have a direct connection to the presentation of this content. Some reasons for this include:

• not distracting a "content contributor" with considerations about presentation, location or layout,
  
• enabling content to be easily displayed at multiple places in the public interface,
• enabling site layout and content selection for display to be done by different users (roles) than those required for contributing and controlling content.
  

On the other hand, we're not throwing the baby out with the bath water. The Zope classic content model, very pervasive in the behavior of Plone for instance, is a model where the hierarchy of items in the object database determines the site structure and the URL mapping. It is very useful and convenient for a lot of use cases, and it will play a central role in the Flint PMI. It is there that an editor will implement the site structure through a Site Map Editor, adding Sections, to the structure and adding Custom Pages and sub-Sections to those Sections (btw, words in bold have special meaning in Flint, and are defined in our Glossary).

Sections can be configured with a Selection Rule, which will filter, order and group content created in the CMI causing a structure of Generated Pages to be automatically presented under the Section and displayed in a uniform layout.

Custom Pages will be composed by the user with blocks containing either information pulled from the CMI or with text edited inline. The same user interface that will be used to edit these Custom Pages will also be used to edit template pages that will dress the Generated Pages.

Of course, the ideas above are in flux while we flesh them out and investigate current CMS implementations.

There's a Glossary constantly being redefined in the Flint-cms project Wiki.

A future post will have more to say on the behaviour of the CMI.