On 1/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 1/7/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > [snip] > > * A self transition for a view state should be possible (its > > definitely legit in state chart theory, Shale dialogs being state > > charts for a specific purpose). > > > Self-transitions for a view state are definitely legal, but there's an > interesting semantic twist here. Since we are in a view state, the > transition is based on the logical outcome returned by the action method > that is invoked for the submit button that actually submits the form (phew, > say that sentence three times real fast :-). If the action method returns > an outcome that happens to map to the same view identifier, a *new* > component tree is still created, so you lose any state information you've > stored in the current component tree. If the action method returns null, on > the other hand, there is a short circuit to the normal transition mechanism > that causes the current view to be redisplayed, *without* being recreated. > > This was done deliberately, so that action methods within a dialog work > exactly the way they do outside a dialog. From a state chart perspective, > you can assume there is an additional unspecified transition that says "if > the logical outcome is null, redisplay the current component tree without > recreating it." This can be an important consideration when you are > designing the UI of your application ... even if the *user* doesn't know or > care whether a new view was created or not in this scenario, it can > dramatically simplify your dialog configuration, and your application logic, > to know that this is a scenario you can rely on. > <snip/>
That makes sense. A "stay" (null) transition should retain state, a "self" transition (amounts to calling onexit and onentry -- which gets us in initial -- for that state) should not. Now in terms of DialogNavigationHandler#transition(...) a null outcome and a stay transition seems to produce the identical State as a return value and hence identical results from a dialog progression perspective. A quick test by making the "next" transition on page 2 of the edit profile dialog (from the shale usecases war) point to the same state seemed to retain the values in the <h:inputText>s. Is my quick test missing something? -Rahul > Craig > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
