[Zope-CMF] Re: CMFSetup and workflows

[yuppie]

Hi!


Anahide Tchertchian wrote:
> yuppie wrote:
> 
>>> - turn import methods in CMFSetup/workflow.py into configurator class
>>> methods so that they're easier to override when subclassing
>>> (_extract*Nodes and _initDCWorkflow* methods)
>>
>> Sounds fine if you don't want to do the big refactoring.
> 
> Yes I'd like to, but as I am new to this code I thought these methods 
> were necessary (is it?) and I just wanted to make them class methods. 
> Maybe it's not the case with ConfiguratorBase, I just have to have a 
> closer look at it.

Great. The _extract*Nodes methods should become obsolete, the 
_initDCWorkflow* methods (or similar methods) are still necessary. I 
guess the best example to look at is typeinfo.py.

>>> - get rid of DCWorkflow specifics, and use the workflow factory and
>>> API methods to import a workflow (no need to import
>>> DCWorkflowDefinition, State, Transition classes anymore, for instance)
>>
>> I didn't have a look at the details. But I'm afraid we would loose 
>> some flexibility. Other import handlers allow fine-grained changes to 
>> existing setups.
> 
> I'm not sure I understand why we could lose some flexibility.
> For instance, instead of doing:
> 
> from Products.DCWorkflow.States import StateDefinition
> s = StateDefinition(id)
> workflow.states._setObject(id, s)
> 
> I'd like to do:
> workflow.states.addState(id)
> 
> Since workflows handled are supposed to be quite similar to DCWorkflow 
> workflows, I thought that if it's too different, a new configurator will 
> have to be coded anyway. This is just to handle DCWorkflow subclasses, 
> like CPSWorkflow classes.

Ok. Looking at your example, I guess this is fine.

>>> - do not list workflows that are not supported when exporting (not
>>> supported workflows are listed but not exported at the moment)
>>
>> You mean workflows without CMFSetup supported? i.e. CMFDefault 
>> DefaultWorkflow? Why shouldn't they be listed?
> 
> Currently, on export, if a workflow is not a DCWorkflowDefinition 
> instance, its name is listed in workflows.xml but there is no other file 
> containing the worklow definition, so I'm not sure there is a point to 
> list it.

It's not useful for an automated re-import. But people can read the XML 
and get informed about unsupported objects in their site.

On the other hand I don't care much about this.


Cheers,

	Yuppie