[MGNLUI-156] Form: Separate the Form functionality from the dialog Created: 08/Nov/12  Updated: 11/Feb/13  Resolved: 05/Dec/12

Status: Closed
Project: Magnolia UI
Component/s: forms, framework
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: Espen Jervidalo Assignee: Espen Jervidalo
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
duplicate
relation
is related to MGNLUI-309 Don't show twice the header and foote... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLUI-139 Forms: create Form Builder, FormPrese... Sub-task Closed Espen Jervidalo  
MGNLUI-215 Migrate dialogs to new Definition con... Sub-task Closed Espen Jervidalo  
MGNLUI-218 Form: Introduce FormDefinitions, conf... Sub-task Closed Espen Jervidalo  
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

We want to use forms outside of dialogs.

This involves lots of tasks:

  • View (Vaadin) Client/Server side changes:
    • renaming where needed
    • create new Form* classes which take care of validation etc.
    • old FormDialog should be simplified to just be a simple BaseDialog containing the form
    • Remove unused FormDialog implementations

Configuration, conf-by-code, Builders

  • Builders for Forms, simplify DialogBuilder (throw it away at a later point)
  • add formDefinition containing tabs and field, used in workspaceDefinition and DialogDefinition
    • should move into nodeType-Registry at a later point
  • conf-by-code must be updated


 Comments   
Comment by Jan Haderka [ 27/Nov/12 ]
  • VForm
    • class level javadoc says "VTabDialog." ... which is wrong on so many levels I don't even want to list it all
  • VFormView
    • class level javadoc. Same abomination as above.
  • magnolia-ui-vaadin-common-widgets/pom.xml
    • you increased stack size. Why is this necessary? This needs to be explained ideally in the commit message or directly in the pom, but in the very least in the issue itself. Need to increase stack size is usually sign that there is deep recursion somewhere and by increasing size you just push this issue to later. IF this is the case there needs to be ticket open for this and we need to investigate issue in depth
  • VDialogHeader
    +    public void construct() {
    +        super.construct();
    +//        closeButton.setStyleName(CLASSNAME_CLOSEBUTTON);
    +//        closeButton.addStyleName("green");
    +//        add(closeButton, captionContainer);
    +
         }
    
    • really there is no need to override method to just call the superclass
  • FormBuilder
    +                } //This can happen in case of extends/override. FieldDefinition is ConfiguredFieldDefinition and of course no builder is linked to this.
    
    • inline comment by the end of is statement is little bit difficult to assign to code or condition that is X lines above. Can you always put such comments on top?
  • AbstractFieldBuilder
    • should use generics so extending classes don't need to override thousands of methods just to customise return type (see FileUploadFiledBuilder for example)
  • SaveContactFormActionDefinition, SaveContactFormAction, CancelFormActionDefinition
    • why do we need empty class?
  • SaveFormAction.traceNode*() methods
    • those methods have no place in Action class. They should be moved to NodeUtil class if they are useful and the logging level should be made configurable

And of course as in many cases with other issues - most of the classes have nonexistent javadoc.

Comment by Federico Grilli [ 27/Nov/12 ]

@Jan re the increased stack size, I did it during previous project-reorganization in the hope of mitigating the risk of OOME and SOE which occurred sometimes, see http://mojo.codehaus.org/gwt-maven-plugin/user-guide/compile.html. I can add a comment in the pom, I guess that's enough.

Generated at Mon Feb 12 08:34:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.