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]
