[Zope-CMF] Zope as theatre

seb bacon seb@jamkit.com
25 Feb 2002 11:03:26 +0000


> 1. Can the default workflow be removed from a CMF site? If so, how?
>    If it can't, then why does it appear as simply another object in
>    the workflow tool's contents?

Yes it can - see Adam's mail regarding AUTO_MIGRATE_WORKFLOW_TOOLS.

This setting will automatically add a workflow called default_workflow
to the workflow tool when you restart Zope.

I presume it was needed to make sure upgrades worked between CMF
versions, where the newer versions required a 'default_workflow' to work
correctly.

It should really be provided as an external method and referenced in the
install docs - I don't know for which versions it was needed.  Perhaps
Tres could confirm?

> 2. Are these (and other recent and inevitably future) problems simply 
>    the result of operator difficulty, or is DCWorkflow not ready for
>    production use outside of Zope Corp. and other Zope gurus?

If you're not comfortable with the source, and it doesn't do what you
want or expect, then you're likely to be in some trouble.  I can vouch
that the CMF is stable, but if you're trying to do anything slightly
unusual, you should expect to have to get messy with the source.  The
problem you've found is typical of the kind of bugs or wierdness you can
expect - it doesn't stop you from doing anything, but it should really
have been implemented differently so there was less confusion.

The reality is that CMF is in a place similar to where Zope was one or
two years ago: an excellent system, but under-documented.  You should
have no concerns about its stability though.  ZC uses it for all their
consulting projects, I believe, and my company uses it exclusively.  

> 3. Is there some resource aside from the CMF sources and Dogbowl which
>    has up-to-date information on the CMF architecture, and more than
>    surface-level customization?

All the APIs are well-documented in the Zope Help, but beyond that,
there is not much documentation around.  The best place for help is this
list, but you may have to wait a couple of days or ask twice to get a
reply.  Tres & co at ZC are really good at answering queries.

> 
> Act IV: A Happy Ending (maybe)
> 
> <<audience participation encouraged!>>
> 
> I'm really, really trying to like Zope, but keep coming up against this
> wall of bizarre internal APIs used for everything that seems to cost so
> much of the readability and dynamic nature that made me love Python in
> the first place. I've done J2EE-based sites in the past, and never want
> to go back to that kind of gargantuan, heavyweight environment if I can
> help it. I'm not trying to blame any of the Zope core developers for my
> inability to understand their excellent tools...I'm just pleading for
> some guidance, before my time for exploration is up and I'm forced go
> buy something off the shelf.

What's the bizarre internal API you're thinking of?  Admittedly Zope
itself has some icky legacy stuff, but IMO the CMF has a very well
defined, well designed API.

The CMF may be immature with respect to documentation and best practice
examples, but it's well designed and you have access to the source.  The
OTS products I've used are well documented and easy to get started with,
but are badly designed and closed source.  The result is sooner or later
I'm staring at a brick wall.  With the CMF, you still get brick walls,
but there's always a very good chance you will be able to get to the
other side within a few days.