Page History
...
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Main goals
- Adapt UI framework to Vaadin 8 concepts
- Data binding in forms, dialogs and grids - simplify the existing solution
Module View Presenter
| Reasons to bother | What changes | Benefits |
|---|---|---|
|
|
|
We use some reactive technology for convenient subscription....
| Reasons to bother | What changes | Outcome |
|---|---|---|
Quirky way of communicating the data source changes
| We should try to expose the data source observation utilities and subscribe to them where needed.
| Benefits
Questions
|
THE FOLLOWING STILL REQUIRES GROOMING
Affected parts:
UI framework in Magnolia involves different components and abstractions that function on different levels. In the scope of the current effort we plan to target/re-work only some of them.
- Content app de
- Content app implementation.
Main goals
The main purpose of the effort is to simplify the existing concepts
Current state overview
Framework should help the developers to build their apps with Magnolia faster, get access to the components and features, framework though should not be all the time in the way of the developer.
The current offering of the UI framework:
- Content app implementation
- Form framework
- Flexibility via configuration of the content apps
- Dependency injection via Guice and factory capabilities of the ComponentProvider
- EventBus API to share events between the UI parts
The problems:
...
- Solution proposal - let the views drive the process, treat presenters as optional, view-specific detail that merely helps to separate communication with the backend.
...
- As a result - lot's of redundant Listener interfaces between views and presenters.
- Each view and a presenter as a result is a Guice component mapped in the module descriptor, making it hard to override the parts with custom implementations.
- Can we treat views more as custom Vaadin components? Can we rely more on
ComponentProvider#newInstancemore when creating the views and merely using the impl classes coming from e.g. definitions? - Possible solution: provide views with out-of-the-box component provider and
#create()API, let them create sub-views easily.
...
How to share context and provide injectable components
...
- Views rarely require 'components' with specific lifecycle (typically they just need an instance of smth).
- Views, especially the ones that are bound to generic data, require generic instances to be provided. Guice does not support that easily (and our XML configs completely block that).
...
| Code Pro | ||||
|---|---|---|---|---|
| ||||
public interface UiFrameworkView extends View {
...
/**
* Wrapper around {@link ComponentProvider} capabilities.
*/
default <T> T create(Class type, Object... args) {
return getComponentProvider().newInstance((Class<T>) type, args);
}
default ViewProvider getViewProvider() {
return new ViewProvider.Impl(getCurrentViewReference());
}
default ComponentProvider getComponentProvider() {
return new ViewComponentProvider(getCurrentViewReference());
}
default UiContextReference getCurrentViewReference() {
return ViewContextKeyRegistry.access()
.lookUp(this)
.orElseGet(() -> CurrentUiContextReference.get().getUiContextReference());
}
default <T extends ViewContext> T bindContext(Class<? extends T> contextClass) {
final T context = new ViewContextProxy().createViewContext(contextClass);
SessionStore.access().getBeanStore(getCurrentViewReference()).put(contextClass, context);
return context;
}
default void bindDatasource(Object definition) {
SessionStore.access().getBeanStore(getCurrentViewReference()).put(DatasourceHolder.class, new DatasourceHolder(definition));
}
}
|
How to bind to different data sources
The following could be a looser and more flexible replacement for the ContentConnector abstraction. Instead of having the monolithic interface, we rather could facilitate a DatasourceSupport that could provide data-binding implementations based on the exposed configuration by e.g. delegating to the registered reference implementations.
| Code Pro | ||
|---|---|---|
| ||
@Singleton
public class DatasourceSupport {
private final Map<Class, DatasourceBundle> bundles;
@Inject
public DatasourceSupport(Set<DatasourceBundle> bundles) {
this.bundles = bundles
.stream()
.collect(toMap(
DatasourceBundle::supportedDataSourceType,
identity()));
}
@SuppressWarnings("unchecked")
public <DEF> DatasourceBundle<DEF> getDatasourceBundle(DEF def) {
Objects.requireNonNull(def);
return Optional.ofNullable(bundles.get(def.getClass())).orElseThrow(() -> new IllegalArgumentException("No such bundle for the type " + def.getClass()));
}
}
@Multibinding
public abstract class DatasourceBundle<DEF> {
private final Class<DEF> type;
public DatasourceBundle(Class<DEF> type) {
this.type = type;
}
public Class<DEF> supportedDataSourceType() {
return this.type;
}
public abstract <T> T lookup(Class<T> type, DEF definition);
}
|
| Code Pro | ||||
|---|---|---|---|---|
| ||||
public class DatasourceComponentParameterResolver implements ParameterResolver {
private final DatasourceSupport datasourceSupport;
private final Object datasourceDefinition;
public DatasourceComponentParameterResolver(DatasourceSupport datasourceSupport, Object datasourceDefinition) {
this.datasourceSupport = datasourceSupport;
this.datasourceDefinition = datasourceDefinition;
}
@Override
public Object resolveParameter(ParameterInfo parameter) {
boolean isDatasourceComponent = Stream.of(parameter.getParameterAnnotations()).anyMatch(DatasourceComponent.class::isInstance);
if (isDatasourceComponent) {
return datasourceSupport
.getDatasourceBundle(datasourceDefinition)
.lookup(parameter.getParameterType(), datasourceDefinition);
}
return UNRESOLVED;
}
}
|
Questions:
...
Databinding in Grids
- Datasource support introduction might be a nice matching for the grid databinding requirements, since what is mostly required is the DataProvider (to fetch the row data) and the PropertySet (for the column rendering).
- Apparently it is possible to pass the PropertySet instance directly into the Grid making it aware of the underlying datasource properties, then configuration of the columns is just about assigning the captions and renderers.
...
Overview
Content Tools