On 1/31/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2 if the
property Leased is checked on the page1, otherwise go to page2. Neither is
happening!
When the cancel button is clicked, the transition to menu works as expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
<state id="page1">
<onentry>
<shale:view viewId="vehicle/addPage1" />
</onentry>
<transition cond="${dialogData.licenseTag eq 'test'}"
target="page2" />
<transition cond="${dialog.data.licenseTag eq 'test'}"
target="page2" />
<transition cond="${dialog.data.lease}"
target="page2" />
<transition event="faces.outcome" cond="${outcome eq 'next'}">
<if cond="${dialog.data.leased eq 'true'}">
<target next="page2" />
<else>
<target next="review" />
</else>
</if>
</transition>
<snip/>
The target of a <transition> element cannot be determined at runtime
(if we think of this in terms of a state chart diagrams, when we start
to draw a transition we need to also know the "end point/state", can't
have it TBD amongst some candidates) -- a slight exception is
<history> (but thats OT, see SCXML WD or Commons SCXML test suite /
site for semantics).
But another way to look at this is that we simply have compound
conditional expressions, i.e. the one <transition> above whose target
we're trying to determine using conditionals (<if>) is conceptually
equivalent to the two <transition>s below (untested):
<transition event="faces.outcome"
cond="${outcome eq 'next' and dialog.data.leased}"
target="page2"/>
<transition event="faces.outcome"
cond="${outcome eq 'next' and not dialog.data.leased}"
target="review"/>
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Other observations probably relevant here:
* Generally, all outbound transitions from a view state should be
guarded by the "faces.outcome" event (or they may be followed
immediately if the cond is satisfied)
* The latest SCXML WD [1] (Jan '06) has removed the <target> element
(though the 0.x line of Commons SCXML supports it for backwards
compatibility). It is recommended to use the target attribute of
<transition> instead (and once thats done, it becomes hard to provide
more than one based on some conditional logic anyway). The SCXML
examples in the Shale test app use the newer variants of any such spec
changes.
* Upto v0.6 of Commons SCXML, the conds are expected to be mutually
exclusive (no two -- or more -- should evaluate to true at the same
time in a given scenario). That will lead to non-determinism, and the
related error being reported. I think the spec may talk about document
order priorities in the next rev.
-Rahul
[1] http://www.w3.org/TR/scxml/
<transition target="menu" event="faces.outcome"
cond="${outcome eq 'cancel'}" />
</state>
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next'} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialogData.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.lease} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.leased eq 'true'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [page1]
Paul Spencer
<snap/>
