[Zope-CMF] Plone/Metadata/FUD

[Jeffrey P Shell]

On Friday, October 4, 2002, at 10:51  AM, Erik Lange wrote:

>> I really don't think it's splitting hairs though. A lot of Mr Lange's 
>> complaints may not have surfaced had this divide been clearer from 
>> the start.
>
> I've thougt a lot about this the last few days... I'll try to explain 
> my "complaints" in a more civalized manor this time - I hope...
>
> The CMF started as an idea of a 'PTK' - Portal Tool Kit. To me it was 
> correct to change the name to CMF - Content Management Framework - 
> because a framework must be the core of a PTK, but keeping a 'base' of 
> just the framework, makes it possible to create both PTK's and other 
> content management solutions, that not necesserally are build as 
> portals/communities.

A lot of the portal/community design is still too prevalent, however.  
I've told the story before of trying to design and implement a customer 
/ project / task management system using the CMF.  I thought it would 
be easy, since tasks / projects / and customers could all be treated as 
"Content", and enjoy the luxuries of things like Workflow and the 
presentation layer separation that the Skins tool offers.

While it did get great benefits out of those services, it was often 
hindered in some usability areas by intruding services that I had to 
keep coding around.  Some were just latent bugs (made worse by the fact 
that I was going against a shaky CVS checkout instead of a more 
reliable release) that have since been fixed, but some of it was due to 
the intertwined relationships between certain tools and services, 
particularly the portal/community based items.  And some of it was due 
to me using more of CMFDefault than I probably should have, considering 
how different my application was than what CMFDefault offered, which 
was just bad a early architecture decision on my part.  But considering 
the amount of time it took for me to get to a somewhat usable 
application compared to what a coworker did in a weekend with DTML and 
SQL is now something we do every time we go into a content management 
proposal - are we going to spend more time fighting with the CMF than 
we're going to spend implementing a solution?

Eventually, we (my company) may have our own 'default' layer that gives 
us a known base of operations that does what we need to do.  I'm glad 
the CMF lets us do that.

> Where now moving towards Zope3 where CMF will be integrated in Zope - 
> CMFCore that is, as far as I have understood...

I think most of what Zope 3 gets out of CMF is the service (tool) based 
architecture, and a much needed successor to the Skins Tool where new 
views can be attached to a component at configuration (or other) time.  
I'm actually a little uncomfortable with Zope 3's main objects being 
referred to as 'Content Components'.  There are a lot of web 
applications out there that require little or no content-ish support 
structure, and I fear if too much content management gets pushed into 
Zope 3, then other types of web applications will become harder to do.

If it's a layer (maybe even a shipping layer) on Zope 3, like the CMF 
is now to Zope 2, I imagine it will be a lot better and easier to use 
than the CMF is now on Zope 2.  This is not a bad reflection on the 
CMF's design - but Zope 3's better separation of responsibilities, 
emphasis on configuration control, and built in Service based 
architecture will make adding content management layers easier.

> Meanwhile Plone has evolved and is today almost a true killer app. (I 
> belive it will be whwn it hits 1.0, so it's not to offend anyone, that 
> I don't recognize it as such just yet - it's almost there...).
>
> As I see Plone today, it's actually what the CMF started out wanting 
> to be - a Portal Tool Kit ! :-)

Actually, much of this is similar to how Zope started out!  The early 
Principia management interfaces were single paned, with actions going 
down the left-hand column (those actions eventually became the ZMI 
Tabs).  The early objects available as purchasable add-ons for 
Principia were things like the Confera discussion system, and the 
Tabula desktop-database publishing system.  These, along with tools 
like Aqueduct (which became Database Adapters / SQL Methods), were 
previously all separate Bobo (which is now ZPublisher) applications.  
Principia was seen as being this unifying framework for all of these 
things.

Sometimes I feel as though it's as the song says - "it's all just a 
little bit of history repeating".  Eventually, one tool goes from being 
a targeted application to being a generic framework/platform, and a new 
targeted application is eventually made on top of it.  But then, it too 
starts morphing into the generic tool/framework, and a new targeted 
application is built on top of that.

People seem to initially want something neat and immediately usable 
like Plone.  But then the questions start coming like "how do I move 
this?"  "how do I get rid of this box?"  "how do I make it do this 
instead?"  "how do I integrate this with the business processes our 
organization already has in place?"  "I like Foo, but how do I change 
everything about it?"

> Going back to the early evolution of CMF, when it was called PTK, I 
> believe it's important that we now re-define if it is a CMF, or a PTK, 
> that we want to integrate in Zope3... I belive we should only 
> integrate the base framework.
>
> The easy way out, would be to integrate Plone as a PTK, but I belive 
> this would limit, or at least obscour, the possibillities of the 
> framework. So what I would like to see, is Zope with an powerfull 
> integrated content management framework, and nothing more. CMFCore 
> stille needs some work or system-design to qualify for this - as this 
> thread has shown. On top of this, people can then install a PTK (like 
> Plone, or the upcomming CMF Portlets) if that's what they need, or 
> build their own 'layers' on the framework.

Zope 3's configuration based setup should make installing and 
integrating such layers an easier process than it is now - more 
explicit work, less surprises.

> I've seen a tendency these last month in the community, where people 
> are percieving Plone as an extended CMF-implementation, that people 
> like so much, that there's talk of porting Plone back into the CMF 
> (Core or Default). This I belive would be a major design-error for 
> Zope3, where I belive we should keep a clean framework that can be 
> used as a base for both the PTK's and other types of products... i.e 
> we're building automated production solutions for broadcasters, and 
> they have very little need for all the stuff in Plone, just like most 
> Plone-users won't have anything to use our streaming media CMS for... 
> it's just two very different worlds, that have very different needs, 
> but both worlds should build on the same framework, without _having_ 
> to interfer with eachother... so I don't see any reason for porting 
> anything from Plone back into CMF, but it would be nice if the various 
> parts of Plone was available as individual products, that could be 
> used as needed - on an opt-in basis.

It will be nice if Zope 3 makes the creation, distribution, management, 
and installation of smaller individual "products" or components easier. 
  I think that it will.  Hopefully developers will be able to catch on 
quickly.

> In short; Plone is great for those that needs a portal-like site, but 
> it's way to heavy to base the next generation of the CMF/Zope3 on it.
>
> Hmm... does this make sense ? Hope I haven't offended anyone...