On 12/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:

I have implemented an extension of t:panelNavigation
(x:shalePanelNavigation) that set active all items of the panel that
have an action callable based of the current state of the current
dialog. At the moment I do:
- take the current state (I use an old version)
- obtain shaleState.getTransitionOutcomes() (in Iterator trans)
- for each item of the panel navigation I check if his action ha a value
present in the iterator trans
- if true I set active the item...otherwise disactive

Obviously I have some application standards to respects for a correct
use of this panel navigation, but at the moment is perfect for us.

I hope is a good reason Craig.... :)


Well, it is certainly an *understandable* reason :-).  However, I fear that
enabling access to the information you propose will affect your application
design in negative ways.  The information needed to determine what
navigation choices should be available can be stored in an application data
structure that is independent of the dialog machinery, and kept in the
"data" item, without needing any reference to the internals.

Among other things, that would let you migrate later to a more sophisticated
dialog management system like the Commons SCXML version (or even something
completely different like Spring WebFlow) without having to rearchitect
everything once the State object no longer exists :-).

Thanks in advance
Mario


Craig

Reply via email to