Here is the basis of the change.
And here's the background.
So prior to v2 where there are now potentially other ways of doing this, I needed a way to pass dynamic values into the wizard.
i.e. to pre-populate dropdown lists dynamically to allow for scenarios where I need a value from
step_1 to create a dynamic set of dropdown options in
step_2 for example.
I should say at this point that I’ve just assembled enough Ruby skills to be dangerous but Ember remains out of my grasp for the moment. As the saying goes “If all you have is a hammer, everything looks like a nail”.
So as I could only conceive this as a Ruby-based solution I changed the Wizard builder. I’ve basically copied @angus’s step handler validation model where blocks of code are registered and then called when needed.
If certain conditions are met, my
content_providers approach calls out to blocks of pre-registered code that it expects to update the default values of the field.
It’s simple but it works. It does rely on manipulating internal structures within the
step_updater which isn’t ideal.
Separately, and as you’ll see in the commit above, I also came across a show-stopper in my validation routines. I’m surprised others haven’t had this issue with v2 - or I’m missing something.
Now that the field id is auto-generated, two or more wizards can, in fact, will have the same field id
When all you’re passed in the validation routine is the field id this makes validation impossible as you can’t uniquely identify a field across many different wizards.
I had to make
wizard accessible from outside the
step_updater object so that I could combine
wizard.id with the
field.id to get something unique.
On dynamic content, Angus has (understandably) suggested that he’d like to achieve the same result in the client and not the backend. So he would prefer to focus efforts there.
So for the time being, I’m going to have to maintain the fork.
I work in schools with children that have behavioural challenges and have developed a complete system to manage their day using Polls in Discourse to capture responses to questions, and I use the CWP to interface with the user on specific, real-time tasks.
I have to say that if, like me, you not a full-time developer and don’t have the time or knowledge to understand the complexities of Ember, using the CWP as your user interface is fantastic.
I have encapsulated the validation of fields, the population of dynamic fields and the capturing of multi-step wizard results into more intuitive fields names into a singe
WizardManager object like this.
class CreatePointsCards < WizardManagerBase
@wizard_id = 'create_new_blank_points_cards'
all_children = DynamicContent::AllChildren.new
It works really well.