Abstract

Using forms and dialogs should feel natural for a developer. The current implementation is flexible, but not very clear. Where to add actions, what classes are important.

Steps

Update SubAppDescriptor 

subApp

• editor
  
  • form
  • actions
    
    • actionName (maps to subapp actions)
• actions
• ..

TODO: move description and label from form to editor

Drop FormPresenterFactory

• Use IOC for the FOrmPresenter.
• pass formDefinition into start method

Changed role of FormDialogPresenterFactory

1. remove usage of DialogActionRegistry
   
   1. ActionDefinition (FormActionDef can be dropped -> ConfigActionDef) has Default implementation set, can be overriden
2. formDefinition -> form
3. drop DialogBuilder 
4. info.magnolia.ui.form.FormPresenterImpl remove all references to actions and callback

info.magnolia.ui.vaadin.form.Form

remove dataSource 

https://www.evernote.com/shard/s248/sh/fb0ec1cd-307f-4bdd-bef1-08a4a621e087/d97c8d46e5314eff588a88be9a2d4902

Analysis

Documentation

The documentation needs to be updated. Use the Employees App to showcase dialog usage. Form and ItemSubApp is already in place.

Form

• Do we want to have action definitions for forms or should the container take care of actions?
  
  • container = dialog, itemView in AbstractItemSubApp
  • If itemView is container we can't use the defined actions like info.magnolia.ui.admincentral.form.action.SaveFormAction
• Configuration
  
  • formDefinition currently in workbench and dialog definition.
  • itemType registry and configure form per item?

Dialog

• info.magnolia.ui.admincentral.dialog.builder.DialogBuilder lost relevancy after introducing FormBuilder
  
  • only some setters beeing used.
  • action mapping done in info.magnolia.ui.admincentral.dialog.DialogPresenter.DialogPresenterUtil
• Registry for dialogs

FormDialog

• info.magnolia.ui.admincentral.dialog.FormDialogPresenterImpl vs info.magnolia.ui.admincentral.form.FormPresenterImpl
  
  • too similar

Actions

• dialogActionRegistry
  
  • used for forms and dialogs
• callback concept at least needs some documentation
  
  • info.magnolia.ui.admincentral.dialog.DialogPresenter.Callback.Adapter usecase?
  • for forms?
• how to properly hook dialog actions and form actions?

Decisions

• General
  
  • documentation needs to be updated to reflect latest changes
  • Review needed
    
    • simplify builders, drop dialogBuilder?
    • views and presenters
  • migration needs to reflect latest changes
    
    • currently only the bootstrap files are changed and have the new form node under the dialog node.
    • currently there won't be any changes to the current configuration of dialogs and form, except for the removal of actions from the form
  • make some developer tests, after first iteration
  • formDefinition -> form
    
    
• Major sub tasks
  
  
  • Dialog and Form relationship
    
    • hide complexity with convenient methods or reduce it generally
  • Dialog Actions
    
    • will need separate effort for general cleanup, see Concept - Actions API and configuration
    • Actions are not part of the form, but the container
  • Form Fields
    
    • Review needed:
      
      • !! com.vaadin.data.fieldgroup
      • introduced w/ vaadin 7
      • basically the same concept as our fieldBuilders
    • last chance to change old, confusing names
      
      • http://wiki.magnolia-cms.com/display/DOCS/Fields

UML Diagrams with annotated Problems and Proposals

Diagrams and Notes made in the meeting.

Future Improvements

• FormDialog class has to be refactored/removed: this class used to be a significant component that was combining the Form and the Dialog. Now it doesn't do anything
  except for forwarding the method calls to the internal FormView. This class has to be removed or should actually implement functionality of the FormView.
• FormView interface, ItemFormView which implements it. Should be renamed as the implementation contains a Form in the Dialog chrome and now Form and Dialog are separate concepts. 
  I propose it to become an EditorView (ItemEditorView). As mentioned above - these could be merged with FormDialog.
• BaseDialog should now become a DialogLayout.
• DialogActionListener has to get a better name as now it is used in both ItemPresenter and FormDialog concepts (EditorActionListener??).
• Form/FormView should not manage validation and data-binding on their own. Instead the FormBuilder should assemble the FieldGroup and provide it to the Form, which in turn should 
  simply lay out the fields. This would allow us to enhance the workflow with forms, introduce transactional editing, simplify validation (drop our code in favor for the similar in FieldGroup).
• Many duplicate actions and actions with wrong names (related to Form/Dialog but not mentioning the new editor concept). Also the code of actions should be reviewed (e.g. access to protected fields like 
  callback, validator, item in SaveFormAction is duplicated by getter methods).
• Clear naming and structure of classes related to i18n: FormItem <- AbstractFormItem <- Form, Dialog, TabDefinition etc. The problem here is that the class names conflict with UI components,
  the hierarchy is not clear: both definition classes and field builders are present in it - we need to review it.
• Utilize Vaadin commit form process. Instead of just validating the form in the save action we could actually do the normal Vaadin commit cycle - validation + updating the buffered components -> we can 
  use transactional properties and Buffered forms.