[Zope-CMF] Plone/Metadata/FUD

[Chris Withers]

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.

> 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.

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.

 > 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.

> 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

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'.

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 ;-)

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

Anyway, that's all I can muster for now, I'm sure there will be more later...

cheers,

Chris