[Zope3-dev] On Types, Workflows, And Versions (was PythonProgrammerTutorial: questions, comments, and feedback)

[Jeffrey P Shell]

On Friday, December 14, 2001, at 05:58  PM, Florent Guillaume wrote:

>>>   - CMF implemented the idea of a zope object having a "Type" and
>>>     "meta-type".  How does this compare with Zope3?
>
> This separation is sometimes very painful in CMF. The goal it solves is
> to create a new type having different views or skin behaviour than its
> original type. Zope3 allows us to do the same thing much more cleanly,
> so I think Type (aka portal_type) should die.

It's not just different views or skin behavior - it affects how 
almost all of the tools(services) interact with an object.

For example - I have a class Task, with two portal types - 
'Project' and 'Task'.  On top of some subtle skin differences, the 
'Project' type has an extra workflow agent in its chain that deals 
with a financial workflow on top of the task workflow.  There are 
also different meta-data policies for each one.

This design is changing though - but I am planning on revamping the 
Task workflow agent to do a sort of 'State' like pattern [GoF, 
p305] where tasks can morph between types 'Proposed Action', 
'Implemented Action', and 'Suspended Action', as decided by certain 
transitions within the workflow process.

It's a powerful feature.  But I agree - the Type vs meta_type is 
confusing.  But I've never been terribly comfortable with meta_type 
anyways.  I like the dynamic type nature of the CMF.  It makes it 
much easier to plug in a new Folder or Project class without 
damaging too much existing expectations of code.

>>>    4. I really wish the CMF DCWorkflow functionality was built-in to
>>>    zope's security mechanism.  The whole CMF concept of
>>>    published,private,show,hide etc. would be much more powerful if it
>>>    could be applied in a manner similiar to zope's security model.
>>>    For example, the "acquire permission settings" button would 
>>> equally
>>>    apply if one had a "acquire publication settings" button.  Anyway,
>>>    this is just an idea.
>>
>> This is an intriguing idea.  I also wonder if there is any cross-over
>> effect with versioning.
>
> There is definitely a lot of crossover between versioning and workflow.
> For instance when one document is published (made visible to the 
> world),
> do you still allow access to the old versions ? Answer: it 
> depends. When
> a published document is retracted, do you put back the latest archived
> version in its place ? It depends...

I want to point out that DCWorkflow is merely a type of workflow 
agent that plugs into the CMF's workflow tool - a service that is 
basically a process controller.  DCWorkflow just happens to be a 
workflow agent that lets you define the process through the web.  
But it's only a part of what's possible with the workflow tool.

Likewise, the create/review/publish workflow is only one such thing 
that is possible.  I've written new workflow agents in Python that 
plug into the workflow tool for very different processes.

You *can* actually come up with some versioning scheme and plug it 
into the workflow tool.  I worked on a system that stored a lot of 
the content in a relational database to be served up by a different 
server instance (a fairly common story in web content management 
systems actually), and when the content hit an 'Approved' state, it 
was written out to different tables than where it was being 
edited.  The 'Approved' tables were used by the main site that the 
world saw.  You can do this with the CMF's workflow system by 
writing it into your workflow agent - either in one written 
entirely in python, or by using scripts in DCWorkflow based ones.  
It's a fairly open architecture, which is good because there's no 
single workflow process that can fit everybody.

[SNIP]

Versioning, like naming, can be a fairly large issue.  And a 
double-edged one at that.  On top of versioning content, we might 
have to decide soon about versioning interfaces. It's something 
that could have a huge impact on component dependencies.

Jeffrey P Shell, jeffrey@cuemedia.com