Rahul,
See below.
Rahul Akolkar wrote:
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"/>
My previous configuration was simply a summary of my attempts. Although I my
first attempt matches your suggestion, I did not included it in the example.
Below is the configuration you suggested. I suspect that SCXML is not getting
the properties from dialog.data because the value of dialog.data.leased is
always
false.
***
* Value of dialog.data fields
***
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
<state id="page1">
<onentry>
<shale:view viewId="vehicle/addPage1" />
</onentry>
<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" />
<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' and dialog.data.leased} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next' and not dialog.data.leased} = 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
_eventdata = null
_eventdatamap = null
Current States: [review]
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Can you point me to an example of this?
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)
This is good to know.
* 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.
I only used <target> in an attempt to get the transition working. I was
using an example from Commons SCXML's wiki.
* 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.
This matches my expectations. I only had two potentially evaluating to
true for debugging and testing. Once in production only 1 transition will
evaluate to true.
-Rahul
<snip>
Paul Spencer
