Clojurians Log v2

for context; this is the code i was running in my exploration. so without the patch I'm not getting back the done-data in the parent-chart.

yeah, invoke is a bit under-tested/utilized at the moment. In my spare time (hah) I’ve been trying to make that a little better. Don’t remember if I have any unreleased patches, but I seem to remember running into the same thing

I think I was also surprised that the SCXML spec doesn’t return done-data in all of the cases I would expect.

I did some work on invoke in v 1.2.16…you running that?

yes i am/was on latest

In the spec under 5.5, i see: In cases where the SCXML Processor generates a 'done' event upon entry into the final state, it _MUST_ evaluate the <donedata> elements <param> or <content> children and place the resulting data in the _event.data field. My patch is for the send-done-event! function, which wasn't doing anything like that before, that's why I thought it might be a gap in the lib. But I've only really looked at the spec for details like this, didnt read it all nor do I feel like I fully comprehend statecharts in general yet; so its hard for me to judge in light of the full picture.

This behaviour does make sense for me personally though, for what's it worth 🙂

When you say "invoke is a bit under-tested/utilized at the moment", you must mean you're not using it a lot yourself either, right? Asking because one of the reasons for me to explore this, is that some of our statecharts are starting to get a bit big/hard to follow and Im looking for ways to better structure them. Breaking them apart into separate statecharts that can invoke one another seemed like a reasonable direction to explore, but you saying you're not using it much makes me wonder if it might not be the best way forward. An obivous alternative strategy would of course be to break-out recurring or logically stand-alone pieces into simple def's for those states, but still compose them into a single statechart. That's kind of what we've been doing, but as said, is still getting out of hand in certain places; although that doesnt have to mean there's anything wrong with that basic strategy and might just mean that we need to improve in how we break them up and define the dependencies/communication etc. Any insight appreaciated.

Oh I plan to use them heavily, I’ve just been swamped with my main business. If you look at recent additions to the library I’m working on a routing system for Fulcro that leverages them extensively so you can co-locate statecharts with UI components.

let me read over your patch, it sounds like you’re right

"patch" is a bit of a big word in this case, there was barely anything extra needed to get it to work, but sure have a look if it makes sense in relation to the rest of the implementation, couldnt realy judge that; but from the spec, function-name and what I understand of the flow this made sense to me

Released in 1.2.7