[Zope-CMF] Plone/Metadata/FUD

[Erik Lange]

At 11:31 AM 10/2/02, seb bacon wrote:
>I think the plone team are doing a lot to bring people into the Zope fold.

So do I - a big applaus and there where much rejoicement ! :-)

>It looks cool and make several usability improvements over CMFDefault.

Yes - but that's not my point... hip hip hurray for Plone - could we move 
on now ? ;-)

>I don't care if you call it a fork or a layer, if more people are using 
>Zope/CMF then I'm happier.  I would rather 10,000 more people were using 
>20 forks of the CMF, rather than 100 people were using a single CMF 
>implementation.  Let's get people on board; let's worry about the other 
>stuff once we have sufficient momentum from a large enough community.  And 
>this from someone who doesn't even use plone :^)

I agree totally - but here in denmark we have an expression that goes like 
this: "You shouldn't throw out the Baby with the bathingwater!" ;-)

If Plone get's ported back to CMFCore, that's what I fear will have 
happened, and then it would be too late to do anything about it.

>>A recently-recommended book says "[m]ost conflicts are based in differing 
>>interpretations of the facts."  We should step back from heavy artillery 
>>and find out how the situation can be improved for all our viewpoints.
>
>One observation I draw from this discussion is that we should have some 
>kind of conceptual / infrastructural framework for differentiating between 
>Implementations (CMFDefault / Plone) and Framework (CMFCore).

Wow - enlightning ! :-))


>Ever since the CMF began, most people consistently (and understandably) 
>don't get the relationship  between Core and Default.
>
>In the future, I would like to see CMF releases available in 2 (or more) 
>*separate* parts:
>
>1) Download the CMF (actually just CMFCore)
>2) Download an implementation (currently a choice of CMFDefault, Plone, 
>mmmanager...)

Brilliant explenation :-)

One small error: mmmanager doesn't provide a CMFDefault-implementation 
(yet) our MMM Skins is just what it says - a skin ;-)

We're working however, on a "CMF Layout" product, that will work as an 
administrators UI for building slots and filling them with content- and 
list-boxes... but we're not ready to release this at the moment (a couple 
of weeks from, I guess).

>This approach has the advantages of keeping the conceptual break clean, 
>and also possibly encouraging people to think outside the CMFDefault box a 
>bit more.  There are more types of website than the member-centric 
>document-centric portal...

Yep - and an CMFDefault-implementation _can_ be made on top of CMFCore 
framework - and should be, IMHO :-)

Changes to CMFCore, should be made in CMFCore - not in a "random" 
CMFDefault-implementation... again, just IMHO :-)

Otherwise we're all stuck with member-centric and document-centic portals...

Regards,
Erik