Skip to content

Conversation

@mcruzdev
Copy link
Contributor

@mcruzdev mcruzdev commented Nov 4, 2025

Many thanks for submitting your Pull Request ❤️!

What this PR does / why we need it:

Special notes for reviewers:

Additional information (if needed):

Copy link
Collaborator

@fjtirado fjtirado left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a draft but I think is good I wrote a long general comment, since this PR requires some deep refactor.
The goal should be to not add Javascript or Python dependencies to the core.
With that spirit, you need a RunScriptTask in the core modules that selects either the JavaScript or the Python implementation (use the language id to select the right implementation, all implementation being loaded through service loading to not create dependencies)
Then you have another module with the java script specific code plus the javascript library (the java script implementation class being loaded thorugh service loader)
About this specific module, we need to split better between init (parsing) and apply (runtime). rather than having an Executor that does all the parsing at runtime at the end, you will need several "functor" classes that give you the source, the environmment and so on.
Finally, JavaScript should be executed on embedded mode, not running an external process.
I will try to comment on specific cases.

Comment on lines 121 to 128
String value =
ExpressionUtils.isExpr(entry.getValue())
? WorkflowUtils.buildStringResolver(
application,
entry.getValue().toString(),
taskContext.input().asJavaObject())
.apply(workflowContext, taskContext, taskContext.input())
: entry.getValue().toString();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an example of functor I mention in the general comment.
The idea is that you generate a Map<String,WorkflowValueResolver during init, by using Workfloutils.buildStringFilter (WorkflowApplication appl, String expression), and at runtime you actually invoke the apply (passing the Workflowcontext, TaskContext and WorkflowModel passed to apply method)

Copy link
Collaborator

@fjtirado fjtirado left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a couple of comments trying to illustrate my previous comment.

@mcruzdev
Copy link
Contributor Author

mcruzdev commented Nov 4, 2025

Added a couple of comments trying to illustrate my previous comment.

Great comment, I was inclined to create a separate module, especially since the dependency is quite large and really specific. Thanks, I will change it in the next commits.

Signed-off-by: Matheus Cruz <matheuscruz.dev@gmail.com>
Signed-off-by: Matheus Cruz <matheuscruz.dev@gmail.com>
@mcruzdev mcruzdev marked this pull request as ready for review November 8, 2025 16:19
fjtirado and others added 2 commits November 11, 2025 15:07
Signed-off-by: fjtirado <ftirados@redhat.com>
@fjtirado fjtirado self-requested a review November 11, 2025 16:48
fjtirado and others added 3 commits November 11, 2025 18:00
Signed-off-by: fjtirado <ftirados@redhat.com>
Signed-off-by: fjtirado <ftirados@redhat.com>
@fjtirado fjtirado merged commit c33f8ef into serverlessworkflow:main Nov 11, 2025
3 checks passed
@fjtirado fjtirado mentioned this pull request Nov 12, 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