On 1/31/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul,
See below.
Rahul Akolkar wrote:
> On 1/31/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
<snip/>
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.
<snap/>
Bah, OK, it seems I missed one todo in code, about three lines needed
to tie the application variable resolver to the Commons SCXML context
for greater EL capabilities (such as this, arbitrary expressions
beyond simply calling action state MBEs etc). Could you file a JIRA
issue for this? Thanks! In any case, I intend to get to this later
this afternoon, so there will be one soon enough.
> 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?
<snip/>
What I meant was if we ever get into ${A and B and C or D ...} style
expressions, perhaps the procedural bits can be captured in a managed
bean method for brevity of the dialog descriptor.
I only used <target> in an attempt to get the transition working. I was
using an example from Commons SCXML's wiki.
<snap/>
You're welcome to whack any bits on the wiki that are outdated /
incorrect, if you feel like it.
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.
<snip/>
Sounds good.
-Rahul
