Page History

• Too many Guice components
  • type mappings should just do the trick
• Guice does not support generics
• No good support for View-scoped components
  • Can only share sub-app components which is not enough often
• Hard to share such essential objects as definitions

ViewProvider API

Special factory API that creates the view with all the following additional features.

Bean Storages for the views

Each framework view gets the bean storage (same as app/sub-app) and can store objects in there. Each view can create sub-views and their storages will form an hierarchy with the parent's which makes it easy to traverse the parent storages from the child ones.

Sharing objects between views

Each view can bind view contexts (see MVP pattern changes) and publish other objects like definitions so that all the child views can access them effortlessly

ComponentProvider for every view

Each view gets its own ComponentProvider bound to the view's UI key. Each such component provider is enhanced with two additional ParameterResolvers:

• ViewContextParameterResolver - upon ComponentProvider#newInstance calls this one looks up the constructor dependencies from the bean storage hierarchy (e.g. shared with the mechanism above).
• DatasourceComponentParameterResolver - provides support for the datasource related components injection (see ContentConnector changes description)

Benefits:

• Ability to share configuration/resources between the views without coding overhead.
  • E.g. a root view can share some context; and then all the sub-views on all the levels can inject that context without any need to pass it through all the intermediate parents.
• Better support for the pattern improvements described above.

Questions:

• How to know when to clean up the view context?
  • We only have one similar example - choosers, their context is cleaned up when dialog is closed.
  • Should we also attach this logic to maybe Vaadin attach/detach events?
  • Should we communicate that the views/sub-views should be closed manually?
• How to attach the sub-views properly?
  
  • should we do it manually?
  • should we pass the parent container/attachment lambda? (same might work for closing of the view as well)
• We probably require additional tooling to make the thing

• CC seems to be incomplete, over-promising interface
  • while claiming to be "the connection" to the data source it merely provides the conversion between different forms of the item (id → Vaadin Item → url fragment and back);
  • CC doesn't provide any child/parent relations API;
• part of CC's functionality becomes obsolete with Vaadin 8
  
  • Vaadin Items are no longer there, the corresponding CC methods can/should go too;
• It is hard to extend the CC interface. E.g. if we want to add API that provides support for item version look-up or support for item creation - we have to create the extending interface and then cast the CC to the extension;
• CC is not generic (partially cause it is not possible to inject generics with Guice);

Instead of single CC interface we can introduce a concept of a DataSourceSupport:

• it would be based on an arbitrary DS definition attached to app/sub-app/view
• it would manage so-called 'bundles' of utilities that provide various functionality realted to the data source.
  • once an app with JCR DS configured needs e.g. a Vaadin HierarchicalDataProvider, we can ask the DS support to give one. It looks up the bundle corresponding to JCR DS definition and sees if the bundle provides an HDataProvider.
  • Bundles are completely arbitrary, they may contain domain specific utlitites and components

Benefits

• Flexible and versatile provisioning of DS components (properysets, data providers, hierarchy look-ups, to-string converters etc)
  
  

Concerns

• Such solution adds a bit of magic - DSSupport and DS Bundles are yet two more layers of indirection, though still they typically should be concealed behind IoC - maybe that is not a big deal?
• It wouldn't be easy to provision generic DS components via Guice, the #newInstance(...) variant will work just fine.