Same event cannot trigger a different transition based on current state

[penoux]

Hello,

I was about to use Xworkflows in my project, with its native support for Django. But once implemented, I discovered a limitation that I cannot overcome: the same event cannot trigger a different transition based on current state.

So, the following implementation does not work (I have commented out lines NOK).
Xworkflows definitions appear to be more transition-based than event-based...
I previously checked (and run) Fysom package, which has support for this feature, not so well integrated to Django models though.

STEP_STATES = (
('idle', _(u"Idle")),
('pending', _(u"Pending")),
('running', _(u"Running")),
('pause_requested', _(u"Pause requested")),
('stop_requested', _(u"Stop requested")),
('bypassed', _(u"Bypassed")),
('revoked', _(u"Revoked")),
('waiting', _(u"Waiting")),
('stopped', _(u"Stopped")),
('paused', _(u"Paused")),
('success', _(u"Success")),
('error', _(u"Error")),
('last_success', _(u"Last execution success")),
('last_error', _(u"Last execution error")),
)

STEP_TRANSITIONS = (
('init', 'idle', 'pending'),
('ignore', 'idle', 'idle'),
#('ignore', 'success', 'last_success'),
#('ignore', 'error', 'last_error'),
('start', 'pending', 'running'),
#('pause', 'pause_requested', 'paused'),
#('start', 'stop_requested', 'stopped'),
#('start', 'bypassed', 'bypassed'),
('bypass', ('idle', 'pending'), 'bypassed'),
('pause', ('idle', 'pending'), 'pause_requested'),
('stop', ('idle', 'pending'), 'stop_requested'),
('revoke', 'stop_requested', 'stopped'),
('wait', 'running', 'waiting'),
('continue', 'waiting', 'running'),
('success', 'running', 'success'),
('error', 'running', 'error')
)

STEP_INITIAL_STATE = 'idle'

[rbarrois]

Indeed, the current design is lacking in this regard: the main focus is on states (and reaching a new state) rather than on events.

I see two options for this feature:

• Add a higher-level "event-based" declarative API at the workflow level that states the actual transition to use for each (source_state, event) pair
• Allow multiple declarations of the same transition with distinct source states

The main issue I see with the second option is about transition implementations: the behavior would likely differ between "pause while idle" and "pause from pause_requested".

What APIs would you expect to see for this feature?

[penoux]

I think the second option is more obvious at definition stage (btw it is the one chosen by Fysom and it works well). On the behavior difference, after all it is the expectation: trigger other processing based on the event received. Callbacks should know the src, dst and state of the transition to perform different processing.

Regards

From: Raphaël Barrois [mailto:notifications@github.com]
Sent: dimanche 22 juin 2014 17:13
To: rbarrois/xworkflows
Cc: ENOUX Patrick SCE/ID ITS
Subject: Re: [xworkflows] Same event cannot trigger a different transition based on current state (#11)

Indeed, the current design is lacking in this regard: the main focus is on states (and reaching a new state) rather than on events.

I see two options for this feature:

• Add a higher-level "event-based" declarative API at the workflow level that states the actual transition to use for each (source_state, event) pair
• Allow multiple declarations of the same transition with distinct source states

The main issue I see with the second option is about transition implementations: the behavior would likely differ between "pause while idle" and "pause from pause_requested".

What APIs would you expect to see for this feature?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-46783554.

---

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.