[Zope-CMF] Plone/Metadata/FUD

[hazmat]

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.

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

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.

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.

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. 

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.

cheers,

-haz


On Tuesday 01 October 2002 09:56 am, Erik Lange wrote:
> 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
>
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://collector.zope.org/CMF for bug reports and feature requests