Hi @angus, I’ve extended the Custom Wizard Plugin with some dynamic (runtime) content functionality. I’m maintaining this on a fork at the moment and wanted to know if you’d be happy to take it into your master repo.
What does it do?
It allows the Wizard to present content to the user that is generated at runtime.
How does it do it?
I allow the developer to register a custom content code block which is called when the wizard is built and before being presented to the user.
I’ve followed your model of registering a step handler
add_step_handler and instead allow the user to register an
add_dynamic_content code block. This is called in the
steps method in
wizard.rb as the wizard is being built and the changed content is then presented to the user.
What is the use case?
I found myself using the same dropdown options across 6 wizards and when those dropdown options change - as they do, I needed to modify all 6 wizards. These dropdown options are also keys into other data structures so making a mistake in rekeying any of it would cause downstream issues.
What could be improved?
At the moment the dynamic content block manipulates the data structures inside the Wizard directly. i.e. I change a list within a hash inside the wizard. It would be far better to build those data structures with some higher level methods
remove_dropdown_option, etc. It might be that I can use or lean on your existing UI code to do that.
Risks and why you might not want this in your repo
Well, if you can manipulate the data structures inside the core code then things can go bang (very loudly!) and it might add to your support issues.
If you decide you need to change the structures inside the core code then it gives everyone a headache if they’ve added dynamic content
It might also inhibit you from making such significant internal changes due to fear of regression failures
Happy to maintain this in a fork if you feel it’s not where you want to go.