[Framework-Team] Re: new workflows

Martin Aspeli optilude at gmx.net
Wed Feb 28 13:48:59 UTC 2007


Hi Raphael,

On 2/28/07, Raphael Ritz <r.ritz at biologie.hu-berlin.de> wrote:
> Martin Aspeli schrieb:
> >> I general I agree; it's mostly a practical issue here because
> >> the old API for adding workflows to the tool is gone and
> >> I simply don't know whether/how GS supports doing only
> >> parts of an import step (import wf x and y but leave z alone;
> >> don't touch the chains ...) but maybe it's just me and all this
> >> turns out to be a non-issue.
> >
> > I don't think it's that hard, and I will give it a shot. The strategy
> > would be to run just the import handler that updates the workflow
> > object, not the whole workflows.xml one. I'd have to look at it a bit
> > more carefully, though.
> >
>
> We need to be careful here indeed.
>
> To the extend that I've understood how GS works this
> isn't exactly straight-forward.
>
> CMFCore.exportimport.workflow._importNode calls
>
>          self._initProperties(node)
>          self._initObjects(node)
>          self._initBBBObjects(node)
>          self._initChains(n
>
> which - in a custom import handler - can be easily
> restricted to just call self._initObjects(node)
> which comes from GenericSetup.utils.ObjectManagerHelpers.
>
> This iterates over all 'object' children in the node, creates
> them only if they are not yet there (which is exactly what we
> want) but then also invokes the import handlers for **all**
> 'object' children (not really sure on this one, though - if
> this could somehow be restricted to objects newly created
> we would be done).
>
> At least calling it on all childern (here workflow instances)
> is not what we want here, because
>
>   DCWorkflow.exportimport.DCWorkflowDefinitionBodyAdapter._importBody
>
> calls _initDCWorkflow unconditionally on all workflow instances
> enforcing the settings found in the XML files irrespective of
> any previous settings. This is where it becomes dangerous and
> this is why I think we cannot (easily) rely on GS here.
>
> Please prove me wrong!
>
> And just to clarify: what I know fore sure is that when you
> import a wf via an extension profile, do some customizations
> TTW (e.g., change permission settings for a state) and then
> reapply that same extension profile your TTW customizations
> are gone. This is why we have this discussion.

I need to look at this in more detail, but we'd need to find a way of
doing it at a lower level. Hell, I'd copy the XML-parsing code and
make it more defensive if necessary. :)

My hope (without looking at the code in detail) was that the logic
that parses the Definition.xml file and creates states, transitions
and so on is in a separate function to the logic that parses the main
workflows.xml file (which points to workflows to install, but also
does type mapping and what not). If we could invoke this logic
separately, we could make sure it was only ever called on XML files
corresponding to non-existant workflows.

I propose that we:

 - Make sure the workflows merge and install on a fresh site, first
 - Make sure the control panel works, including remap states (got code
for this already)
 - Write tests. I may not manage perfect coverage for beta 1, but it's
a beta after all. I'm hoping to get started and get Alex and Andrew
and others to help me fill in the blanks.
 - Write migrations. This could be dead simple... or not. I don't know
how Wiggy would feel if we left the migrations until beta 2?

Martin




More information about the Framework-Team mailing list