Best practices changes
We aim for maximum configurability and flexibility of out UI views/presenters. Shipping them as Guice components like below seems to go against such idea:
- It only complicates overriding them with custom extensions
- Views/presenters never have any scope attached to them (i.e. they're always one-shot instances)
- It is hard to provide required information to UI components with Guice (e.g. typically some sort of definition is required and then we inject the sub-app descriptor just cause it is the only injectable definition, and read sub-definitions from there).
- Shipping views as Guice components restricts usage of generics: one cannot inject e.g
TreeView<T> treeViewsince Guice needs to know explicit generic type upon injector creation (which will fail blaming such arg as under-specified).
In order to mitigate the above and in order to avoid weird patterns when presenter first injects the view somehow, and then initialises it with an obscure and bulky method like e.g.:
public TreeView start(WorkbenchDefinition workbenchDefinition, EventBus eventBus, String viewTypeName, ContentConnector contentConnector)
WithImplementationinterface proposed to 'standardise' the definitions which incorporate implementation type.
UiFrameworkViewhas convenience API that allows to 'un-pack' and instantiate objects from such definitions.
ViewDefinitionof course implements it.
- There's no convention re: presenter provisioning, typically views just create them manually atm, but we could also introduce smth like
PresentedViewwhich allows to specify (and configure) the presenter class on definition level and then auto-create it with the view.
As it is mentioned in View interface extensions concept, each framework view is automatically provisioned with its own
ComponentProvider instance (called
ViewComponentProvider). It roughly the same thing as any other
UiContextBoundComponentProvider, i.e. it'll point Guice to look for scoped instances in the session store. The distinguishing difference of
ViewComponentProvider though, that it adds two additional
ParameterResolvers to the blend, making
ComponentProvider#newInstance API more powerful in case of the views:
ViewContextParameterResolverlooks up c-tor arguments in the bean stores that are in the context of the current views (its own and its parents), which allows us to avoid having to pass around a bunch of objects like definitions, selected items etc.
DatasourceComponentParameterResolverdescribed in Datasource bundles
Example: injection of definition and value context in