You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "Lee, Cheryl - ES/RDR -Gil" <Ch...@itt.com> on 2009/01/07 22:45:19 UTC
SCXML Templating
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?
Thanks!
Cheryl
________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
RE: SCXML Templating
Posted by "Lee, Cheryl - ES/RDR -Gil" <Ch...@itt.com>.
OK, thanks a bunch for your help. I get it. Right now everything is
local. I'll see what I can rig up to make this work locally or
determine that I need some other approach like you've outlined using
JSP.
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Thursday, January 08, 2009 10:42 AM
To: Commons Users List
Subject: Re: SCXML Templating
On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
<Ch...@itt.com> wrote:
> Thanks for your response.
>
> I'm not familiar with using a JSP (assume are we talking Java Server
> Pages?) in the context of my application. Mine is a stand-alone Java
> GUI application using Swing with the state machine to respond to user
> actions and other system actions. Is there a way to use a dynamic
> resource without using JSP? If so, what would an example look like?
>
<snip/>
It doesn't have to be a JSP, it was used for illustration. All we're
saying is use a dynamic URL to tweak the IDs as needed. If everything
has to be local (no servlet container, web server or any type of
remote service access), then it may not be straightforward to create
such a dynamic URL (custom protocol handlers for the java.net.URL
architecture or other fancy footwork perhaps).
-Rahul
> Thanks a bunch,
> Cheryl
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Wednesday, January 07, 2009 10:38 PM
> To: Commons Users List
> Subject: Re: SCXML Templating
>
> On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
> <Ch...@itt.com> 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
>
> This e-mail and any files transmitted with it may be proprietary and
are intended solely for the use of the individual or entity to whom they
are addressed. If you have received this e-mail in error please notify
the sender.
> Please note that any views or opinions presented in this e-mail are
solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments
for the presence of viruses. ITT accepts no liability for any damage
caused by any virus transmitted by this e-mail.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Joel Truher <jo...@truher.org>.
On Thu, Jan 8, 2009 at 11:22 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> I'm not sure if you are saying you avoid templating or use some other
> authoring pattern (if you'd like to share with all users, you can
> create a wiki page if you want). The wiki is here [1] and open to all
> (after a quick registration).
I'm just saying I avoided templating.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Jan 8, 2009 at 3:02 PM, Roger Hoover <ro...@gmail.com> wrote:
> Hi Rahul,
>
> Please enlighten me if I'm missing something.
>
> It seems like the only reason that state names must be globally unique is
> that they need to be referenced by name in transitions. Why not reference
> them by something similar to XPath? In the example you gave earlier, the
> states could be uniquely identified by expressions such as "s1/foo, s1/bar,
> and s2/foo, s2/bar?
>
> In this way, the names would need to be unique only in their scope but not
> unique globally. I think it would make modularizing SCXML easier. What you
> think?
>
<snip/>
I will note that this list merely concerns itself with the Commons
SCXML implementation. There is a public W3C list as well, which
collects spec feedback.
But briefly, IMO the idea you suggest clearly solves one problem, but
its loses some of the existing simplicity (keeping track of the
pseudo-XPath notation can get quite cumbersome) and doesn't align with
the state chart theory that SCXML is based on (neither Harel nor UML2
use such a notation).
-Rahul
> Roger
>
>
> On Thu, Jan 8, 2009 at 11:22 AM, Rahul Akolkar <ra...@gmail.com>wrote:
>
>> On Thu, Jan 8, 2009 at 2:04 PM, Joel Truher <jo...@truher.org> wrote:
>> > I'm curious about this topic, Rahul, since I encountered it as well.
>> >
>> > The solution you suggest seems to me to be external to SCXML, and it
>> > made me wonder if this sort of templating ought to be supported more
>> > natively, or if there's a design argument to exclude it?
>> >
>> > I searched for a way to avoid templating, since it does seem foreign
>> > to the state-chart idea (as well as other implementations of it, e.g.
>> > Boost.Statechart). I eventually succeeded, and I think my design is
>> > better for it. So maybe the exclusion of templates is a good design
>> > choice. Is that how you see it?
>> >
>> <snip/>
>>
>> It has been a conscious design choice so far to say that ensuring the
>> uniqueness of IDs is the responsibility of the document author in all
>> cases. Some solutions were considered IIRC to automatically introduce
>> some sort of scoping or ID-munging to get around this issue of src'ing
>> in the same document multiple times, but none were found to be
>> satisfactory. Given that SCXML will very likely be used to design
>> systems that are distributed, reactive and heterogeneous it was
>> considered that its not a stretch to say use a dynamic URL here. The
>> advantage of the example approach outlined here is that it gives the
>> author complete control over how the IDs will be treated every time,
>> and these are therefore predictable at design-time.
>>
>> I'm not sure if you are saying you avoid templating or use some other
>> authoring pattern (if you'd like to share with all users, you can
>> create a wiki page if you want). The wiki is here [1] and open to all
>> (after a quick registration).
>>
>> -Rahul
>>
>> [1] http://wiki.apache.org/commons/SCXML/HomePage
>>
>>
>>
>> >
>> > Joel
>> >
>> >
>> > On Thu, Jan 8, 2009 at 10:41 AM, Rahul Akolkar <ra...@gmail.com>
>> wrote:
>> >> On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
>> >> <Ch...@itt.com> wrote:
>> >>> Thanks for your response.
>> >>>
>> >>> I'm not familiar with using a JSP (assume are we talking Java Server
>> >>> Pages?) in the context of my application. Mine is a stand-alone Java
>> >>> GUI application using Swing with the state machine to respond to user
>> >>> actions and other system actions. Is there a way to use a dynamic
>> >>> resource without using JSP? If so, what would an example look like?
>> >>>
>> >> <snip/>
>> >>
>> >> It doesn't have to be a JSP, it was used for illustration. All we're
>> >> saying is use a dynamic URL to tweak the IDs as needed. If everything
>> >> has to be local (no servlet container, web server or any type of
>> >> remote service access), then it may not be straightforward to create
>> >> such a dynamic URL (custom protocol handlers for the java.net.URL
>> >> architecture or other fancy footwork perhaps).
>> >>
>> >> -Rahul
>> >>
>> >>
>> >>> Thanks a bunch,
>> >>> Cheryl
>> >>>
>> <snap/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Roger Hoover <ro...@gmail.com>.
Hi Rahul,
Please enlighten me if I'm missing something.
It seems like the only reason that state names must be globally unique is
that they need to be referenced by name in transitions. Why not reference
them by something similar to XPath? In the example you gave earlier, the
states could be uniquely identified by expressions such as "s1/foo, s1/bar,
and s2/foo, s2/bar?
In this way, the names would need to be unique only in their scope but not
unique globally. I think it would make modularizing SCXML easier. What you
think?
Roger
On Thu, Jan 8, 2009 at 11:22 AM, Rahul Akolkar <ra...@gmail.com>wrote:
> On Thu, Jan 8, 2009 at 2:04 PM, Joel Truher <jo...@truher.org> wrote:
> > I'm curious about this topic, Rahul, since I encountered it as well.
> >
> > The solution you suggest seems to me to be external to SCXML, and it
> > made me wonder if this sort of templating ought to be supported more
> > natively, or if there's a design argument to exclude it?
> >
> > I searched for a way to avoid templating, since it does seem foreign
> > to the state-chart idea (as well as other implementations of it, e.g.
> > Boost.Statechart). I eventually succeeded, and I think my design is
> > better for it. So maybe the exclusion of templates is a good design
> > choice. Is that how you see it?
> >
> <snip/>
>
> It has been a conscious design choice so far to say that ensuring the
> uniqueness of IDs is the responsibility of the document author in all
> cases. Some solutions were considered IIRC to automatically introduce
> some sort of scoping or ID-munging to get around this issue of src'ing
> in the same document multiple times, but none were found to be
> satisfactory. Given that SCXML will very likely be used to design
> systems that are distributed, reactive and heterogeneous it was
> considered that its not a stretch to say use a dynamic URL here. The
> advantage of the example approach outlined here is that it gives the
> author complete control over how the IDs will be treated every time,
> and these are therefore predictable at design-time.
>
> I'm not sure if you are saying you avoid templating or use some other
> authoring pattern (if you'd like to share with all users, you can
> create a wiki page if you want). The wiki is here [1] and open to all
> (after a quick registration).
>
> -Rahul
>
> [1] http://wiki.apache.org/commons/SCXML/HomePage
>
>
>
> >
> > Joel
> >
> >
> > On Thu, Jan 8, 2009 at 10:41 AM, Rahul Akolkar <ra...@gmail.com>
> wrote:
> >> On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
> >> <Ch...@itt.com> wrote:
> >>> Thanks for your response.
> >>>
> >>> I'm not familiar with using a JSP (assume are we talking Java Server
> >>> Pages?) in the context of my application. Mine is a stand-alone Java
> >>> GUI application using Swing with the state machine to respond to user
> >>> actions and other system actions. Is there a way to use a dynamic
> >>> resource without using JSP? If so, what would an example look like?
> >>>
> >> <snip/>
> >>
> >> It doesn't have to be a JSP, it was used for illustration. All we're
> >> saying is use a dynamic URL to tweak the IDs as needed. If everything
> >> has to be local (no servlet container, web server or any type of
> >> remote service access), then it may not be straightforward to create
> >> such a dynamic URL (custom protocol handlers for the java.net.URL
> >> architecture or other fancy footwork perhaps).
> >>
> >> -Rahul
> >>
> >>
> >>> Thanks a bunch,
> >>> Cheryl
> >>>
> <snap/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: SCXML Templating
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Jan 8, 2009 at 2:04 PM, Joel Truher <jo...@truher.org> wrote:
> I'm curious about this topic, Rahul, since I encountered it as well.
>
> The solution you suggest seems to me to be external to SCXML, and it
> made me wonder if this sort of templating ought to be supported more
> natively, or if there's a design argument to exclude it?
>
> I searched for a way to avoid templating, since it does seem foreign
> to the state-chart idea (as well as other implementations of it, e.g.
> Boost.Statechart). I eventually succeeded, and I think my design is
> better for it. So maybe the exclusion of templates is a good design
> choice. Is that how you see it?
>
<snip/>
It has been a conscious design choice so far to say that ensuring the
uniqueness of IDs is the responsibility of the document author in all
cases. Some solutions were considered IIRC to automatically introduce
some sort of scoping or ID-munging to get around this issue of src'ing
in the same document multiple times, but none were found to be
satisfactory. Given that SCXML will very likely be used to design
systems that are distributed, reactive and heterogeneous it was
considered that its not a stretch to say use a dynamic URL here. The
advantage of the example approach outlined here is that it gives the
author complete control over how the IDs will be treated every time,
and these are therefore predictable at design-time.
I'm not sure if you are saying you avoid templating or use some other
authoring pattern (if you'd like to share with all users, you can
create a wiki page if you want). The wiki is here [1] and open to all
(after a quick registration).
-Rahul
[1] http://wiki.apache.org/commons/SCXML/HomePage
>
> Joel
>
>
> On Thu, Jan 8, 2009 at 10:41 AM, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
>> <Ch...@itt.com> wrote:
>>> Thanks for your response.
>>>
>>> I'm not familiar with using a JSP (assume are we talking Java Server
>>> Pages?) in the context of my application. Mine is a stand-alone Java
>>> GUI application using Swing with the state machine to respond to user
>>> actions and other system actions. Is there a way to use a dynamic
>>> resource without using JSP? If so, what would an example look like?
>>>
>> <snip/>
>>
>> It doesn't have to be a JSP, it was used for illustration. All we're
>> saying is use a dynamic URL to tweak the IDs as needed. If everything
>> has to be local (no servlet container, web server or any type of
>> remote service access), then it may not be straightforward to create
>> such a dynamic URL (custom protocol handlers for the java.net.URL
>> architecture or other fancy footwork perhaps).
>>
>> -Rahul
>>
>>
>>> Thanks a bunch,
>>> Cheryl
>>>
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Joel Truher <jo...@truher.org>.
I'm curious about this topic, Rahul, since I encountered it as well.
The solution you suggest seems to me to be external to SCXML, and it
made me wonder if this sort of templating ought to be supported more
natively, or if there's a design argument to exclude it?
I searched for a way to avoid templating, since it does seem foreign
to the state-chart idea (as well as other implementations of it, e.g.
Boost.Statechart). I eventually succeeded, and I think my design is
better for it. So maybe the exclusion of templates is a good design
choice. Is that how you see it?
Joel
On Thu, Jan 8, 2009 at 10:41 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
> <Ch...@itt.com> wrote:
>> Thanks for your response.
>>
>> I'm not familiar with using a JSP (assume are we talking Java Server
>> Pages?) in the context of my application. Mine is a stand-alone Java
>> GUI application using Swing with the state machine to respond to user
>> actions and other system actions. Is there a way to use a dynamic
>> resource without using JSP? If so, what would an example look like?
>>
> <snip/>
>
> It doesn't have to be a JSP, it was used for illustration. All we're
> saying is use a dynamic URL to tweak the IDs as needed. If everything
> has to be local (no servlet container, web server or any type of
> remote service access), then it may not be straightforward to create
> such a dynamic URL (custom protocol handlers for the java.net.URL
> architecture or other fancy footwork perhaps).
>
> -Rahul
>
>
>> Thanks a bunch,
>> Cheryl
>>
>> -----Original Message-----
>> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
>> Sent: Wednesday, January 07, 2009 10:38 PM
>> To: Commons Users List
>> Subject: Re: SCXML Templating
>>
>> On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
>> <Ch...@itt.com> 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
>>
>> This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
>> Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Jan 8, 2009 at 8:37 AM, Lee, Cheryl - ES/RDR -Gil
<Ch...@itt.com> wrote:
> Thanks for your response.
>
> I'm not familiar with using a JSP (assume are we talking Java Server
> Pages?) in the context of my application. Mine is a stand-alone Java
> GUI application using Swing with the state machine to respond to user
> actions and other system actions. Is there a way to use a dynamic
> resource without using JSP? If so, what would an example look like?
>
<snip/>
It doesn't have to be a JSP, it was used for illustration. All we're
saying is use a dynamic URL to tweak the IDs as needed. If everything
has to be local (no servlet container, web server or any type of
remote service access), then it may not be straightforward to create
such a dynamic URL (custom protocol handlers for the java.net.URL
architecture or other fancy footwork perhaps).
-Rahul
> Thanks a bunch,
> Cheryl
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Wednesday, January 07, 2009 10:38 PM
> To: Commons Users List
> Subject: Re: SCXML Templating
>
> On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
> <Ch...@itt.com> 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
>
> This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
> Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: SCXML Templating
Posted by "Lee, Cheryl - ES/RDR -Gil" <Ch...@itt.com>.
Thanks for your response.
I'm not familiar with using a JSP (assume are we talking Java Server
Pages?) in the context of my application. Mine is a stand-alone Java
GUI application using Swing with the state machine to respond to user
actions and other system actions. Is there a way to use a dynamic
resource without using JSP? If so, what would an example look like?
Thanks a bunch,
Cheryl
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, January 07, 2009 10:38 PM
To: Commons Users List
Subject: Re: SCXML Templating
On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
<Ch...@itt.com> 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Templating
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, Jan 7, 2009 at 4:45 PM, Lee, Cheryl - ES/RDR -Gil
<Ch...@itt.com> 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org