[Feature Request] Setup Wizard

[jersiovic]

It would be useful to split setup in 1+ N steps: First step will be only for select recipe, next steps to fullfill other data (site name, connection string).

Why? Because based on this feature #396 it would allow to a recipe to take the control of the setup process very early and customise the data required to the user.

Examples of scenarios:
An scenario where I don't want to ask the user the connection string to the db because the recipe will create a db in a predefined server with a db name equal to the tenant name.
An scenario where I want the user only choose the sql server and the dbname but I don't want he provides the complete connection string.
An scenario where I don't want they provide the admin username.
An scenario where I don't want they provide the admin username and password.

In the first page of the setup user only will choose the recipe.
Then the recipe selected will be executed.
When the parameters definition step in the recipe.json is processed the setup page will be shown to the user asking user only those parameters.
Those parameters can be initialised with default values set with variables initialised by previous commands to that step based on #494

When second setup page form is submitted the recipe will continue its execution with the next steps after the parammeters initialization.
We can have as many parammeters steps as we need.

The creation of the site will be done through a command step that will execute a create site command that will receive as parameters the values needed to create the site instead of using current setup handler. In that way after read parammeters in previous steps like db server and db name we can compose the connection string and pass it through parameters to the create site command

What do you think? is it an interesting scenario to cover?

[Jetski5822]

This has been talked about before on O1.... any idea where that is?

[jersiovic]

What do you think if to make things easier to develop in a parameters definition step we also have to indicate a viewname to be rendered.
So, the developer will provide views that post data to a recipecontroller for those views.
Those views will have to follow some requisites to fit with GET and POST operations of recipecontroller.

This approach doesn't force us to generate a view on the fly based on a parameter definition step. That approach was harder of developing because we need to take into account all the user needs. However using custom views devs can provide the maximum level of customization to their views.
In the future when dynamic forms feature is available we can also support to bind a dynamic form with a parameter definition step in some way if we want to provide a less custom alternative.

[jersiovic]

Just in case anyone is waiting this feature soon. I inform you I'm going to close the PR I started to work on it because what I was attempting is not a good approach. More info on this can be found on this related issue I've just created #716
The point is due to agenda constraints I don't know when I will have time to work on this issue or the new I've created. So if you are interested on having it soon feel free to move it forward. When I have another time enough time to spend on them I will check those issues to know if there is someone working on it.

[hishamco]

I don't think @sebastienros will agree about this :) he always looking for a single and quick setup screen