Gianugo Rabellino wrote: > > Cocoon is about XML handling and presentation. A CMS is responsible for > the "backoffice" part and has several concerns that are difficult to > model in Cocoon: think about users, groups, permissions, workflow, > scheduled publishing, categorization and so on. I remain convinced that > the best solution would be a CMS where all those concerns are addressed > specifically (most of such a beast can be done using Cocoon as the base > framework) *and* a way to access the CMS from the "presentation" side > using Cocoon via custom generators or, even better, a (pseudo-)protocol.
One of the most important points of a CMS is that it must be agnostic of deployment and runtime considerations. Deployment and runtime technologies have to be integrated into the CMS, not vice versa. The CMS is "here to stay", but the content it manages may be deployed on a number of different platforms in a number of different ways. All (or at least most) of the commercially available CMS things lock you into a certain type of runtime platform. Even Open-Source efforts such as Zope include their own runtime environment - some people may want to use Zope's CMS features, but they might not want to do their programming in Python. So, an "Apache-style" CMS should in my mind be absolutely independent of anything else except XML. Cocoon could be the world's first runtime environment to include an "Apache-CMS client", but it should not be the underlying framework. Rather I think Avalon/Phoenix are a better choice for the framework, they do not make nearly as many assumptions as the Cocoon framework does. Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
