Skip to content

Conversation

@vincentspaa
Copy link

Explicitly allows the use of typeof(SomeType).FullName
Adds support for converting a nested workflow-input accessor to a Conductor-friendly ${} string
Example:

_builder.AddTask(
            wf => wf.SomeTask,
            wf =>
                new()
                {
                    Command = AllFormatters.SomeStringFormatter(wf.Input.PrepareOutput.ImportantValue),
                    OutputType = typeof(SomeType).FullName!,
                }
);

(where AllFormatters is assumed to be a static property and SomeStringFormatter a method on said property)

… property

Explicitly allows the use of `typeof(SomeType).FullName`
Adds support for converting a nested workflow-input accessor to a Conductor-friendly `${}` string
@boma96
Copy link
Collaborator

boma96 commented Feb 28, 2025

@vincentspaa Thanks for contribution, can you submit at least one test case that demonstrates what is enabled by this code?

Fixes issue where some expressions in the tree are skipped
Makes the selection of workflow-accessor-to-string-conversion
more selective to prevent further method calls on top of it to work
@vincentspaa
Copy link
Author

@boma96 Very good point, sorry for skipping that. I've added a test case for the primary use-case covered by this PR, the static formatter.
I've had to adjust one test case because $"{wf.GetCustomer.Output.Address}".ToUpperInvariant() becomes legal with this PR. It doesn't work as a user might have intended, but I assumed that it's more important to prevent people from calling methods on workflow properties. So calling wf.GetCustomer.Output.Address.ConvertToSomethingElse() will still be illegal after this PR since it can't and shouldn't be evaluated. And I think there are way more cases where you might inadvertently call a method on an instance of the workflow, as opposed to $"{wf.GetCustomer.Output.Address}".ToUpperInvariant() which feels like a rare edge-case.

@boma96
Copy link
Collaborator

boma96 commented Apr 23, 2025

I have created a separate PR #204 which implements similar functionality described in this PR and also handles some edge cases we already discussed. Thanks for contribution.

@boma96 boma96 closed this Apr 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants