Philosophy

The Flint project recognizes that it is not the goal of Grok to be a customizable web app, just as Zope 3 gave up this idea early on. Grok and Zope 3 need to be generic frameworks for building web apps. But a simple, customizable CMS built on top of Grok makes it easier to demonstrate and provides beginning developers with a valuable starting point for many common use cases. Having a simple Grok-based CMS ready to use when Grok 1.0 launches can help to attract and retain more users.

High-level features

Flint aims to leverage a few powerful concepts.

Faceted Tagging

Content will not be kept in folders. Instead, each content item will be be tagged. A "section" tag may provide a default location for the item in the content management interface navigation, and some categories of tags may be nested, providing hierarchical organization when desired. But by avoiding the folder metaphor from the start, users will be able to tackle more advanced, but very real and common content management problems such as how to make a story appear in two different places. By faceted tagging we mean that each content item will have several tag fields, each with it's own rules. For instance, a "section" tag field may allow a single tag drawn from a hierarchy, while a "channel" field may allow multiple tags drawn from a flat list. So a story about a soccer match may be tagged for section "sports/soccer" and for channels "Santos FC", "CA Boca Juniors" and "Libertadores Cup".

Faceted tagging is the natural solution to the old content management dilemma: how to make content easy to manage for the producers and easy to navigate for the consumers.

Data is not metadata

Metadata is not the same as content data. Some CMSs confuse this issue, with the result that an "author" field sometimes names the creative author of the item and other times the person who put the item in the system. Zope 3 already comes with a powerful annotation mechanism by default, and Flint will use it to store Dublin Core metadata and keep the content types themselves very simple.

TTW creation of content types

A main goal is to make it very easy to create new content types, either by editing Python code on the file system or through the web. The idea of basic TTW customization of content types introduced by the CMF years ago deserves a fresh look, with a few twists. For example, one simple customization that is very useful is to change the visible names of fields as well as their ordering, without requiring cumbersome template editing or any Python programming. So for a specific application a Network Alert content type can be derived from a News Item by renaming the "author" field to "engineer" and the "summary" to "impact". Creating new content types unrelated to existing ones should not be too hard either.

Composite pages (formerly called "covers")

In most content sites two very distinct types of pages can be identified: composite pages, which are node pages with little content of their own, and simple pages which usually carry the full text of one content item each. For example, the initial page of a content site is almost always a composite page: all the content in it is just extracted from content items that are elsewhere, just like the front page of a newspaper. Composite pages are the focus of the attention of content editors (as opposed to writers), and require special permissions and workflow. Flint will have composite pages as a special kind of content which references other content objects and provides RSS/ATOM feeds.

User info is content

An object which represents a user in the system is just another content type, with default views, annotations, and faceted tagging to indicate group membership and the equivalent of roles and permissions. User data will be indexed, and basic infrastructure for user management will be ready to use (see next item).

Infra and super-structure to go

Flint will be preconfigured with some essential infrastructure which Zope 3 provides and Grok supports, such as user authentication and authorization, user/group management and content indexing. In addition, some high-level functionality will come ready to use: RSS and ATOM feeds of sections, channels and arbitrary queries, RSS and ATOM aggregation, standard workflows, content versioning and friendly widgets for e-mail, dates, rich text, tagging etc. The unification of users and content types means that rich tagging widgets will benefit both content producers and site managers.

Inspiration

The ideas outlined above come from recent brainstorming sessions by Daniel Vainsencher, Rodrigo Pimentel and Luciano Ramalho of Occam Consultoria, who have just started working on the Django-based BSD-licensed Razor CMS. The Flint project will take advantage of much of the work done for Razor, such as high-level requirements and specs, UI design, stylesheets and even functional tests.

Other key sources of inspiration will be Plone, Radiant (the CMS used in ruby-lang.org, see http://radiantcms.org/), Página-1 (an early Zope-based CMS written by Luciano Ramalho, Leonardo Rochael, Marcos Iuato and others) and Django itself, which although is not a CMS was created by journalists and comes very close to being one with its built-in admin interface and extremely agile and high-level modeling framework.

Relationship to other Zope Projects

Pending discussions with the project mentor and the result of other GSoC 2008 student applications, Flint will benefit from or can collaborate with the following Zope Foundation project ideas:

- TTW development: Both Página-1 and the early CMF supported and even encouraged TTW development of content types and template customization. These can be interesting use cases for trying out TTW ideas in Grok.

- Catalog maintainability: besides making it easy to index content through sensible defaults, Flint needs automated reconstruction of the Catalog if TTW development of content types is to be feasible.

- Relational database integration: the Zope Community respects and trusts the ZODB, but the market at large does not. To gain wide acceptance Grok and Flint must have an excellent relational database integration story. The Zope without ZOBD idea is also relevant to this issue.

- Grok user and group management: in order to be useful out-of-the-egg, Flint needs to have a pre-installed infrastructure for user CRUD, authentication and authorization.