Repository navigation
Conversation
| </bpmn2:serviceTask> | ||
| ``` | ||
|
|
||
| For inline scripts in an input parameter, template engines other than JUEL are subject to |
There was a problem hiding this comment.
| For inline scripts in an input parameter, template engines other than JUEL are subject to | |
| For inline scripts template engines other than JUEL are subject to |
This will be true for all usages of inline scripts
| dynamic script-source detection: if the script content starts with `${` or `#{` after | ||
| leading and trailing whitespace is trimmed, Operaton treats it as an expression that resolves | ||
| to a script source. | ||
| If those characters are part of the template itself, prefix the content with a comment |
There was a problem hiding this comment.
Add empty line to separate the paragraph
kthoms
left a comment
kthoms
left a comment
There was a problem hiding this comment.
Thanks, this addresses #168 well. The detection rule (trimmed, starts with ${ or #{, non-JUEL languages only) matches StringUtil.isExpression / ScriptUtil.isDynamicScriptExpression, the external-resource alternative is accurate (only the resource attribute value is checked, not the loaded file), the XML escaping is correct, and all MDX-sensitive characters are inside code. One wording issue that should be fixed, plus a few optional suggestions inline.
Possible follow-up (out of scope here): add a matching note to the "Script Source" section of scripting.md, which is the canonical place for the dynamic-source rule.
| </bpmn2:serviceTask> | ||
| ``` | ||
|
|
||
| For inline scripts in an input parameter, template engines other than JUEL are subject to |
There was a problem hiding this comment.
Should fix: this understates the scope. ScriptUtil.getScriptFormSource applies the check to every inline script source, not just input parameters: script tasks, execution/task listeners, conditions, and input and output parameters all go through it. A FreeMarker <scriptTask> whose body starts with ${ fails the same way.
Suggestion:
| For inline scripts in an input parameter, template engines other than JUEL are subject to | |
| For inline script sources (script tasks, listeners, conditions, and input/output parameters), template engines other than JUEL are subject to |
Consider also linking the existing [script-source] reference so readers see the documented feature behind this behavior.
| For inline scripts in an input parameter, template engines other than JUEL are subject to | ||
| dynamic script-source detection: if the script content starts with `${` or `#{` after | ||
| leading and trailing whitespace is trimmed, Operaton treats it as an expression that resolves | ||
| to a script source. | ||
| If those characters are part of the template itself, prefix the content with a comment | ||
| recognized by the template engine, or use an external resource instead. For example, an | ||
| inline FreeMarker template can start with an escaped FreeMarker comment: |
There was a problem hiding this comment.
Optional:
- Mention the symptom, e.g. that the template is never passed to the template engine and the content is evaluated as an expression instead, which usually fails or produces unexpected output. Users tend to search by symptom.
- Since this is a pitfall, a
:::caution(or:::note, as used elsewhere on this page) admonition would make it stand out. - Strictly, the check applies to any non-JUEL language (Groovy, JavaScript, ...), not only template engines. Fine on a templating page, but "script or template languages other than JUEL" would be more precise.
| ```xml | ||
| <operaton:inputParameter name="message"> | ||
| <operaton:script scriptFormat="freemarker"> | ||
| <#-- Keep this as an inline FreeMarker template. -->${name} likes: |
There was a problem hiding this comment.
Optional: only the detection check trims the source; the template itself is not trimmed. The rendered output will therefore start with a newline and keep the indentation on each line. Placing the comment directly after <operaton:script ...> (as in the issue) avoids the leading newline, or a short note could mention it.
Inline script content starting with
${or#{can be interpreted as a dynamic script-source expression before the selected script or template engine evaluates it. Document the rule for script tasks, listeners, conditions, and input/output parameters, link the existing script-source reference, and show the escaped FreeMarker comment workaround alongside the external-resource alternative.The caution explains the error symptom and starts the example comment immediately after the opening script tag, avoiding an extra leading output newline.
Fixes #168.
Validation:
npm run typecheck,npm run build, andgit diff --checkpassed. Docusaurus reported broken-link and anchor warnings elsewhere in the documentation. Tests were not run.