[Zope-CMF] Re: CMFSetup and workflows

2005-07-11 Thread yuppie

Encolpe Degoute wrote:

That's seems a good idea, but I dont where worklists will be import
in few weeks.


That sounds like you're working on a big worklists refactoring. If 
that's the case, sending a small proposal to the list would be nice.


Cheers, Yuppie

___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests


[Zope-CMF] Re: CMFSetup and workflows

2005-07-11 Thread 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

___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests