Parent: #320
Summary
Allow resources to replace the generic metadata-driven add dialog with a resource-specific wizard or custom dialog. Currently, AddResourceDialogs auto-generates form items from the :add operation's parameter descriptions with no way to customize the dialog.
Motivation
The classic example is a multi-step datasource wizard that walks the user through connection settings, pool configuration, validation, and timeouts — instead of presenting all parameters in a single flat form. Similar use cases exist for:
- Security domains (multi-step authentication/authorization setup)
- Credential stores (key store selection + alias configuration)
- Messaging destinations (topic/queue with specific defaults)
- Any resource where the generic form doesn't provide enough guidance or where parameters have complex interdependencies
Capabilities
- Replace the add dialog entirely — provide a custom
Promise<ModelNode> factory that replaces DialogBricks.addResourceModal()
- The custom dialog receives the same inputs (parent template, child name, singleton flag) and returns the same
Promise<ModelNode> result
Registration
A registry keyed by Environment + AddressTemplate. When DialogBricks.addResourceModal() is called for a matching template, the registry delegates to the custom dialog factory instead. Providers are CDI beans in org.jboss.hal.ui.resource.spi.
Affected Call Sites
ModelBrowser.add() — model browser add button
FinderBricks — finder column add action
ResourceList — resource list add button
CapabilityReferenceSupport / PathSupport — inline "create new" from form fields
Open Questions
- Should the custom dialog factory also handle the wizard variant (
addResourceWizard) for multi-template scenarios?
- Should there be a base class that provides common wizard infrastructure (step navigation, validation, progress) that custom wizards can extend?
Parent: #320
Summary
Allow resources to replace the generic metadata-driven add dialog with a resource-specific wizard or custom dialog. Currently,
AddResourceDialogsauto-generates form items from the:addoperation's parameter descriptions with no way to customize the dialog.Motivation
The classic example is a multi-step datasource wizard that walks the user through connection settings, pool configuration, validation, and timeouts — instead of presenting all parameters in a single flat form. Similar use cases exist for:
Capabilities
Promise<ModelNode>factory that replacesDialogBricks.addResourceModal()Promise<ModelNode>resultRegistration
A registry keyed by
Environment+AddressTemplate. WhenDialogBricks.addResourceModal()is called for a matching template, the registry delegates to the custom dialog factory instead. Providers are CDI beans inorg.jboss.hal.ui.resource.spi.Affected Call Sites
ModelBrowser.add()— model browser add buttonFinderBricks— finder column add actionResourceList— resource list add buttonCapabilityReferenceSupport/PathSupport— inline "create new" from form fieldsOpen Questions
addResourceWizard) for multi-template scenarios?