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
openDialog methods
TODO: rename to DialogUtil or something
Renaming of ContentApp classes
ItemWorkbenchPresenter -> ItemPresenter
ItemPresenter -> EditorPresenter
ContentWorkenchPresenter -> Contentpresenter
ContentPresenter -> Workbenchpresenter
These changes reflect the hierarchy in the configuration
On the map
- remove usage of DialogActionRegistry
- ActionDefinition (FormActionDef can be dropped -> ConfigActionDef) has Default implementation set, can be overriden
- formDefinition -> form
- drop DialogBuilder
- info.magnolia.ui.form.FormPresenterImpl remove all references to actions and callback
info.magnolia.ui.vaadin.form.Form
remove dataSource
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
- Review needed:
- Dialog and Form relationship
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 theForm
and theDialog
. Now it doesn't do anything
except for forwarding the method calls to the internalFormView
. This class has to be removed or should actually implement functionality of theFormView
.FormView
interface,ItemFormView
which implements it. Should be renamed as the implementation contains aForm
in theDialog
chrome and nowForm
andDialog
are separate concepts.
I propose it to become an EditorView (ItemEditorView
). As mentioned above - these could be merged withFormDialog.
BaseDialog
should now become aDialogLayout.
DialogActionListener
has to get a better name as now it is used in bothItemPresenter
andFormDialog
concepts (EditorActionListener??
).Form/FormView
should not manage validation and data-binding on their own. Instead theFormBuilder
should assemble theFieldGroup
and provide it to theForm
, 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 inFieldGroup
).- 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 likecallback
,validator
,item
inSaveFormAction
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.
4 Comments
Christopher Zimmermann
The refactor will also need to address classes like DialogAdaptingToFormView and EditorLike.
An Idea:
A diagram showing the different "elements" and how they are used.
Im suggesting that the elements should all be different classes, and that the uses use composition to assemble the elements to meet their UI requirements.
Tobias Mattsson
Meeting minutes February 12
1 field builders
-> vaadin 7
2 Form / Builder depend on JCR API?
-> Adapters
3 Actions on Container(dialog etc)
4 View / Edit
4 Naming of fields and properties
5 UML of Presenter, Callback
Choose Dialog
6 -> 2 Headers and footers
- > Form & Dialog
7 Modality
Tobias Mattsson
Here's my input after the March 15th meeting
what is a form?
what is a form dialog?
whats in an item sub app?
what do you configure on a dialog?
actions / buttons
IN SUMMARY
Screenshots of configuring a dialog and of configuring a form in an item sub app
Viet Nguyen