Wizard with dynamic state

54 views
Skip to first unread message

M. Murray

unread,
Dec 15, 2015, 12:50:04 PM12/15/15
to tryton
I have a wizard that has 4 states. 

One of the states, the second one, named component, is dynamically added to the wizard depending on what happens in the first state. The first state presents a selection field and, based on that selection, the second state is added. 

Everything seems to work fine except in two cases. (1) When many people are using it, sometimes, a user will get an error message that indicates that the server is attempting to use the wrong model for the view. This suggests that it is confusing what user A has opened vs what user B has opened. (2) If I restart the trytond when someone has the wizard open, they have to kill the client because the wizard cannot be continued or cancelled. This is because I add the state to the wizard using :

self.states['component'] = component_view

The dynamically added StateView is always called "component" and shows views from a small list of models. It is the model that is selected on the first stateview.

I think that information about the current state of the wizard is stored in-process in the server. And I suspect that this is the reason that the wizard becomes unusable if the server restarts. 

The restart issue is not a big thing. My bigger problem is figuring out how the server keeps track of who has what state/wizard open. 

The code that for the wizard and that generates the dynamic state can be found here: https://github.com/moh-gov-jm/health_encounter/blob/master/components/wizard.py

Any help would be greatly appreciated. 

---
M

Cédric Krier

unread,
Dec 15, 2015, 2:00:07 PM12/15/15
to tryton
On 2015-12-15 09:31, M. Murray wrote:
> I have a wizard that has 4 states.
>
> One of the states, the second one, named component, is dynamically added to
> the wizard depending on what happens in the first state. The first state
> presents a selection field and, based on that selection, the second state
> is added.
>
> Everything seems to work fine except in two cases. (1) When many people are
> using it, sometimes, a user will get an error message that indicates that
> the server is attempting to use the wrong model for the view. This suggests
> that it is confusing what user A has opened vs what user B has opened. (2)
> If I restart the trytond when someone has the wizard open, they have to
> kill the client because the wizard cannot be continued or cancelled. This
> is because I add the state to the wizard using :
>
> self.states['component'] = component_view
>
> The dynamically added StateView is always called "component" and shows
> views from a small list of models. It is the model that is selected on the
> first stateview.

This can not work correctly because you are updating a class attribute
'states' which is shared across all the wizard instances.

> I think that information about the current state of the wizard is stored
> in-process in the server. And I suspect that this is the reason that the
> wizard becomes unusable if the server restarts.
>
> The restart issue is not a big thing. My bigger problem is figuring out how
> the server keeps track of who has what state/wizard open.
>
> The code that for the wizard and that generates the dynamic state can be
> found
> here: https://github.com/moh-gov-jm/health_encounter/blob/master/components/wizard.py

I think you try to do something for which the wizard were not designed.
The Wizard design is based on the finite state machine so adding
dynamically new state goes against the design.

I think you should just customize a StateView to get a dynamic
model_name and view.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

M. Murray

unread,
Dec 16, 2015, 1:00:05 AM12/16/15
to tryton

On Tuesday, December 15, 2015 at 2:00:07 PM UTC-5, Cédric Krier wrote:
On 2015-12-15 09:31, M. Murray wrote:
> I have a wizard that has 4 states.
>
> One of the states, the second one, named component, is dynamically added to
> the wizard depending on what happens in the first state. The first state
> presents a selection field and, based on that selection, the second state
> is added.
>
> Everything seems to work fine except in two cases. (1) When many people are
> using it, sometimes, a user will get an error message that indicates that
> the server is attempting to use the wrong model for the view. This suggests
> that it is confusing what user A has opened vs what user B has opened. (2)
> If I restart the trytond when someone has the wizard open, they have to
> kill the client because the wizard cannot be continued or cancelled. This
> is because I add the state to the wizard using :
>
> self.states['component'] = component_view
>
> The dynamically added StateView is always called "component" and shows
> views from a small list of models. It is the model that is selected on the
> first stateview.

This can not work correctly because you are updating a class attribute
'states' which is shared across all the wizard instances.

This is the first big mistake on my part and definitely the source of the issue. 
 

> I think that information about the current state of the wizard is stored
> in-process in the server. And I suspect that this is the reason that the
> wizard becomes unusable if the server restarts.
>
> The restart issue is not a big thing. My bigger problem is figuring out how
> the server keeps track of who has what state/wizard open.
>
> The code that for the wizard and that generates the dynamic state can be
> found
> here: https://github.com/moh-gov-jm/health_encounter/blob/master/components/wizard.py

I think you try to do something for which the wizard were not designed.
The Wizard design is based on the finite state machine so adding
dynamically new state goes against the design.

I think you should just customize a StateView to get a dynamic
model_name and view.

As you can see from the code, we actually have a custom StateView as well. But, I can understand how the modification of the class attribute (using self.states) is a total violation. 

Back to the drawing board. 

Thanks Cédric.

--
MM
 
Reply all
Reply to author
Forward
0 new messages