On 7/20/06, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
Hello Rahul ... could we reopen this issue? Seems like the w3c working group is in its way to accept nested <if>. Please could you read below the answer from them as well as my reply about even the use of the <script> tag?
<snip/> I probably wasn't clear in my closing comment on SCXML-12 [1]. Nested <if> statements should be no trouble. What I meant by <elseif> and <else> being partitions, rather than containers, is that the following snippet (as well as the snippet you post below) is malformed: <if cond="..."> <!-- if actions --> <else> <!-- else actions --> </else> </if> whereas it should be: <if cond="..."> <!-- if actions --> <else/> <!-- else actions --> </if> Further, the "if actions" or "else actions" may themselves contain other if statements, and this may recurse to any arbitrary levels of nesting.
I am currently with a lot of business rules to evaluate and definetely when it comes to complexity a good flow control/scripting mechanism is needed.
<snap/> Commons SCXML will not develop a scripting language. However, if there are expression languages that support scripting (neither EL nor JEXL's latest releases support that -- EL won't ever, JEXL has script support available in SVN trunk ATM so its next release should) they may be plugged in to provide such <script> support. However, that is unlikely to happen before a Commons SCXML 1.0 release (we're currently aiming for a 0.5 release). Note that a refined datamodel with a well-defined event lifecycle can provide useful hooks for actions rather than resorting to ad-hoc scripting. Time will tell us what the SCXML datamodel ends up looking like. -Rahul [1] http://issues.apache.org/jira/browse/SCXML-12
That is my goal right now ... to make scxml suitable for modeling and configuring complex business processes like the State Oriented Business Protocol I am building for my Company. Thanks!, Nestor *************************************** w3c thread: **************************************** Thanks a lot Barnett. Just for your information I am using commons-scxml to manage a State Oriented Business Protocol based on Harel Statecharts. As the business rules grow the complexity needed grows as well and without good flow control it is kind of difficult to get efficient results. I was wondering if besides having nested conditions wouldn't be wonderful to be able to use the <script> element (http://www.w3.org/TR/scxml/#N107D9) using ECMA inside or why not as commons-scxml has proposed jexl or je as scripting languages. Do you think it makes sense to use a <script> portion inside an <onentry> just to setup final variables that could be tested later on the <onentry> or <transiton> internal FSM events? Thanks!, Nestor --- "Barnett, James" <[EMAIL PROTECTED]> wrote: > Nestor, > After a little discussion in the group, it turns > out that we weren't > very clear on this either. However, we have > provisionally decided to > allow them since VoiceXML does. We will clarify the > issue in the next > public draft. > > - Jim > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Nestor Urquiza > Sent: Friday, July 14, 2006 8:09 AM > To: [EMAIL PROTECTED] > Subject: [scxml] nested conditions > > > Hello all, > After reading http://www.w3.org/TR/scxml/#N109D0 it > is > not clear to me if nested "<if>" are allowed. With > an > example is the code below supposed to be scxml > valid? > ... > <n:if cond="status1 eq 'false'"> > <!-- a first nested condition --> > <n:if cond="status2 eq 'true' "> > <n:assign name="result" expr="'status1 > false'"/> > <n:else> > <n:assign name="result" expr="'statuses > false'"/> > </n:else> > <n:else> > <!-- another nested condition --> > <n:if cond="status2 eq 'true' "> > <n:assign name="result" expr="'statuses > true'"/> > <n:else> > <n:assign name="result" expr="'status2 > false'"/> > </n:else> > </n:else> > </n:if> > > Thanks, > Nestor ************************************** end w3c thread ***************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
