On 10/17/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On 10/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Thanks. I have a patch but its at work and I'm working from home > > today. So I will file the issue and patch on Monday. > > > <snip/> > > Thanks for attaching a patch to 37120 [1], in this case, it helped > (me, atleast) to have code to look at :-) I tend to agree with your > observation that this does not entirely address the problem.
For example, state charts notations tend to allow: > * Event-less transitions (just guard conditions i.e. null event) > * Self transitions (current state is transition target, requires > re-entry i.e. calling onexit handler, followed by onentry) > * Stay transitions (a transition that doesn't have a target, used > primarily for executable content ontransition). > > Some of the above might manifest into null outcomes, in which case, it > might make sense to not delegate to the default NavigationHandler > (even if the outcome is null). I believe a suitable approach here will > tend to be along these lines: > > * Delegate to DialogNavigationHandler when dialog is running. > * DialogNavigationHandler determines if the outcome was of any > consequence to this dialog. Hmm ... it's not clear how DialogNavigationHandler is supposed to make this determination. Wouldn't we need some special transition that dealt with a null outcome, and a way to say "stay where you are" in that case? * Inconsequential triggers, then [since we have determined, do not > pertain to the dialog on hand], become suitable candidates to be > rewired to the default JSF NavigationHandler. I suppose one could generalize that to say any outcome (or, at least one returned by a view state) for which there is no defined transition should be deledgated. If I have some code which we can stare at, I'll post some more later > in the week. > > -Rahul > > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120 > > > > > > sean > > Craig
