Improve Expression Language handling in the step extension config page

[lhein]

Please describe the feature that you want to propose

Currently there are 3 possible expression languages shown in parallel with separate input fields in the config panel.

What happens if a user defines all 3 of them? I think this is confusing and we should move to use a drop down for the available and supported expression languages and just a single text field.

[lhein]

This is not just affecting the Set-Header but a couple other EIPs too which support expression languages.

[igarashitm]

For me it loads the step extension properly

[kahboom]

@lhein please provide the YAML, it would be more helpful. we can then see if it's a bug.

[lhein]

Interesting...I cannot reproduce that any more. Was there a new build deployed on OperateFirst that fixed the issue?

[lhein]

It seems that was not the only difference...look at the Name label and the Expression Syntax label.

[lhein]

so maybe this was the fallback generic step extension which was displayed?

[lhein]

In the current state we do not mark mandatory fields correctly in the UI. We also lack the configuration fields for "description" and "disabled". Why can't we use the generic step extension and make that one clever enough to provide the expression drop down rather than providing an extra step extension for this?

[kahboom]

@lhein :

In the current state we do not mark mandatory fields correctly in the UI. We also lack the configuration fields for "description" and "disabled". Why can't we use the generic step extension and make that one clever enough to provide the expression drop down rather than providing an extra step extension for this?

I know it's related, but I think it would be good to create a separate issue for this, so that feedback doesn't get lost, or rename it & update the description.

But, to answer your question, we could auto-generate forms based on the parameters for each step (as we do for the default step detail view) from the step extension, or we can manually add those fields (not sure why they are not on that step extension actually) to the step extension.

The tradeoff with auto-generating the forms is that it adds complexity to each step extension that would then need to be overridden with custom logic. Not a problem, just something to consider. cc @igarashitm @lordrip

[lhein]

Why does that add complexity in this case? If we use the auto generated form here this will reduce the code as this specific extension gets obsolete. Not sure I understand the problem.

[kahboom]

@lhein - It's the difference between:

• Add a new library (uniforms-patternfly) to autogenerate the fields, create the schema and model from the API response, create the component with the form fields, create the bridge and auto-form component, override the bridge if there is anything custom like icons or disabled fields.

vs

• Create the component with the form fields

And that doesn't include any heavy modifications to the auto-form stuff or in-depth validation. Autogenerating stuff is great if there is a lot of repetition and consistency, or if the component fields will change a lot; it gets messy the more you need to override stuff (see Syndesis).

In most cases it feels like overkill since the step extensions are not always forms that map directly to the JSON (for example choice and http-source), and the ones that do are just a few fields that don't change all that often, like this one.

On the other hand, the benefit is that we could reuse that logic between step extensions. I'm not against it, I think we should do it if we find many extensions that would be too much work to do by hand or if there is a lot of repetition. That's still a question to me.