[Zope-CMF] Plone/Metadata/FUD

Erik Lange erik@mmmanager.org
Wed, 02 Oct 2002 08:54:11 +0200


At 03:09 AM 10/2/02, hazmat wrote:
>my two cents, those who are easily offended are advised to close their eyes
>while reading ;-)
>
>Plone is a customization of the CMFDefault to add functionality, useability,
>and look and feel. 90% of the problems i've heard so far, basically relate to
>look and feel, ie trivial changes to skins. and honestly, considering that
>plone basically looks *much, much* better than the cmf default, including
>many useability improvements, i can't understand how anyone could expect it
>to mirror the location and functionality of the CMFDefault.

Well... it can be done - just wait and see ;-)

It might take some thinking to figure it out - but it can be done... why 
_not_ do it ?

>Plone does provide additional tool functionality, but the use of those tools
>is entirely optional.

Great - that's new then.. since when ?

>as a developer, i've written several products for the cmf, everyone of them
>works fine with plone, and without plone. as a developer deciding whether or
>not to use plone, its a fairly easy equation, i can spend the time to make a
>site look good using cmf default, or i can fix the occasional trivial problem
>from some third-party product thats using a slightly different skin. as
>someone who readily admits their ui design skill sux, its a fairly easy to
>justify 5 minutes fixing a product skin, vs hrs, days, and weeks spent
>working on cmf ui.

Great - I'v never stated Plone wasn't a great product, we just haven't got 
the same needs as you, apperently, since it doesn't fullfill our needs.

Now, please - don't get offended over this! ;-)

MMM Skins fullfills our need for a nicer look on the CMF... it looks just 
like Plone, but doesn't do anything else... we hope ;-)


>the other thing i'm hearing is about compatiblity with workflow,  which is a
>big copout imo. because i've used plone with alternative workflows, and it
>works fine. if other products can't work well with a different workflow
>because they are *hardcoded* to a particular workflow, i consider that a
>product bug. simple as that.

Well.. you have misunderstod what I was saying.

It's fine that Plone has it's own workflow and yes, you can use other 
worksflows with plone. Great.

What I don't like is the idea of Plone workflow being rolled back to CMF 
core, instead of being released as a stand alone product. Then we could 
choose never to install it, if we don't need it.

I recognize that it's usefull for many users - but that shouldn't have 
_any_ impact on those for whom it isn't... or should everybody just shut up 
and see the light and use Plone all over to make it easier for you as a 
developer ? ;-)

We are looking for activity based workflow, and not action based - that's 
why I belive Plone-workflow won't be the one for us... sorry about that, 
don't take it personal.


>does anyone consider CMFDefault a fork of the CMF?, its a customization that
>adds useability and functionality that mirrors usecases that for zope.org,
>but its hardly an end user product. i don't see developers running to use
>CMFCore bare, because it doesn't provide alot of functionality and useability
>from a developer pov. in a similiar vein i do see users flocking to use
>plone, because for them it provides functionality and useability out of the
>box. these aren't forks they are progressively layerd systems that build
>functionality that users and developers can avail themselves of. ie
>Zope->CMFCore->CMFDefault->Plone.

I agree on the above. But what about this:

Zope->CMFCore->CMFDefault->Plone - rolling back - Plone->CMFCore , next gen 
= Zope->Plone... where did CMFCore go ?

Why  can't Plone contribute with seperate products from the Plone-package, 
instead of going for replacement of CMF with the full package ?

It's this mental twist, that "if we just accepted Plone and embraced it, 
there would be no problems", that I'm against - not Plone as a product in 
itself, but the impact it seems to be having on CMF development.

It's like Plone or nothing at all... and allthough Plone has a broad 
appeal, it won't be a product for _everyone_, unless you're thinking the 
Microsoft way ... if you belive that Plone should be the future base of CMF 
(as I feel Alan believes), I will feel we have been "forked". It's way to 
limiting in it's complexity for a base-product like CMF. Some of the 
component might be nice - but let me choose between the components I want 
to use on top of our common base in the future.

If You're missing something in the base - make it there and not in Plone.. 
specialized workflows are not a part of the common base - IMHO.


>also i'd like to note that this conversation has been mostly civil (with one
>noteable exception), of which i'm glad, please lets keep it that way.

I appologize for my Italian genes, that often has the effect that I'm 
saying things as straightforward as I see them - don't take it that 
personal.. Mama Mia ! ;-)

Regards,
Erik