Re: [Zope-CMF] Forcing a workflow state

[Christian Scholz]

Hi!


I'm writing some migration code that needs to force a workflow state. 
That  is, a given content item has a workflow with states A, B and C, 
and  depending on some external state, I  need to force it to be in 
state B,  including having B's security settings.


I've had a look at the API, but it's all very geared towards 
transitions  rather than setting states explicitly. Before I resort to 
pdb, does anyone  know the 


relevant part of the DCWorkflow API I should use to force a  state? I 
don't mind mucking about with internals, obviously.




I once found some piece of code in the ATCT migrator once:

def migrate_workflow(self):
   migrate the workflow state
   
   wfh = getattr(self.old, 'workflow_history', None)
   if wfh:
   wfh = copyPermMap(wfh)
   self.new.workflow_history = wfh

I'd say that you might look into what workflow_history looks like. AFAIK 
the review_state is actually just the last entry in this and not 
separately saved.


-- christian


___
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

Re: [Zope-CMF] Re: Re: [Plone-developers] Re: Re: The components of Archetypes

[Christian Scholz]

Hi!

Martin Aspeli wrote:
 Hi Alec,
 
 I see that plone_schemas covers most of what I was asking about, which
 is  great :)
 
 I took a look at plone_schemas' example type. I can't get it to install 
 (Zope won't start, some conflict of versions, I'm sure), but looking at 
 the code, I notice that you
 
  - Derive from PortalContent
 
  - Define an FTI dict
 
  - Define all the DC metadata accessors manually
 
  - Define a factory method
 
  - Manually construct an FTI etc. in Install.py
 
 None of that's rocket science, but I wonder if the framework shouldn't 
 take care of some more of that. Part of the point would be to insulate 
 your content types from changes in the underlying stack, e.g. if/when
 CMF  stops using the portal_types/FTI constructs, for instance. If
 that's  starting to sound like Archetypes, though, you're right. :)
 
 So... let's think about what we really *want*:
 
  - A simple Z3 schema in an interface that defines what my content type 
 does
 
  - A component-architecture compatible way of adding behaviour and
 other  facets via adapters etc.
 
  - Something that works as a proper CMF and/or Plone (and/or CPS or 
 whatever) type, that shows up in the add menu, that interacts with
 other  Plone facilities.
 
 So - one problem is that there is a lot of Plone software out there
 that  just assumes all content types are Archetypes. I'd rather not
 worry about  that just yet, though, because we're not yet at the stage
 where we have a  realistic general alternative, and with proper
 componentisation, fixing up  those places where AT is assumed probably
 won't be too hard.
 
 But beyond that, CMF requires a lot of boilerplate, like above, that
 I'd  rather not have to remember or deal with. So, what are the options?
 
  - Having the framework inject base classes and code based e.g. based
 on  certain ZCML directives?
 
  - Using BaseContent or something similar as a base class?
 
  - Making a custom base class for plone_schemas-like content that pulls
 in  whatever CMF needs, but insulates us from future changes?

What about code generation? At least for the FTI I would like that
because I see more explicitly what is used and I can change it myself
afterwards. Same might also be possible with other types of boilerplate.

The best way would be anyway to make the components in a way to be used
with any of the above solutions.

-- christian



___
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