On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
<[email protected]> wrote:
> Dear All,
>
>
> I have a situation where I need to execute the same set of sequential
> sub-states from multiple places, and I would like to reuse an SCXML file
> multiple times in the same "master" SCXML file (via the state "src"
> attribute). I know there is a problem doing this because it would result in
> duplicated state names. I have studied the tutorial in
> http://wiki.apache.org/commons/SCXML/Tutorials/Templating, and the very last
> paragraph under "A word of caution" I think contains the key to a solution
> for me. It says that the duplicated names "can be avoided by using a
> param=value after the URL" as it mangles the URL. Does anyone have an
> example usage of this?
>
<snip/>
Not sure what the sentence in question on the wiki means either.
However, lets replay the example, say we have this reusable template
(lets call it template.scxml):
template.scxml:
<scxml ...>
<state id="foo">
...
</state>
<state id="bar">
...
</state>
</scxml>
where foo and bar do interesting things that we want to reuse in our
main.scxml. If we reference this static document multiple times like
so:
main.scxml:
<scxml ...>
<state id="s1" src="template.scxml">
...
</state>
<state id="s2" src="template.scxml">
...
</state>
</scxml>
we'll get ID clashes (for IDs foo and bar, included twice).
However, if we reference a dynamic resource (such as a JSP, lets call
this template.jsp) which allows us to tweak the IDs like the one
below:
template.jsp:
<%@ page info="SCXML template" %>
<scxml ...>
<state id="foo${param.suffix}">
...
</state>
<state id="bar${param.suffix}">
...
</state>
</scxml>
and then we reference the reusable pattern like so in our main.scxml:
main.scxml:
<scxml ...>
<state id="s1" src="template.jsp?suffix=1">
...
</state>
<state id="s2" src="template.jsp?suffix=2">
...
</state>
</scxml>
we wouldn't get any ID clashes (since we now have states with ID foo1
and bar1 as children of s1 and foo2 and bar2 as children of s2).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]