commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ant Kutschera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SCXML-156) Need a better way of setting initial state in instances of SCXMLExecutor
Date Fri, 27 Aug 2010 18:42:55 GMT

    [ https://issues.apache.org/jira/browse/SCXML-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903522#action_12903522
] 

Ant Kutschera commented on SCXML-156:
-------------------------------------

OK, cool, and makes sense, although the Javadoc isn't too intuitive.  

Maybe for the future you could consider making an explicit method for setting the current
state, which encapsulates this?  And the Javadoc could clearly state what the method is for.

Anyway, I know its not part of this issue, but is there a way to get SCXML to throw an exception
if you trigger an illegal transition?

> Need a better way of setting initial state in instances of SCXMLExecutor
> ------------------------------------------------------------------------
>
>                 Key: SCXML-156
>                 URL: https://issues.apache.org/jira/browse/SCXML-156
>             Project: Commons SCXML
>          Issue Type: Improvement
>    Affects Versions: 0.9
>         Environment: local j2se
>            Reporter: Ant Kutschera
>            Priority: Minor
>
> Example:
> I have states RESERVED->BOOKED->PAID.  The initial state is RESERVED.  I create
a business entity which has this state and I need to persist it in state BOOKED.
> I persist the state as a varchar / String.  I don't want to persist a state machine in
my database.
> When I load the entity in order to update the state to "PAID", I need to instantiate
the state machine, and update the state to "BOOKED", since that is the status my object really
has.
> I can do this, only by modifying the InitialTarget of the SCXML using the API.  That
isn't nice, because I only want one instance of SCXML, because loading the XML is expensive
in terms of time/cpu etc.  The solution I've used now is to do the update in a synchronized
block, while being synchronized on the SCXML instance, and then after I instantiate the SCXMLExecutor,
I put the state back in the SCXML to the original initial state.
> Ideally, I would be able to pass the "starting state" to the constructor of the SCXMLExecutor,
to indicate that I am starting from a partially run workflow, if that makes sense.
> See this blog article too: http://blog.maxant.co.uk/pebble/2010/08/26/1282857660000.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message