[scxml] templates, url and parameters

[Fabrizio Morbini <fm...@gmail.com>]

Hi, concerning the wiki page:
http://wiki.apache.org/commons/SCXML/Tutorials/Templating

There the src attribute is given the value:
"accept-connection.scxml?call-id=incoming-line".

How is the parameter call-id used/accessed?
Would the same be possible also with xinclude?

thanks,
fabrizio.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org

Re: [scxml] templates, url and parameters

[Rahul Akolkar <ra...@gmail.com>]

On Mon, Jun 21, 2010 at 2:50 PM, Fabrizio Morbini <fm...@gmail.com> wrote:
> Hi, concerning the wiki page:
> http://wiki.apache.org/commons/SCXML/Tutorials/Templating
>
> There the src attribute is given the value:
> "accept-connection.scxml?call-id=incoming-line".
>
> How is the parameter call-id used/accessed?
<snip/>

The point that needs to be made better perhaps on that page is that
the URI needn't point to a static resource. So what is src'ed in could
be any dynamic server-side resource that generated an SCXML document
or fragment in some parameterized fashion where the number and
semantics of the parameters are application specific.

In the context of templating, one could imagine such a parameterized
script, where the dynamic portions are limited to appending unique
prefixes to ids and idrefs such that the same document or fragment may
be src'ed in multiple times (since each src'ed in URI would create
unique ids for the including state machine's scope -- along the lines
of "foo.scxml.jsp?suffix=1" and "foo.scxml.jsp?suffix=2").


> Would the same be possible also with xinclude?
>
<snap/>

Using XInclude to similarly point to dynamic resources is possible
(and even fragments, using an appropriate XPointer, may be possible if
the parser has the necessary support).

The said dynamic resource/script is part of the application (and needs
to be authored and deployed).

-Rahul


> thanks,
> fabrizio.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org