Another piece of the puzzle is in trunk gluon/contrib/autolinks.py
You can use it with other CMSes as well. On Sunday, 22 April 2012 11:24:50 UTC-5, Massimo Di Pierro wrote: > > Let's say we want to build a new kick-ass CMS. > > My technical side tells me that the best way it to use markup language and > separate data from presentation (which allows swapping of themes). > > My practical side tells is is better to allow users to edit html. > > Everytime I has worked with end-users I had a hard time explaining this > concept of separation of data from presentation. They usually want a page > tat looks like "that page" but the ability to edit all text and images in > it. > > Most CMS's (like concrete CMS) solve the problem by a compromise. You can > only edit specific parts of a page (and they must be clearly tag in the > HTML). This allows some separation because as long as two themes have the > same editable tags, the content it portable between the themes. Yet if they > use a wysiwyg the editable blocks are stored as HTML. Moreover creating > themes requires some programming skills and make the themes CMS specific. > In the case of Concrete5 or Joomla for example, this tagging is done in PHP. > > So what is better? > 1) using a markup language with limited choice of themes (like wikipedia) > 2) using wysiwyg to edit fixed sections in themes (like joomla and > concrete5) > 3) using fully editable html with no limitation on themes (any existing > page would be a theme without need for tweaking) yet one would not be able > to swap a theme on a page without loss of content, any more you can swap > the theme on a msworld document. > > > Massimo >
