You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When an element template is applied only explicitly defined properties in the element template are rendered. This means that when I select an element template I lose the ability to add execution listeners.
Business Case:
I have a custom delegate defined and I want to provide an element template for that delegate so that the model designer does not need to know implementation details such as Java Class path, input/output names, etc. However, there are cases where inputs/output variables may need to be pre/post processed (or other actions taken) in an execution listener and I lose the ability for a user to add execution listeners when the template is applied.
Describe the solution you'd like
On the element template definition allow for a variable at the root called allowUserDefinedExecutionListeners that is a boolean that will show/hide the section for execution listeners and will allow/disallow the ability to add new ones.
It will enable this section in the properties panel (as seen on a basic service task)
Describe alternatives you've considered
Not using element templates
Not good UX because a user needs to know technical details of the implementation.
Apply the element template, defined the values, then unlink the element template to allow adding execution listeners.
Will allow for applying execution listeners, but loses the ability update to a newer version of an element template.
The text was updated successfully, but these errors were encountered:
@codygulley Essentially, as part of element templates, you'd like to control which additional (stock) editing sections are being shown? This is a feature we had in the old 0.x properties panel.
Focussed on execution listeners only it would be more controlled (less risk) to implement.
@nikku That is correct. I am mainly interested in execution listeners.
IMHO I can't think of a use case where I would need to supply other "stock" sections outside the template (i.e. input, outputs, etc) as those would have a strong contract with the delegate/connector.
Allow it to (optionally) be an object of 'component -> boolean' mappings, or a list of components that may be visible. The only allowed option shall be executionListeners.
Alternatively we could go a little leaner approach and simply allow that property to be an object entry names as keys.
Is your feature request related to a problem? Please describe.
When an element template is applied only explicitly defined properties in the element template are rendered. This means that when I select an element template I lose the ability to add execution listeners.
Business Case:
I have a custom delegate defined and I want to provide an element template for that delegate so that the model designer does not need to know implementation details such as Java Class path, input/output names, etc. However, there are cases where inputs/output variables may need to be pre/post processed (or other actions taken) in an execution listener and I lose the ability for a user to add execution listeners when the template is applied.
Describe the solution you'd like
On the element template definition allow for a variable at the root called
allowUserDefinedExecutionListeners
that is a boolean that will show/hide the section for execution listeners and will allow/disallow the ability to add new ones.It will enable this section in the properties panel (as seen on a basic service task)
Describe alternatives you've considered
Not good UX because a user needs to know technical details of the implementation.
Will allow for applying execution listeners, but loses the ability update to a newer version of an element template.
The text was updated successfully, but these errors were encountered: