* Incremental work
* Enable control over when to include full compositie root
* Cleanup
* Update WorkflowDefinitionActivity
* Implement input as variables
* Delete unused class
* Remove less common types
* Rename ExpandoObject to JSON
* Implement variable scoping
* Remove parent/child relationship from MemoryRegister
* Add support for sending input to "trigger event" endpoint
* Add support for configuring input storage driver
* Remove unused namespace imports
* Auto-register activity types when running a workflow
* Fix missing variables from containers
The test coverage here actually proves that for Liquid expressions,
the issue has already been fixed as part of other work. Specifically
it was fixed in 2a22a328c4 in the
class StringExtensions.cs
This change means that a service provider may use both the Frozen
specimen builder and also the 'with autofixture resolution' behaviour.
That means that some unwanted extra logic in the test may now be
removed, with the test objects also coming from Autofixture.
This now also includes reworking the attribute which activates
Autofixture-style resolution upon an IServiceProvider.
This has now been renamed to WithAutofixtureResolutionAttribute.
The new/reworked attribute is composable with other Autofixture
attributes.
This removes all of the (now actually non-trivial) conversion logic from
the class which is actually responsible for executing the Jint engine.
This moves it all to a new service which uses chain of responsibility to
convert the result, using one of a few different mechanisms.
Of note is the handling of ExpandoObject when no specific type
information has been provided, and also the handling of enumerables,
with the exception of strings.
Unfortunately Jint still chokes in this case if the expando contains
further nested expandos. It turns out that I need to do this
recursively for it to always work.
We also have trouble with IEnumerable types. They also can't be
round-tripped from/to JSON when they aren't deserialized as a very
specific type.
It appears that this can be fixed by intercepting occasions
when Jint returns an ExpandoObject but the desired return type
is simply object. In this scenario we must return
a Dictionary<string,object> instead of a simple object, or else
Jint freaks out should we try to stringify it later.
I also added a second test to prove that making this change hasn't
broken the way we expect Jint to work for us.
This means that the model:
* Implements IConvertible so that Jint may implicitly convert
it to other types as if it were just a string.
* The Values & Values properties are perhaps a little less confusing
now, and present a more consistent set of state, regardless of
the inner model.
* There's a minor simplification to ToString, since String.Join already
did what we wanted for one or many values.
Notable though is - because this class implements IConvertible,
it is no longer CLS compliant. We do not currently mark this assembly
as CLS complient so as things stand that's OK. I do not know if there
are any plans/expectations for CLS compliance in Elsa.
If we do plan to mark the assemblies as compliant then we must mark this
class [CLSCompliant(false)].
This extension method is quite complex and is frustrating
when a unit test passes-through it. That's because extension
methods can't be mocked in tests.
The triggers-for-activity-blueprint functionality
is quite complex just on its own, so I have moved this to
a new service.
Once again the integration test which is left behind proves
that it still does the same job.
