[Zope-CMF] Re[2]: DCWorkflow + Acqusition
Hello Florent Guillaume, Monday, October 24, 2005, 7:47:43 PM, you wrote: FG They're not skipped, they're treated specially. These exceptions are the way FG for transition code to notify the caller that something happened to the FG underlying object. But what preventtoraiseObjectMoved, ObjectDeleted in nofityException,notifySuccess? I.e. DCWorkflowDefinition.notifyCreated swallow ObjectDeleted, ObjectMoved. Why? if ObjectMoved raised in DCWorkflowDefinition.notifyCreated, WorkflowTool.notifyCreated doen`t know about that, and def notifyCreated(self, ob): Notify all applicable workflows that an object has been created and put in its new place. wfs = self.getWorkflowsFor(ob) for wf in wfs: wf.notifyCreated(ob) self._reindexWorkflowVariables(ob) -- ob reindexed in a wrong acquisition wrapper. -- Best regards, Victor Safronovich NauMen.NauDoc.SoftwareDeveloper http://www.naumen.ru ___ 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: DCWorkflow + Acqusition
Victor Safronovich wrote: Hello Florent Guillaume, Monday, October 24, 2005, 7:47:43 PM, you wrote: FG They're not skipped, they're treated specially. These exceptions are the way FG for transition code to notify the caller that something happened to the FG underlying object. But what preventtoraiseObjectMoved, ObjectDeleted in nofityException,notifySuccess? That's not what these methods are for. ObjectMoved and ObjectDeleted are designed to be raised by workflow scripts, during the transition, to inform the workflow machinery that the transition left the object in an unexpected place. notifySuccess marks the end of the transition, and is designed similarly to an event mechanism, to inform interested parties that the transition is complete. If it raises exceptions, then they won't be caught. Florent I.e. DCWorkflowDefinition.notifyCreated swallow ObjectDeleted, ObjectMoved. Why? if ObjectMoved raised in DCWorkflowDefinition.notifyCreated, WorkflowTool.notifyCreated doen`t know about that, and def notifyCreated(self, ob): Notify all applicable workflows that an object has been created and put in its new place. wfs = self.getWorkflowsFor(ob) for wf in wfs: wf.notifyCreated(ob) self._reindexWorkflowVariables(ob) -- ob reindexed in a wrong acquisition wrapper. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: getActionById replacement
yuppie wrote:
getActionObject(action_path) is the method you are looking for.
getActionById is defined as public, getActionObject as private, so you
can't use it in any skin scripts or templates :-(
Can't see why you would need that method in the skins.
Okay, so how would you get the url for an action from inside a skin
script or template?
Unless someone bribes me I'll not help cleaning up the mess in Plone.
Yes, I wish I didn't have to either, but work with me on this, okay?
I'm not asking you to clean up the Plone mess, I'm asking you to explain
what pattern should be used in CMF 1.5 for something which was common in
CMF 1.4 (I have examples of this from totally non-Plone CMF projects,
and they face the same problems: What to replace getActionById with,
especially when it's used in skin script?)
BTW: IIRC Kapil has a Plone version that works with CMF trunk. That
would mean that he resolved all the deprecation warnings.
Just to emphasise further, I'm looking to document by way of mailing
list archives, what the correct way to replace getActionById calls is,
regardless of whether you're using Plone, CPS, or just plain CMF...
Also, can you explain what type_info.getActionInfo('object/view')['url']
is supposed to return?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
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: getActionById replacement
yuppie wrote: This is in a completely set up Plone site? Could you please try to debug those values while we are still in customizePortalTypes? Okay, in there, it's just the normal Plone types, which we don't use. And yes, their _aliases dict appears to have 'view' keys which map to the right thing. So, I guess maybe this is an Archeturds thing? Do they somehow screw up their TI's such that they don't have a sensible _aliases attribute? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: getActionById replacement
Hi Chris!
Chris Withers wrote:
yuppie wrote:
Okay, so how would you get the url for an action from inside a skin
script or template?
obj.getActionInfo('object/view')['url'] for type actions or
provider.getActionInfo('user/join')['url'] for other actions.
Just to emphasise further, I'm looking to document by way of mailing
list archives, what the correct way to replace getActionById calls is,
regardless of whether you're using Plone, CPS, or just plain CMF...
Also, can you explain what type_info.getActionInfo('object/view')['url']
is supposed to return?
getActionInfo() returns an ActionInfo object as defined in
interfaces.portal_actions.ActionInfo. (Note that ActionInfo and
ActionInformation are two different classes: ActionInformation is the
class of the persistent action object, not of the info dict created
based on that object.)
- url (string): URL to access the action
This is the result of the url expression in the current request context.
It is always useful if you want a link or redirect target - for
traversal use queryMethodID instead.
Please read the interfaces and grep for examples in the CMF source.
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: getActionById replacement
Chris Withers wrote:
yuppie wrote:
This is in a completely set up Plone site? Could you please try to
debug those values while we are still in customizePortalTypes?
Okay, in there, it's just the normal Plone types, which we don't use.
And yes, their _aliases dict appears to have 'view' keys which map to
the right thing.
So, I guess maybe this is an Archeturds thing? Do they somehow screw up
their TI's such that they don't have a sensible _aliases attribute?
The _aliases attribute is an implementation detail of default FTIs. ATCT
uses CMFDynamicViewFTI which has a different implementation of
queryMethodID.
The MethodID returned by CMFDynamicViewFTI depends on the specific
object, so you have to pass the object to queryMethodID:
ti.queryMethodID('view', object)
HTH, 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
