[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