You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "Berg, T.W. (Tom) van den" <to...@tno.nl> on 2008/07/21 15:59:25 UTC
[SCXML] Reusing statediagrams through the src attribute in state
I would like to reuse a statediagram in an overall state diagram. The
src attribute in the state tag seems to suggest this is possible.
For example the main state.xml file would contain:
----
<state id="Composite1" src="include.xml">
<state id="finalState">
<transition target="Composite2"/>
</state>
</state>
<state id="Composite2" src="include.xml">
<state id="finalState">
<transition target="Composite3"/>
</state>
</state>
<state id="Composite3" src="include.xml">
<state id="finalState">
</state>
</state>
----
And the (simplified) include.xml looks like:
<scxml xmlns="http://www.w3.org/2005/07/scxml
<http://www.w3.org/2005/07/scxml> "
xmlns:rti="http://rti.actions/CUSTOM <http://rti.actions/CUSTOM>
"
version="1.0"
initialstate="sp">
<state id="sp">
<transition target="finalState"/>
</state>
</scxml>
----
However, this example does not work.
I get the following error:
21-jul-2008 15:50:24 org.apache.commons.scxml.io.ModelUpdater
logAndThrowModelError
SEVERE: Initial state null or not a descendant of state with ID
"Composite1"
Does nesting and state reuse work this way?
What are alternate ways to reuse state diagrams?
-- Tom
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
Re: [SCXML] Reusing statediagrams through the src attribute in state
Posted by Rahul Akolkar <ra...@gmail.com>.
Also, when using the src attribute, here is a general pattern that
supports good encapsulation practices:
<state id="foo" src="foo.xml">
<transition event="foo.done" target="bar"/>
</state>
<state id="bar">
...
</state>
On Mon, Jul 21, 2008 at 11:28 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> On Mon, Jul 21, 2008 at 9:59 AM, Berg, T.W. (Tom) van den
> <to...@tno.nl> wrote:
>> I would like to reuse a statediagram in an overall state diagram. The
>> src attribute in the state tag seems to suggest this is possible.
>> For example the main state.xml file would contain:
>>
>> ----
>>
>> <state id="Composite1" src="include.xml">
>> <state id="finalState">
>> <transition target="Composite2"/>
>> </state>
>> </state>
>>
>> <state id="Composite2" src="include.xml">
>> <state id="finalState">
>> <transition target="Composite3"/>
>> </state>
>> </state>
>>
>> <state id="Composite3" src="include.xml">
>> <state id="finalState">
>> </state>
>> </state>
>>
>> ----
>>
>> And the (simplified) include.xml looks like:
>>
>> <scxml xmlns="http://www.w3.org/2005/07/scxml
>> <http://www.w3.org/2005/07/scxml> "
>> xmlns:rti="http://rti.actions/CUSTOM <http://rti.actions/CUSTOM>
>> "
>> version="1.0"
>> initialstate="sp">
>>
>> <state id="sp">
>> <transition target="finalState"/>
>> </state>
>> </scxml>
>>
>>
>> ----
>>
>> However, this example does not work.
>>
>> I get the following error:
>> 21-jul-2008 15:50:24 org.apache.commons.scxml.io.ModelUpdater
>> logAndThrowModelError
>> SEVERE: Initial state null or not a descendant of state with ID
>> "Composite1"
>>
> <snip/>
>
> There are (atleast) three states in the above document with the same
> ID ("finalState"), which violates the uniqueness constraint.
>
>
>> Does nesting and state reuse work this way?
> <snap/>
>
> Yes, when done right. Some notes contributed by users to the wiki on
> this topic may also be helpful:
>
> http://wiki.apache.org/commons/SCXML/Tutorials/Templating
>
>
>> What are alternate ways to reuse state diagrams?
>>
> <snip/>
>
> I know folks have suggested using XML entities, but that doesn't
> necessarily address "importing" such fragments multiple times into the
> same SCXML state machine definition.
>
> -Rahul
>
>
>>
>> -- Tom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Reusing statediagrams through the src attribute in state
Posted by Rahul Akolkar <ra...@gmail.com>.
On Mon, Jul 21, 2008 at 9:59 AM, Berg, T.W. (Tom) van den
<to...@tno.nl> wrote:
> I would like to reuse a statediagram in an overall state diagram. The
> src attribute in the state tag seems to suggest this is possible.
> For example the main state.xml file would contain:
>
> ----
>
> <state id="Composite1" src="include.xml">
> <state id="finalState">
> <transition target="Composite2"/>
> </state>
> </state>
>
> <state id="Composite2" src="include.xml">
> <state id="finalState">
> <transition target="Composite3"/>
> </state>
> </state>
>
> <state id="Composite3" src="include.xml">
> <state id="finalState">
> </state>
> </state>
>
> ----
>
> And the (simplified) include.xml looks like:
>
> <scxml xmlns="http://www.w3.org/2005/07/scxml
> <http://www.w3.org/2005/07/scxml> "
> xmlns:rti="http://rti.actions/CUSTOM <http://rti.actions/CUSTOM>
> "
> version="1.0"
> initialstate="sp">
>
> <state id="sp">
> <transition target="finalState"/>
> </state>
> </scxml>
>
>
> ----
>
> However, this example does not work.
>
> I get the following error:
> 21-jul-2008 15:50:24 org.apache.commons.scxml.io.ModelUpdater
> logAndThrowModelError
> SEVERE: Initial state null or not a descendant of state with ID
> "Composite1"
>
<snip/>
There are (atleast) three states in the above document with the same
ID ("finalState"), which violates the uniqueness constraint.
> Does nesting and state reuse work this way?
<snap/>
Yes, when done right. Some notes contributed by users to the wiki on
this topic may also be helpful:
http://wiki.apache.org/commons/SCXML/Tutorials/Templating
> What are alternate ways to reuse state diagrams?
>
<snip/>
I know folks have suggested using XML entities, but that doesn't
necessarily address "importing" such fragments multiple times into the
same SCXML state machine definition.
-Rahul
>
> -- Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org