Context

[dandcg]

Hi Prasanna,

I have been using the stateless library however it didn't quite fill my needs, so I extended it to be initialized like so:

var machine = new StateMachine<State, Trigger, Context>

the reason behind this being that is I can have a WF factory that returns a machine with it own instance of a context that can be utilized through all the state events (OnEntry, OnExit etc).

As stateless doesn't support async await I am looking at your library and will probably implement something similar based on this.

The reason for my issue (no issue really) is to see if you have a view on this approach?

Cheers,

Dan

[prasannavl]

Hello Dan,

I thought about adding a context internally, but it seemed to be an un-necessary complication for a general purpose machine since it can be achieved with a little bit extra code.

There are a few straight-forward ways of achieving this, since all these methods simply take lambdas. If the overhead isn't an issue, simply passing it through another layer of abstraction would be the simplest or if you can separate the entire configuration directly into the context class, and simply use them as though they were regular closure variables.

But the approach heavily depends on how you really want to use this context. If you could give a small piece of code explaining how you're exactly using the context, perhaps I can help you better.
For example, it could be a static machine level context, or perhaps a dynamic context along that you pass along with the triggers. In short, I'd need a better understanding of the context of your context.

[dandcg]

Hi Prasanna,

Thanks for the reply. Sorry for the delay in getting back to you. The reason for the context type within the creation of a new machine is to keep the machine configuration and implementation of OnEntry/Exit separate from the 'working memory' of the statemachine. This is because services used in the OnEntry/Exit implementations are injected in. The WF factory service gives an instance of the workflow with its own specific context memory included. I can then pull out multiple instances of the WF from the factory and manage them independently.

It felt like hard work having to pass the context into every trigger when it is used in everyOnEntry/Exit implementation.

Hope I'm making sense - I will try and get some code together for you if not. Just wanted to see I was completely missing something.

Dan

[prasannavl]

Let me see if I correctly understood the problem you're trying to solve first. Is passing a context with every trigger (i.e, a Fire* call) what you're trying to do?

[dandcg]

Yep - that is pretty much correct - so the context is separate from the machine setup and implementation.

[prasannavl]

Sorry, didn't get the time to write a detailed reply. But this is how I would do it - Using an abstraction over the state-machine which converts all of the contexts into trigger with parameters, and passes the context as parameter.