Multiway wizard

Hi all,

  I wonder if I can make a wizard with the same logical shape of a tree
depending on the choices made by the user in the cards or "nodes" in
this case.

 As far as I see, the actual wizard (including the ones I've made) are
linear as a Collection from the logical point of view.

 Note the implications of the nextCard and previousCard that should
allow the user to "navigate" this tree.

  Any clue or idea would be appreciated.

Seb

Seb,

If I understand you correctly, I do similar things as follows:

        ( self view viewNamed:'ReadOnlyAccess' ) ensureVisible.

The cards remain a flat collection, but you can bounce the user around
as needed.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Dear Bill,

  how do you handle the "navigation" in that way?

  I mean... the user can freely navigate the tree of options. Where do
you have that tree? how do you control the nextCard and previousCard
commands go to?

 For example the user advance 3 pages straight foward (the only way
until card 4 let him choose 2 ways). He(she) changes the state of the
model a little more. When card 4 is shown he(she) chooses to go the
"the option 1 way" (of 3 available options) straight foward 3 cards,
then back again because the user is changing his(shes) mind.

  I'm thinking now about making it with aCardNode. Some kind of cursor
that could be configurated with prerequisites (to eventually forbid to
go in some way) and previous cards an childrens ones. It could be
created at wizard's creation time.

  What do you think? opinions?

  Any comments are welcome

 regards,

Seb

Seb,

>   how do you handle the "navigation" in that way?

I suspect I might be missing your point a little, so feel free to
continue pounding until somebody gets it and helps you.


>   I mean... the user can freely navigate the tree of options. Where do
> you have that tree? how do you control the nextCard and previousCard
> commands go to?

Don't control previous and next - get rid of them.  Of course, you can
have buttons that are LABELED "<< Back" and "Next >>".  Those buttons
will be connected to different commands that will decide which card to
display and then use #ensureVisible to display it.

The back button should probably do just that: send the user to the card
before the current card, which sounds like a job for some kind of
history list.  The next command could look at any number of things,
including radio buttons on the current card, to decide where to send the
user.

Does that help?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Sebastian,

if I'm not mistaken you're talking about 2 different problems.

1. One is the business logic ie. what options he has left once he has
decided for a certain option.

2. The necessary methods to display the logically following tab.

As for 2. the question has been basically answered in the previous posts.

As for 1. the solution would be to implement a "Finite State Automaton"
by using the "State Pattern" as described in the "Design Patterns
Smalltalk Companion".

A Google search for those keywords should help you.

Best regards,

Günther

Yes, Günther my friend, that's the scenario for this case. But I
didn't use aFinite State Automaton". Not as the pattern intent to.

Just for reference I would say that to solve this I've made a tree
model of the logic with aMonooptionalNode and MultioptionalNode.
Monooptional are pretty much like a double linked list node with
anOptionModel (who has #requisites and #action blocks). The
Multioptional are like the node of a multiway tree and also has it's
own #option and #selectedOption beside of the childrens and the
previous node.

Instanciating them, with the precise actions and requisites, let me
configure the logical path of the wizard.

The nice part of the requisites is that if they are not comply at some
point, the user has for instance the #nextCard button disabled, so the
result of the whole thing is that I have not only the logic correctly
modeled in a very flexible way, but also a presenter with all the
application domain modeled in it, that allways returns it's model, only
in valid states.

Best regards,

Sebastián Sastre