Why we need a new concept?

Current implementation of choose dialog somewhat fights against the framework:

• No configuration in the tree is possible.
• Choose dialog actions are hard-coded and give no freedom in modifying the logic of choosing.
• Hacky and complex implementation of choose dialog for a content app is hidden behind a minimalistic ChooseDialogPresenter interface.
  
  • By default, when a content app is asked to provide a choose dialog - it duplicates a workbench and img provider def.
  • It uses WorkbenchChooseDialogPresenter and does all configuration in ContentApp class.
    
    • Child classes (e.g. AssetsApp) don't have a direct access to the implementation - everything has to be casted and a lot of assumptions have to be made in order to introduce modification.
• Choose dialog had to be closed manually by the consumer.

What can be done?

• We can treat choose dialogs the same way we treat form dialogs.
  • Configuration stored in registry.
  • Contains configurable actions (e.g. ChooseDialogCallback actions).
  • Configurable choose dialog UI-content. 
    
    • Most configs like actions, title and label can be shared between form and choose dialogs.
    • The main difference - instead of configuring the whole form we only need one field, whose value would be used for selection.
    • Workbench can be adapted to a CustomField fairly easy (at least without modifying the workbench itself).
  • We set up a registry for choose dialogs analogous to the form dialog registry (they extend all the base classes).
  • We do not use a ChoseDialogPresenterFactory anymore.
    
    • In order to get a different choose dialog  for an app a developer would have to implement a new factory and we don't want that.
    • We inject a ChooseDialogPresenter instead and it builds the view based on provided definition.
  • Choose dialogs can be now called by name (and/or by definition).
    
    • Looks like we can now have several different choose dialogs for a single app.
  • We can actually keep the old mechanism of creating a choose dialog as a fallback - in case absolutely no choose dialog is defined for an app at least try to construct it from the browser sub-app.
  • Actual choose process happens by means newly introduced ChooseDialogCallbackActions - similar to those DialogCallbackActions that fire a callback. 
    
    • The only difference more or less is that besides an action name we pass a chosen value into the callback (maybe there should be some kind of a callback context object so it would look prettier).
    • Additional choose logic can be added effortlessly to these action.
      
      • To close or not to close dialog.
      • To accept selection or not to accept selection (had a request for forbidding selection nodes without children just yesterday, the solution involved creation of custom ContentPresenters).
      • To fire additional notifications if needed.