commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SCXML-200) Normalize and complete the SCXML object model and parsing
Date Sat, 22 Mar 2014 23:25:42 GMT

     [ https://issues.apache.org/jira/browse/SCXML-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ate Douma updated SCXML-200:
----------------------------

    Description: 
The current SCXML object model is still rather 'flat' and de-normalized, and many of the current
SCXML specification features as well as restrictions are not fully mapped.

I'll restructure the current model to bring it more/mostly in line with the specification
and normalize the object hierarchy to clearer separate and restrict the features belonging
to the right level and element.

The current state and transition model hierarchy is like this:
{code}
TransitionTarget 
  <- Initial
  <- History
  <- State
       <- Final
  <- Parallel

Executable
  <- Transition
{code}
  
After my restructuring it looks like this:
{code}
Initial

TransitionTarget
  <- History
  <- EnterableState -> DocumentOrder
       <- TransitionalState
            <- State
            <- Parallel
       <- Final  

Executable
  <- SimpleTransition
       <- Transition -> DocumentOrder
{code}
  
With the above restructuring, each of these model objects now cleanly represents their functional
role in the SCXML specification and only contains the features and relations they are supposed
to have.

I will also update the SCXML document parsing of the model and the validation and post-processing,
and introduce some handy optimizations like adding a document order indicator to the EnterableState
and Transition object which makes sorting them in document or reverse-document order, as needed
for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget
its ancestor tree will be derived once and cached as a fast navigable array.

All these changes have a big impact on the *internal* API because not everything is passed
around as a TransitionTarget anymore but as strongly typed as possible. But these changes
makes it much clearer to understand and use, and are an important improvement needed for implementing
the full SCXML specification.


  was:
The current SCXML object model is still rather 'flat' and de-normalized, and many of the current
SCXML specification features as well as restrictions are not fully mapped.

I'll restructure the current model to bring it more/mostly in line with the specification
and normalize the object hierarchy to clearer separate and restrict the features belonging
to the right level and element.

The current state and transition model hierarchy is like this:
{code}
TransitionTarget 
  <- Initial
  <- History
  <- State
       <- Final
  <- Parallel

Executable
  <- Transition
{code}
  
After my restructuring it looks like this:
{code}
TransitionTarget
  <- History
  <- EnterableState -> DocumentOrder
       <- TransitionalState
            <- State
            <- Parallel
       <- Final  

Executable
  <- SimpleTransition
       <- Transition -> DocumentOrder
{code}
  
With the above restructuring, each of these model objects now cleanly represents their functional
role in the SCXML specification and only contains the features and relations they are supposed
to have.

I will also update the SCXML document parsing of the model and the validation and post-processing,
and introduce some handy optimizations like adding a document order indicator to the EnterableState
and Transition object which makes sorting them in document or reverse-document order, as needed
for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget
its ancestor tree will be derived once and cached as a fast navigable array.

All these changes have a big impact on the *internal* API because not everything is passed
around as a TransitionTarget anymore but as strongly typed as possible. But these changes
makes it much clearer to understand and use, and are an important improvement needed for implementing
the full SCXML specification.



> Normalize and complete the SCXML object model and parsing
> ---------------------------------------------------------
>
>                 Key: SCXML-200
>                 URL: https://issues.apache.org/jira/browse/SCXML-200
>             Project: Commons SCXML
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0
>
>
> The current SCXML object model is still rather 'flat' and de-normalized, and many of
the current SCXML specification features as well as restrictions are not fully mapped.
> I'll restructure the current model to bring it more/mostly in line with the specification
and normalize the object hierarchy to clearer separate and restrict the features belonging
to the right level and element.
> The current state and transition model hierarchy is like this:
> {code}
> TransitionTarget 
>   <- Initial
>   <- History
>   <- State
>        <- Final
>   <- Parallel
> Executable
>   <- Transition
> {code}
>   
> After my restructuring it looks like this:
> {code}
> Initial
> TransitionTarget
>   <- History
>   <- EnterableState -> DocumentOrder
>        <- TransitionalState
>             <- State
>             <- Parallel
>        <- Final  
> Executable
>   <- SimpleTransition
>        <- Transition -> DocumentOrder
> {code}
>   
> With the above restructuring, each of these model objects now cleanly represents their
functional role in the SCXML specification and only contains the features and relations they
are supposed to have.
> I will also update the SCXML document parsing of the model and the validation and post-processing,
and introduce some handy optimizations like adding a document order indicator to the EnterableState
and Transition object which makes sorting them in document or reverse-document order, as needed
for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget
its ancestor tree will be derived once and cached as a fast navigable array.
> All these changes have a big impact on the *internal* API because not everything is passed
around as a TransitionTarget anymore but as strongly typed as possible. But these changes
makes it much clearer to understand and use, and are an important improvement needed for implementing
the full SCXML specification.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message