Craig,
Thanks for the feedback. There is a slight twist to my usecase that I
don't think I mentioned. We have created a LookupDialog which takes a
'start' and 'stop' attribute. It allows you to use a portion of
another dialog. I know there is <subdialog> but that is to cumbersome
when you have a dialog of 10 steps but then want to allow the user to
go back and change just one piece of information from one step.
We also have a common set of buttons that we resuse through tiles. If
its a single step dialog we just have an OK and CANCEL button. If
there are multiples steps we have PREV NEXT and CANCEL. Whether or
not we show the NEXT button depends on if there is a "next" transition
available. To use your solution, there would be a next transition (it
would be an ActionState which checks for matches) but its not a
visible transition.
Any thoughts on this wrinkle? Also, if you're interested I can show
you the code I added for LookupDialog. Even if you don't use it, you
might be interested to see how people are using Shale.
Regards,
sean
On 7/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 7/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > I have an interesting usecase that I'd like some feedback on. I'm
> > working with Shale dialogs and I have a special situation with a multi
> > step dialog.
> >
> > Say there are two steps 1 + 2. Step 1, user enters an applicant name.
> > Before moving to step 2, we'd like to check and see if that name
> > already exists or if there are similar names. So there is an optional
> > dialog screen in between steps 1 + 2 where we say that a similar name
> > has been found and would you like to: a.) pick from the list of
> > similar names b.) continue with the name you chose or c.) return back
> > to step 1 and try a new one.
> >
> > What I've done so far is to combine step 1 and the "optional" screen
> > onto the same JSP and conditionally render one or the other based on a
> > value from a backing bean. So hitting next button on step 1 navigates
> > you to an action state where a method on the same backing bean is
> > called and a check is performed. If the check fails, I throw an
> > AbortProcessingException, etc.
> >
> > Initially I wanted to just use a custom validator but there was one
> > problem. The validation requires values that are being mapped to
> > #{dialog.data} and those values aren't updated yet at this point in
> > the JSF lifecycle. Its important that the bean be populated before
> > the check because even after an error, the user might want to go on to
> > the next step (which is permissable.)
> >
> > Any ideas on this? It seems like I am looking for a second validation
> > phase after the Update Model phase.
>
> Regardless of the technology you use, this still sounds more like a
> three-screen dialog rather than a two-plus-a-validation-error dialog.
> In terms of Shale's dialogs, I'd model it like this:
>
> * View State "Get Application Name", which accepts the name to search for.
> The action that processes the submit does the lookup, and then returns
> one of the following outcomes, which you'd map to different next states:
> - "No Matches" -- Redisplay the same state (perhaps this one is
> actually a validator)
> - "One Match" -- Transition to the "Exact Match" state
> - "Multiple Matches" -- Transition to the "Multiple Matches" state
>
> * View State "Multiple Matches" displays the set of close matches, and lets
> the user pick one of them. The outcome when they do would be "One Match",
> which transitions to the "Exact Match" state.
>
> * View State "One Match" displays the one-and-only match, and
> continues from there.
>
> If you generalize this slightly, the same design pattern works just
> fine for a dialog to process pretty much any sort of a search widget
> -- if there's only one match, go display it directly; if there's more
> than one, offer the choices; and if there are no matches redisplay the
> search screen (perhaps with an error message suggesting that the user
> broaden their search).
> >
> > TIA,
> >
> > sean
> >
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
