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.

First meeting

Today Leonardo and I had our first official meeting of GSoC 2008. We decided to split our work in three phases:

• Phase 0: before the coding start date we will focus on studying other current CMSs, writing specs for Flint and collecting feedback from the Grok community
  
• Phase 1: from start to mid-term we will develop a functional prototype
• Phase 2: from mid-term to finish we will refactor and productize the prototype

We then worked on design principles for Flint, and started a glossary which has been helpful to settle the names of some key concepts. For instance, we decided that what I called section in the project proposal should instead be folder, and the term section is better suited for a different concept which Flint will also have. We agreed that Leo will write the post explaining why.

Why Flint

Flint is a Grok-based CMS. It's not the first one, and surely will not be the last. Our goals are:

1. to provide Grok with a non-trivial sample application demonstrating best practices and how to integrate components to handle common use cases;
2. to provide the Zope community with a simple CMS which addresses content management problems from a perspective that is very different from that of Plone and the underlying CMF (Content Managament Framework)
   

Flint was proposed by Luciano Ramalho based on ideas initially developed by him and his colleagues at Occam Consultoria, Daniel Vainsencher and Rodrigo Pimentel. The project is being mentored by Leonardo Rochael, who along with Luciano and the Hiperlógica team developed Página-1, a pre-CMF, Zope-based CMS.

All of us have been developing Plone-based sites for a few years. Plone is outstanding, but out of the box it's not well suited for some scenarios where Página-1 and other CMSs excel. So Flint does not aim to compete with Plone, but to fulfill different needs. It also aims to be much simpler, so it will have a more modest feature set.

The source code for Flint will be hosted at the Zope.org Subversion repository. For the time being, project documentation is hosted at Googlecode.