[Zope-CMF] Plone/Metadata/FUD

[Erik Lange]

At 02:57 PM 10/1/02, Chris Withers wrote:
>alan runyan wrote:
>>what we have done.  And if we were "not participating" with
>>the CMF community we would have not written on top of the
>>CMF but in our own framework.  Then you may have an arguement.
>>But we have folded in the portal_calendar tool from Plone to
>>CMF (thanks to ChrisW and AndyD)
>
>Urm, not sure about the 'we' there. NIP needed a calendar in a non-Plone 
>CMF which is why Andy and I moved it back into CMF Default. IIRC, we had 
>to make quite a few changes along the way 'cos Plone is such a vastly 
>differing environment to a normal CMF site.

Hmm... according to Alan's statement above; do I have an argument ? ;-)

I mean, If it was written on top of the standard CMF framework, no changes 
would have been needed, before rolling it back to CMF, right ? ;-)


>>and I would hope in the
>>future we could merge our Workflow changes into the CMFDefault
>>because I think its useful for all.
>
>I think you're a little behind on this ;-) It would be nice to see the 
>Plone guys feeding back some of the cool stuff as bare tools (as CMFCore 
>provides) that can be used as needed or not used if you don't need them or 
>don't like the performance penalties. Most importantly, these tools need 
>to be usable with their full functionality in _non_ Plone sites.

Yup ! :-)

Plone has a very well defined mission and for this Plone workflows may be 
appropriate and usefull - but the beauty of the CMF is, that it can be used 
in an endless number of scenarios, many of these where Plone workflow would 
_not_ be appropriate or usefull.

So make your workflow into a seperate product that can be installed as 
needed... we actually stopped using Plone for this reason... it gave us all 
to much that we had no use for - I hope I'll never see the day where we 
need to pull this out of the CMF-core before we can use the CMF for our use 
- it's always more complicated to rip an installation for sub-products, 
than it is just not to install them in the first place !

So Plone should work without Plone workflow, and Plone workflow should work 
without Plone - by bundling everything together, you're looking people in 
to your way of doing things... okay - I must admit that the strategy works 
extremely well for Microsoft, but I believe it's not considered to be good 
behavior in an open source community ;-)

>I think the problem you'll find is that I suspect Plone doesn't 
>differentiate well from components which provide services (like the 
>Actions tool, for example)  and the configuration of those components 
>(like the content_status_modify method ;-) which will make moving useful 
>functionality from Plone to CMF more difficult than it could have been had 
>improving the CMF been a real aim of Plone's from the start.

The CMF calendar seems to be a pretty good example of this, now it's 
explained how it was developed...

> > Also our implementation is more complex
>>(obviously... it does *more*) so it may not have a role in the world
>>of CMFDefault which is the simple-and-easy system to dig through
>>to wrap your mind around the tooling framework.
>
>Nah, I don't agree. Good tools should work simply in their default 
>configuration but should be easy to customise in powerful ways should you 
>choose to do so.

Hear, hear...

>>So I think I have demonstrated for the first and last time why Plone
>>is not a 'fork' of the CMF.
>
>I can empathise with Erik here though. I know you're not trying to make a 
>true fork of Plone, but it feels that way since you can't choose to use a 
>'bit' of Plone. It's prettymuch all or nothing, or at least that's my 
>impression. Also, I have a perception that with Plone, you either do it 
>the Plone way or you're stuffed. I'm not sure hot to judge how accurate 
>that perception is :-S

To me it's not a perception - it's a fact which Plone.org itself states as 
their primary goal and mission for the project, and this is fine with me - 
just stop calling it a CMF product then, when it isn't compliant... it's 
pretty confusing for new users, who think that what they get is a nice 
looking skin for CMF, when they in fact get's a non-standard CMF-site (with 
a nice look).

>It could also be percieved that forking is occuring since all the 
>development takes place in the Plone repository, rather than the CMF one, 
>which we all have access to. It might feel less forky if work was done in 
>the CMF repository to improve tools so that Plone could use them, rather 
>than replacing them in the Plone repository and, in effect, making Plone 
>incompatible with 'normal CMF'.

I don't buy the excuse that "it'll all be fixed when Plone is finished and 
rolled back into the CMF" - then CMF won't be CMF anymore, but Plone ! .. 
now, that would perhaps be a new way of forking - nevertheless, it would be 
a fork to me... who would then be the developers ? not the CMF community !

It should always be the other way around, if Plone shall continue to call 
itself a CMF-product.

Plone to me is an alternative CMF - with a nice look.

This is where I feel the CMF (or the development of it) is being "forked" 
at the moment .. ;-)

>But, this approach would also have downsides. I would howl quite loudly if 
>some of the changes made in Plone were in the default CMF. I don't like 
>CSS used in browser incompatible ways, and I don't like pages of 
>JavaScript sent out with each request ;-)

Neither do we :-)

So we have ripped Plone-skins for all that stuff and have made a product 
called "MMM Skins", that gives your CMF site the look of Plone, without 
changing the underlaying functionalities in the CMF - we hope !

We have had a lot of request from users who has just started out with Zope 
- the common problem is this: "I have a CMF-site and have installed Plone 
to get a nicer look - your product doesn't work" - and the answer; "well, 
try removing Plone and instal our product again - if you want the Plone 
look, use MMM Skins" - this seems to make all the trouble go away ;-)

I have sugested to Alan that we rename our MMM Skins product to "Plone 
skin" or something like that, but haven't gotten an answer yet -  what's 
the lists opinion on this, is there a need for a pure Plone skin product ?

>Also, it is a valid way to develop new tools in a seperate repository, 
>provided they provide identical interfaces to the ones they're replacing. 
>This is exactly what I'm planning to do with the Swishdot Discussion Tool, 
>once I get a chance to write it (interesting aside: you knwo a project is 
>behind schedule when the domain name you registered for it has already 
>expired once ;-) However, I have an idea that this might not be the case 
>with all Plone tools :-S

Hmm... I believe they were pretty fast in getting plone.org up and running, 
and to attract developers to _their_ project, instead of contributing to 
the common development of CMF - otherwise I believe you're right ;-)

There's nothing "wrong" with the Plone-strategy in any legal way, maybe not 
even in any moral way - but it's ineffective and is slowing down the 
development of CMF, that essential CMF-development is now being done 
"through" Plone - I find this a waste of the (CMF) community's limited 
resources, because I belive that more would be willing to contribute to 
CMF, than to Plone - unless ofcourse, if CMF is being totally forked by 
Plone ;-)

And I still haven't heard any convincing reason why Plone couldn't be 
developed the other way round - on top of the framework and not based on 
it's own - as long as the Plone framework hasn't been rolled back into CMF, 
it's simlpy wrong and misleading to give the impression that Plone is a 
standard CMF product or even CMF compliant - IMHO - it's Plone, and that's 
a completely different thing... it may be based on CMF long time ago, but 
it's also long time ago that they were really compatible...

Regards,
Erik