Propose to enhance the user interface on Creating/Editing Brokers

[gaohoward]

Currently when user chooses to create a broker or editing an existing broker, the plugin displays
a page that has 2 kinds of views, form view and yaml view. The form view currently is almost empty
and I suggest to replace it with a more broker focused view.

Below is a sample of existing view:

The new view would be something like:

It is just a sketch that shows the idea but not in its complete content.
This new view presents configurations as broker properties rather than
a custome resource. It breaks the whole configuration into some key config
categories of a broker. Each category will have a UI component for users
to add/remove/edit the items in it.

The new Broker view and the Yaml view should be synchronized, i.e. changes
from one view should be updated to the other -- they share one model.

This new form focus on the messaging part config by single it out in UI.
Even though it can offer cloud related options defined in the CR too.

One key benefit is that the spp plugin can utilize the brokerProperties
feature to configure the broker behind the scene. It prevents users to use
features that already deprecated. And also users don't need to know the
complex syntax of composing brokerProperties contents, the plugin will take
the user's input and convert them into brokerProperties automatically.

Any Thoughts?

[lavocatt]

I see that in the form there are many different topics, Addresses, Acceptors, Connnectors etc.
There's a pattern fly pattern we should consider using for this: https://www.patternfly.org/components/wizard

We've been using this for image builder, it's a good way to provide a multi step form to the user.

[lavocatt]

Speaking of pattern-fly I think we should use PF5 for any new components. I'll open a discussion on the subject.

[gaohoward]

Would it be better to have it as a single page application than a wizard?

[lavocatt]

The wizard is a single page though, but it helps to separate the concerns of every topics. The user sets up the fields they want for a category and move on to the next. It's actually not far from what you have on the design mock.

[lavocatt]

You can try it out on there: https://www.patternfly.org/components/wizard there are a few demo components.

[lavocatt]

Indeed there's also the collapsible sections in the form if you prefer it https://www.patternfly.org/components/forms/form#field-groups 🙂

[gaohoward]

For the moment I don't think the wizard is a good option, user still need to click on next multiple times. And I don't lik the collapsible form it seems clumsy. My suggestion is when user create or edit a broker the model is created with default values and the page will lay out all categories for user to edit. That's more straight forward.

[lavocatt]

I was proposing a wizard or collapsible sections because I'm worried that the page would endup being very long otherwise
And that the user might need to scroll a lot to access the fields they want to customize.

But that's maybe because I imagine that there are a lot of parameters to edit.

Do you know how many parameters we are targeting?

[gaohoward]

There is a lot configuration parameters. The main CRD https://github.com/artemiscloud/activemq-artemis-operator/blob/main/api/v1beta1/activemqartemis_types.go , and in the CRD definition there is a brokerProperties field and it takes an array of key/value pairs that can cover variety of broker specific configs the schema is here: https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/resources/schema/artemis-configuration.xsd.

Besides the operator also offer configuring logging and jaas modules vial secrets.

Yes I have the same concern. I think the best way is to arrange them into categories so that they can fit into one page.

[gaohoward]

The formGroups seems useful.