Page History

...

• We can treat choose dialogs the same way we treat form dialogs.
  • Configuration stored in registry. 
    
    • We extract the generic registry for base dialogs out of the form dialog registry and create choose dialog registry on its basis.
    • Definition managers and providers can be created the same way.
  • 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.