Reference previous activity data

As a user I like to be able to reference (use) data from the previous activities in my current activity.

• Display an activity tree with previous activities in the activity options. Based on the display activity result data task
• Allow the user to browse through the activity tree and copy a path {{ activity:Webhook.output.label }}
• Parse the activity options for inserted paths and replace the path expression with the result on runtime

[sfmskywalker]

I’m currently thinking along the lines of the following:

The idea is that a given property’s type has a default control that makes sense (and is configurable from C#). For example, when a property allows the user to select one value from a set of options, we’d render a dropdown list with these options.

But when the user wants to use an expression, they can do so by switching from ‘Dropdown’ to e.g. ‘JavaScript’, which will replace the dropdown control with a code editor.

The Literal syntax would provide a plain text view of the literal value that would be stored by the default control.

This would work for any type of control, where the user can always switch to advanced mode and select a different mode of input.

This might even work for selecting an activity’s output or a workflow variable. In fact, this list could potentially be extensible by application code itself (which would require adding StencilJS components).

[craigfowler]

@jdevillard the reason I wouldn’t suggest adding to the base class is that it adds complexity to the overall architecture, which I really believe we should be keeping as simple as we can. It’s also my general opinion that “adding extra functionality to the base class” is a sort of development trap. It looks very appealing because one change will automatically add functionality everywhere, but it’s a path that leads to bloated base classes with tightly-coupled functionality.

It’s almost always better to split that new functionality out into either a different service, with a new interface or a decorator class which allows for decoupling between the original impl and that extra functionality. That said - the more I think about a template composable activity, I don’t really like that idea so much either. It seems it would require quite a lot of change for no real reason right now.

Another think about it

Everything else aside, I’d like to go back and look at the original requirement for this:

As a user I like to be able to reference (use) data from the previous activities in my current activity.

• Elsa already has a way to store data from activity execution in variables
• Elsa already has a way to reference/use variable values in activities
• Elsa already permits composite activities, to de-clutter the workflow design whilst enabling complex/multi-step activities

At least in the core (let’s ignore the UI for a second), we’re already ticking all of the right boxes without changing anything at all. In the UI, this is also already possible right now, but it’s a bit annoying because of the manual/multi-step process:

• Create a composite activity and put it into your workflow
• Add your data-getting/data-generating activity into that composite activity
• Add a set-variable activity into that composite activity and choose a variable name
• In the activity which needs the variable value, enter an expression using that variable name

Well, we could certainly make all of that a lot easier by only changing the UI. How about a ‘wizard’ (but let’s not call it that 😆) of sorts which can do the first three of those steps with just one logical action. You choose your data-getting/generating activity type and a variable name, and the UI creates all of that stuff for you in one shot. For the last step, perhaps offer autocomplete (or similar) functionality for names of variables that have been used in the workflow already?