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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/5d244691-86f6-4b8e-9ba8-be9d6fed13c9%40googlegroups.com.
