Properties in the generic step extension are not grouped in the correct way

[lhein]

Describe the Bug

The Camel Catalog provides information for every property of a Camel Component which group that property belongs to. Currently we do not group in the correct way (looks quite random).

The original Camel catalog should be leveraged to group the attributes correctly. I would suggest to use collapsible sections for each group to make it easier for users to filter what they are after.

In the Eclipse Camel Editor it was done like this:

Steps to Reproduce the Bug or Issue

1. select Camel Route type
2. select IMAP as source
3. select the IMAP node on the canvas to open the configuration panel

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 0.30.0]

[kahboom]

@Delawen is this something meant to be done in the UI or the backend, or both?

[Delawen]

The backend could order the parameters better, but right now we are not offering any grouping.

Should we add some kind of category property to the parameters attributes too? And if there is no category defined, do I left it empty or do we agree on a default category?

[lhein]

Where do section names in the above screenshot come from?

Sort Term Scheduler Properties Delay

[Delawen]

Those are not section names, those are properties that are of type object and therefore the default config tab does not know how to configure them.

[lhein]

If we cannot configure them, why bother users displaying them?

[kahboom]

Should we add some kind of category property to the parameters attributes too? And if there is no category defined, do I left it empty or do we agree on a default category?

I don't mind the idea of having some category for grouping properties, and maybe expanding/collapsing them for the default view. And if it's only one category or none we can just default to show them as we do now.

If we cannot configure them, why bother users displaying them?

@lhein maybe @Delawen has a better idea here, but I think it's because it'd be too much work to remove those properties, when instead we could just have step extensions to better handle supporting them, as sometimes they can be complex objects (we just don't know and it depends on each step).

It'd be pretty impossible to handle any complex object without a more formal schema for Kamelets (which we don't have). We can maybe add better default support in the UI for handling simple objects.

[lhein]

Right....that's why I think it is not worth displaying these properties in the generic form if we can't change them. For custom step extensions this is handled differently anyways. If the backend has no idea if the frontend can handle it then I agree that filtering would be too much work. In that case I would change the way of visualizing them. Currently they look like headline and are displayed bold. That is an eye catcher and easier to find than mandatory field marked with just a tiny *. Wdyt?

[kahboom]

Right....that's why I think it is not worth displaying these properties in the generic form if we can't change them. For custom step extensions this is handled differently anyways. If the backend has no idea if the frontend can handle it then I agree that filtering would be too much work. In that case I would change the way of visualizing them. Currently they look like headline and are displayed bold. That is an eye catcher and easier to find than mandatory field marked with just a tiny *. Wdyt?

That's correct, the backend has no idea if the frontend can handle it. I think (if we can) we should format the fields better, but I would need to study the majority of the objects that are returned, to see if we can handle a majority of the use cases with some custom fields for the objects. And maybe by grouping them with categories, as per Maria's suggestion. These would be enhancements that I'm not 100% sure would cover most use cases, but we can give it a shot.

EDIT: As for the required fields and tiny * that's a separate issue and discussion probably shouldn't happen on here. See https://github.com/KaotoIO/kaoto-ui/issues/1301.

[rstroop]

We should sort things the same way Camel does. Here is the link to the docs page for the ActiveMQ component for example: https://camel.apache.org/components/3.20.x/activemq-component.html

Currently Kaoto has a different order that is seemingly random. Camel groups properties by type and that information should be available to Kaoto in the schema for the component. The types are common, consumer, consumer(advanced), producer, producer (advanced), advanced, filter, logging, security, transaction, transaction (advanced). Within those groups, everything is alphabetized as it should be. But if you just alphabetize everything without the groups it gets messy.

Hopefully we can pull those groupings right out of the docs without any extra effort and keep them under expandable tabs so as not to clutter the screen with 100 properties. We also don't want to add our own metadata around sorting, we should use what's already in Camel until we have AI sorting it for us.

[lhein]

In the Camel Catalog there is the group information available...

[lhein]

[lhein]

The grouping information above is available for Camel Components only, but usually these have a lot more parameters in comparison to EIPs, Languages and Data Formats. We should show mandatory fields on top and then create collapsable sections for each of the groups and put in the corresponding parameters in each group in alphabetic order as mentioned by Richard.

[stale[bot]]

🚨This issue has been automatically marked as stale because it has not had recent activity.🚨 If you are still interested in this issue, please, leave a comment stating its current status. Note that if no development resources has been allocated on it, you may need to search for alternative resources to complete it. It will be closed if no further activity occurs. Thank you for your contributions.

[lhein]

buzz off, stale bot! ;)