One StepModel versus multiple ones

didier

As a newbie using SAF, I have a methodology problem about steps with GLOW. It seems that the examples all push for one step/one page, but I might be misreading that.

But after writing a 6 step example following the one to one correspondence between steps and pages, I found myself scratching my head about what are the actual gains of doing that: it is not like steps are reusable between solutions, and I end up having to pass multiple step objects to each page, plus I keep moving data between step models. I am tempted to merge all these steps into just one.

I do not really have a question, but it sounds like the basic examples are maybe overcomplicating things, and would be clearer with a unique StepModel.

Ismael Azehaf

Hi @didier

Thank you for your question.

Indeed, the majority of our solutions currently follos the one step/one page scheme that you defined. I believe that this decomposition makes sense when it comes to guided-workflows where each step focus on a particular physics without feedback loops.

Another reason why the one step/one page scheme is promoted is to encourage solution developers to split their code into small pieces instead of ending up with big objects doing everything. We can see that as a best practice.

So I would say that it is recommended to decompose your solution, but you are not forced to do it. Your use case may justify the necessity of limiting the number of steps. That's perfectly fine.

You can have one steps, and multiple modules du manage the UI side. The opposite is also possible (multiple steps, one UI).