Hi Raphael, On 2/28/07, Raphael Ritz <[EMAIL PROTECTED]> 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 _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
