[Zope-CMF] Plone/Metadata/FUD

[hazmat]

On Tuesday 01 October 2002 11:54 pm, Erik Lange wrote:
> 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 ;-)

cool, i look forward to seeing the release of your fork, um. i mean layer, 
er.. skin,  umm.. i mean thingy. yes, thingy, i like thingy, thats a nice 
safe non deterministic moniker. :-) 

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

good question. as i didn't work on it, i can only guess.. so i'll leave it to 
others to answer more definitively. i can say that it seems to work with the 
products that i've tried it with, most of them with *zero* changes.

> >Plone does provide additional tool functionality, but the use of those
> > tools is entirely optional.
>
> Great - that's new then.. since when ?

i dunno, as long as i've been using the cmf, which started sometime in july, 
after hearing seb's europython, borg assimilation presentation, as i like to 
call it. 

basically afaics plone uses its tools internally (ie portal_forms/validation, 
etc.), but product developers don't have to touch them or use any expanded 
apis provided, if they want cmf portability. 

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

sure, your probably better ui designers than i am as well ;-).

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

very cool.

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

maybe, i'm still not sure what your saying wrt to workflow.

> 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 don't think anyone ever suggested the plone workflow become the default.  
otoh, i'm not sure that i understand the issue, cmfdefault comes with a 
default workflow as well (2 even ;-), do you need that? 

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

smily faces don't make rude comments any better.

again, i fail to see the issue, *no* one is talking about making plone 
workflow default for cmf, and i seriously doubt most people with workflow 
needs are content with the default workflow out of the box, ie without 
customization, so i'm confused how changing the default would matter to you.

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

well your likely to benefit from some work sponsored by a company using plone 
for the cmf, ie openflow integration, that is assuming of course, your not 
writing your own.

again, if your adding a whole new workflow definition framework to define your 
workflows why do you care what the default is, its obviously not suited to 
your needs.

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

the core semantics of the architecture got rolled into zope3. ie centralized 
services, views components detached from object models, etc. which would make 
these semantics available to any zope product, which is a *great* thing, imo.

otoh, zope3 is a whole new ball game, and predicting how its going to be is a 
chancy thing, unless of course people start helping out, and making it the 
platform they want to use.

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

plone isn't replacing the cmf, its building ontop of it. 

its installation is gestalt, because plone's primary market/audience is not 
developers, its end users who want and get a point and clicky install.

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

you mean like bringing lots of new users around?

i really don't buy that plone is so different from the cmf functionally or 
that its some big hinderance to generic core development, at least i haven't 
seen any evidence of such. i see it spurring *generic* development in some 
respects. 

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

i'm all for choice. i don't see the consipiracy theory.  how has your choice 
as developer for using the cmfcore/default been negatively impacted by plone?   

i haven't heard anyone advocating that plone replace the cmf, not to mention 
even in the *worst case* if every plone user and developer were for it (which 
their not, imo), there are several cmf consulting companies who don't use 
plone (zc included), so why do you think that the plone is going to replace 
the cmf? 

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

um.. thats a contradiction, but i think i understood what you meant... 

cheers,

-haz