NAME
State Chart XML Classes -
Classes
class ScXML
Namespace for static ScXML-related functions.
class ScXMLEvent
Base class for events sent to SCXML state machines.
class ScXMLInvoke
Implementation of the <invoke> SCXML element.
class ScXMLObject
Base class for all SCXML objects.
class ScXMLStateMachine
Manager for processing events and setting states in SCXML
structures.
class SoScXMLEvent
Adds an SoEvent holder to the ScXMLEvent base.
class SoScXMLStateMachine
Integration level for using Coin events with SCXML-based state
machines.
Detailed Description
This set of classes is a basic implementation of State Chart XML. It is
not complete, nor is it necessary conformant to those parts it
implements. It is however a decent start, and there are plans for
implementing more parts of the specification.
Currently Coin uses SCXML for managing 3D viewer user interaction (the
non-model-interaction part) - the examiner navigation mode in layman
terms - but with a more complete implementation of SCXML, the potential
for more uses should be quite huge.
The Draft Specification for SCXML is at http://www.w3.org/TR/scxml/.
Since:
Coin 3.0
State Chart XML The ScXML part of Coin is a basic, non-conformant,
partial implementation of State Chart XML, based on the W3C Working
Draft 21 February 2007 of SCXML <http://www.w3.org/TR/2007/WD-
scxml-20070221/>. Read that document for a basic understanding how
SCXML documents should be constructed.
NOTE: A new version of the draft has just been released (May 2008). The
code here does not reflect any changes done to the draft SCXML
specification yet.
Coin uses it for its navigation system, to be able to remove hardcoded
logic for user navigation and externalize it into XML files. It is
hoped that this technology will prove to be a useful addition to Coin
and get broader use as this subsystem matures. The dragger and
manipulator user interaction logic is likely one area where ScXML might
be employed later. Attaching state machines to interactive parts of the
scene graph could be another interesting idea for the future.
For now, the ScXML system is not employed in any pre-established Coin
usage patterns, and you will need to employ new features to touch base
with it. The most obvious are where ScXML will be used is if you use
Quarter 1.0 over Coin 3.0, as you manipulate the camera movements
around the 3D models through mouse and keyboard interaction.
The Coin type system makes it possible to override the default types to
have the state chart description instantiated using customized objects.
A design choice made in that regard was to both use the type overriding
system in Coin, and also to use the ’xmlns’ (XML Namespace) attribute
to make ScXML types available and to prioritize which classtypes to
instantiate objects from. The xmlns attribute is currently only checked
at the document level, but the plan is to let any state have this
attribute, and to simulate static scoping rules for namespace
prioritization.
Partially Supported Items:
· At the moment, the Coin ScXML module only supports ’Executable
Content’ through the <invoke> element, using the ScXMLInvoke
class interface and having the Executable Content written in C++ in
subclasses of the ScXMLInvoke class. ECMAScript and XPath is not
supported yet.
Unsupported Items:
· External document referencing through the <state> / <parallel> ’src’
attribute is not yet handled, but should be easy to implement so it
will likely be one of the first things that will be fixed.
· The <parallel> element is not supported as intended with parallel
states. Coin will just treat it as an ordinary <state> element for
now. Parallel states is not high up on the priority list, so expect
this to be handled after a lot of other functionality is in place.
· The <datamodel>-related part of the specification is not supported.
· The condition attribute in the <transition> element is not supported,
so the only condition you can set is on the event type in the event
attribute. The ScXMLTransition class has a virtual method SbBool
evaluateCondition() which is used in the state machine logic, and
should be all that is needed to overload to implement this in
subclasses yourself.
· The ’target’ attribute in the <transition> element can only identify
a single state currently, not multiple as you would have to when
having support for <parallel> elements (which we don’t have).
· The virtual state elements like <history> and <anchor> are just
implemented as dummy states for now and do not do anything in
relation to what they should actually do.
· There are no mechanisms for inter-statemachine event passing yet.
For learning more about how ScXML is implemented and used in Coin, take
a look at $COINDIR/scxml/navigation/examiner.xml (or in the Coin source
directory, data/scxml/navigation/examiner.xml) for an example of how an
SCXML system for camera navigation looks, and look at the ScXML* source
files in src/navigation/ for the C++ counterparts to the same SCXML
navigation system.
With support for <datamodel>, <transition>-conditions, and inline
executable content in the XML file in some scripting language, the C++
parts could probably have been greatly simplified, if not more or less
eliminated. This will hopefully evolve for future versions of Coin.
Since:
Coin 3.0
Author
Generated automatically by Doxygen for Coin from the source code.