[Zope-CMF] Plone/Metadata/FUD

[Erik Lange]

At 01:56 PM 10/2/02, hazmat wrote:
>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. :-)

*ROTFL*

You'll be the first to know... :-)

<cut>

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

It's my believe that this is actually what people want, when they go for 
Plone - a nicer look than default CMF - that was also why we in the first 
place even bothered to look at Plone... It's fine that Plone wants to be 
more than just that, but since that's the main reason people choose to use 
Plone (IMHO), it should be made clear that Plone is _not_ a skin for CMF!

And I believe it would be polite of the Plone-dudes, to provide such a skin 
themself... but until they do we're happy to assist ;-)

( Our "codename" for MMM Skins is "Plone rip-off" ;-) )


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

I don't want a workflow that depends on other products, as I believe Plone 
workflow will depend on Plone, in the CMFCore or in the default 
implementations (i.e. CMFDefault).


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

We use them ! :-)

And if Plone workflow works without Plone and gives me something that the 
other dosn't provide, it would make sense to distribute Plone workflow with 
CMFDefault.

But I don't belive Plone workflow does that ?

What I would really like to see in CMFDefault is an activity based 
workflow, like OpenFlow, to suplement the different actionsbased workflows 
it comes with today.

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

Uhm... that wasn't meant to be rude :-(

It was more like a summery of how I've interpretated Alan's mission for 
Plone... now that might be a bit rude, if I have misunderstood Alan on this 
point... If I haven't misunderstood Alan on this, I believe it's Alan who 
is rude to the community...

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

If it depends on specific products and can't be used stand alone, it 
bothers we...


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

We're quite bussy here, so at the moment we just use what is there - as 
soon as we get a little air, we would be happy to contribute to OpenFlow... 
I don't see why we should do OpenFlow development in a Plone enviroment... 
do you ?


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

Default WF's are useable, but not perfect - so we don't add "a whole new 
workflow definition framework", but uses the default ones, until we have 
time to develop the perfect ;-)


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

Now you're talking !

Let's get the development resources of the CMF community focused on this, 
rather than on an external 'thingy' :-)


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

And adds it's own framework wich to some extend makes it incompatible with 
the default framework.... IMHO.


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

So let them have it :-)

Why do I need it ?


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

No - I mean focusing the development resources of all the new users on 
Plone development.

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

Chris gave a fine example on this with how CMF Calendar was "ported back"to 
CMFDefault...

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

90% of all mails that should be focused on developing CMF / Zope3, are 
"snapped" from this list with a "we're working on that at Plone, come join us!"

Instead they should be saying "we at Plone are also pissed on that - lets 
do something about it, and fix that shitty product to work with both Plone 
and CMFDefault"... rughly speaking ;-)

The above approach removes the focus from CMF development, where it 
shouldn't - IMHO.

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

Because Alan advocates for Plone's extra functionalities should be ported 
back into CMFCore/Default - I don't see why and fear it will end with 
CMFCore depending on Plone...


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

If you're messing with core-components, these must never have any 
dependencies to other products - then it won't be a base component anymore ;-)

Regards,
Erik