Page History

• Way too many interfaces where a mere class would do (see IoC part as well)
• The way we used it before is cumbersome and not too beneficial.
• Concept of Model is not well defined.
• Poor component isolation patterns
  • views know about sub-views, presenters know about sub-presenters [...and sub-views].
  • poor state management (the parent views/presenters may just have most of the child view's state/business logic).

• We try to prefer classes over the interfaces. If we introduce interfaces, we try to keep them small and function-oriented.
• Instead of MVP we use something like MVVMP (Model-View-ViewModel-Presenter)
  • Model is the good ol' datasource like JCR workspace.
  • View is now the entry point and the driver of the pattern. Views may compose and even interact with each other (though we we should not encourage that!)
  • ViewModel is the state of the View (all the properties that define the view in real time)
  • Presenter - optional, completely isolated part which is used to help View interact with Model/ViewModel
• We implement the ViewModel part via so called ViewContexts - interfaces that describe a certain part of mutable state (selection, value, location etc).
  • We provide the views with the ability to bind contexts and share them with the sub-views (see more in the IoC section).
  • For the ease of use, we do not enforce the developer to actually implement the interfaces, we generate them. We use some reactive technology for convenient subscription.

• Views are more component-like and are easier to compose.
  • Interfaces/classes do not expose methods like #refresh(), that encourage external control over the view.
  • All the internal view state management happens in the view itself (no case when sub-app reacts on events and updates the state of the sub-views/components).
  • All the necessary context can be injected via ViewContexts
• Some synergy with how client-side frameworks manage the UI's (Redux/React contexts do similar things though in more conventional way)
• Less code to write (less noisy listener interfaces, less abstractions)

Quirky way of communicating the data source changes

• Requires manual actions of both sending the events and handling them. I.e. if I change smth in JCR and forget to send CCE, no one will ever know.
• Apps that are not related to the changed data source still have to handle its CCE and see if they should react (hence ContentConnector#canHandleItem).

We should try to expose the data source observation utilities and subscribe to them where needed.

• e.g. we have already the JCR observation mechanism that Vaadin's DataProvider can subscribe to in this or that way and just push the change notification to the UI automatically.
• Whenever we change smth in the data source the UI is notified eventually.
• For the data sources that do not have real time observation, we could easily provide a timer-based implementation that merely refreshes the UI periodically.

Benefits

• Clear and re-usable data source observation mechanism.
• Less boilerplate for the app developers

Questions

• Need to provide un-registration strategy. For some cases a mere weak-hashmap solution might work . We though should also make sure that once the view is dead, no observation left-overs are still hanging around