Description
Description
This feature request asks to add support for overriding storage behavior for Admin UI extensions that use UiTabProviderFactory
and UiPageProviderFactory
.
Currently, the initial version of the Java API for extending the UI uses the org.keycloak.provider.ConfiguredProvider
mechanism to allow CRUD of lists of ComponentModel
s.
It would be helpful to allow extension developers to override the storage behavior so that they could use their own mechanism of exposing and storing the configuration.
Discussion
Motivation
As discussed here, many existing extension authors have already created their own storage mechanism (e.g. using JPA entities, calling a remote API, etc.), using something other than ComponentModel
instances to store their configuration.
The motivation for this can be:
- They have a complex model that cannot easily be recreated in
ComponentModel
- Their extension use case requires them to load their entities/configuration by something other than the full list, ID, or type, which is the current restriction of components.
- They simply didn't know it was an option, and now have a mature extension that uses something else.
- It is unreasonable to believe that an extension author will significantly modify their extension storage layer in order to introduce a bad design/hack of duplicate configuration.
Details
Suggested implementation
- Create an interface that can be implemented along with
UiTabProviderFactory
andUiPageProviderFactory
. E.g.
public interface ComponentStorageFactory {
Stream<ComponentModel> getComponentsStream();
ComponentModel getComponent(String id);
void create(ComponentModel component);
void update(ComponentModel component);
void remove(ComponentModel component);
}
- Update ComponentResource to change behavior if the type of component has implemented
ComponentStorageFactory