-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am I right in thinking that DCWorkflow does not send any Zope 3
events? I'm not terribly familiar with that code, but some grepping
suggests so.
Do you agree this would be useful? (I've got a pretty strong need
for it for Plone 3, i.e. CMF
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am I right in thinking that DCWorkflow does not send any Zope 3
events? I'm not terribly familiar with that code, but some grepping
suggests so.
Do you agree this would be useful? (I've got a pretty strong need for
it for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 11:41, Martin Aspeli wrote:
Right, I hope that helps anyway - sorry I can't just put it in
myself right now, but if someone else has a need or a wish, I'd be
really grateful if they could shepherd this in. :)
You need to
Jens Vagelpohl wrote:
You need to provide full patches and find someone who has the time - I'm
afraid I don't. The best solution would be for you to get in touch with
Jim and get a contributor agreement going. That's not rocket science.
This turned out to be easier than I feared. I've put a
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote:
P.S.: I _hate hate hate_ doctests ;)
Why?
--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
signature.asc
Description: This is a digitally signed message part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi guys,
Am I right in thinking that DCWorkflow does not send any Zope 3 events?
I'm not terribly familiar with that code, but some grepping suggests so.
Do you agree this would be useful? (I've got a pretty strong need
I think there was something else that needs handling in this event
effort. There's an exception that is raised when an object is moved
within a transition to signal the move. That should be converted to an
event, and the corresponding exception handling in the WorkflowTool
should be converted to
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Sidnei da Silva wrote:
I think there was something else that needs handling in this event
effort. There's an exception that is raised when an object is moved
within a transition to signal the move. That should be converted to an
event, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 16:16, Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote:
P.S.: I _hate hate hate_ doctests ;)
Why?
I won't speak for Jens, but I find they have two serious drawbacks
when
used
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 16:16, Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote:
P.S.: I _hate hate hate_ doctests ;)
Why?
I won't speak for Jens, but I find they have two serious
Tres Seaver wrote:
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 17:15, Martin Aspeli wrote:
From painful experience with the customer work right now, and
from the work on the CMF branch to convert tools to utilities I'll
add that they make debugging a lot harder (where can I step into
Tres Seaver wrote:
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The
Something that strikes me, by looking at this code is that we also
want events that map to 'notifySuccess' and 'notifyException' too (ie,
ITransitionSuccessEvent and ITransitionFailureEvent), not only
'before'/'after'. (see _invokeWithNotifications).
Those could be fired from the
Jens Vagelpohl wrote:
The testbrowser tests tend to be the worst when it comes to failures
early on and then spewing out never-ending messages because the browser
ist messed up at that point.
Yes, this is true - they can be pita when you have complex pages (like
Plone).
Martin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 16:16, Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote:
P.S.: I _hate hate hate_ doctests
Hi Tres,
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The transition
Sidnei da Silva wrote:
Something that strikes me, by looking at this code is that we also
want events that map to 'notifySuccess' and 'notifyException' too (ie,
ITransitionSuccessEvent and ITransitionFailureEvent), not only
'before'/'after'. (see _invokeWithNotifications).
Those could be fired
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I don't think I fully understand the use case or usage of
notifySuccess() and notifyException(). They are called by
portal_workflow, on the workflow definition. They don't seem to be used
in the current code at least.
There is at least two
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I don't think I fully understand the use case or usage of
notifySuccess() and notifyException(). They are called by
portal_workflow, on the workflow definition. They don't seem to be used
in the current code at least.
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I agree that maybe this refactoring is lower priority, I'm just making
sure it's not forgotten just because the main workflow used is
DCWorkflow, and maybe clarifying some not-so-clear use cases beyond
DCWorkflow's owns.
Right. It strikes
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I agree that maybe this refactoring is lower priority, I'm just making
sure it's not forgotten just because the main workflow used is
DCWorkflow, and maybe clarifying some not-so-clear use cases beyond
DCWorkflow's
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Right - that was the question I was asking. *Is* this an event that's
useful outside the framework?
I believe so. For example, a subscriber that wants to know if an
action has succeeded, no matter where/when, so it can purge an
external cache
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Right - that was the question I was asking. *Is* this an event that's
useful outside the framework?
I believe so. For example, a subscriber that wants to know if an
action has succeeded, no matter where/when, so it can
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Where would this go?
My first patch (btw, anyone up for merging it?) was to DCWorkflow.
I could make another one to WorkflowTool, I guess, if you can suggest
where and what payload it needs (it's hardly difficult to fire an
event).
That
25 matches
Mail list logo
