Multiple DSLs: How to handle switching

[kahboom]

As we are gearing up to support multiple DSLs from the UI, we should be considering how this will impact the user experience. For now, it looks like we will be allowing users to change the DSL from within a Settings modal, like this:

If the user is switching from one DSL that is not necessarily compatible with the existing one, then we should warn the user. We have a couple of options:

1. Only allow compatible DSLs to be listed in the dropdown, or disable the ones that are incompatible.
2. Show a warning to the user that the selected DSL is not compatible with the current DSL, so if they switch to it then they will lose their branches. On selecting it, then the branches would be cleared. Or the problematic steps removed.
3. Allow them to select whatever they want, maybe still showing the warning from option 2, and rather than removing the branches or steps we can show them in red or something, as "problematic".

Do we have certain steps that are not interoperable? Or is it just the branches that are a concern? @Delawen

I'm not a huge fan of the third option because it means that we leave the user in a state where now they have to clean up a bunch of stuff, but one could argue that it's a feature, because clearing everything that isn't compatible could also be undesirable.

Reference issue #193

[Delawen]

To remember: the list of available DSL will come from a backend endpoint, not hardcoded on the frontend.

[Delawen]

Show a warning to the user that the selected DSL is not compatible with the current DS

The compatibility does not go by DSL. All DSL (right now) are compatible with any other DSL. Because all of them are Camel DSL.

Right now the only difference is by the type of step used. Some types/kinds of steps are not valid inside some DSL. Today is branches, tomorrow? Who knows. It may even not be the type of step but a combination of steps or who knows? It will also depend on the DSLs we support later (when we merge the Syndesis DSL for example, this changes).

[kahboom]

So this means that if we want to support multiple DSLs we need to have some kind of context for steps? And branching? (part of steps?) And for whatever other thing in the future? For combination of steps, for example, how would we do this?

[Delawen]

No, it means that right now "validation" means one thing, but we don't know what it means in the future. So if we hardcode the validation on the frontend, we will have to maintain it both in the frontend and the backend, and synchronized.

[kahboom]

Yes, this should come from the backend and really the business logic should just be in one place.

[Delawen]

Allow them to select whatever they want, maybe still showing the warning from option 2, and rather than removing the branches or steps we can show them in red or something, as "problematic".

I would iterate over this option.

My proposal: each type/kind of step have a visual clue. Could be color, shape, background color,...

So when you select a DSL that contains unsupported steps, it will show a message like:

"This DSL only allows steps that are ${list_of_colors}. You have steps of color ${list} that will be removed from the integration. Are you sure you want to continue?"

So the user can look back at the integration and check which steps will be removed (select a good color scale for color blindness!). Then the user can open the catalog and look for alternative steps to replace them. This means the catalog must have the same visual clues, so the user can replace the step with another step that won't be problematic too.

[kahboom]

I didn't understand this.

Do you remember in Syndesis how we had a little ! triangle mini icon when something was not configured correctly? And my question is, should a step that is from the old DSL/incompatible with the new DSL be considered the same kind of 'misconfigured' as something that actually is misconfigured? For example if it's a Kamelet and not properly configured, or there is some other issue with the Step.

[Delawen]

And my question is, should a step that is from the old DSL/incompatible with the new DSL be considered the same kind of 'misconfigured' as something that actually is misconfigured?

A step that is from the old DSL in my opinion should disappear. It should never be on the graphic part.

Why? Because:

1.- Users tend to think that warnings are stupid. If I was able to plant the step on the graphic side, that means it will be accepted. In fact, they already ignored the warning saying the step will be removed.
2.- The source code in the text editor will not be in sync with the graphic side. If someone edits the source code, that step will be removed anyway on the refresh.

A misconfigured step? Sure, it will fail but it will be on the source code.
An incompatible step? It won't be there.

[kahboom]

A step that is from the old DSL in my opinion should disappear. It should never be on the graphic part.

Then isn't that the same as option 2?

[Delawen]

Mmmmm yes. You are absolutely right.

[kahboom]

Okay that's fine, we got there in the end. 👯‍♀️

[kahboom]

@Delawen - For option 2, how would the UI know which steps to clear? If I send the API a request with the same exact steps as before and just change the DSL, will it return the new YAML without those steps and branches?

[Delawen]

@Delawen - For option 2, how would the UI know which steps to clear?

To generate the warning message, you must know which steps are compatible with the DSL.

I propose that the same endpoint that returns the list of DSL gives you the list of compatible step types.

If I send the API a request with the same exact steps as before and just change the DSL, will it return the new YAML without those steps and branches?

Yes too.