My Vaadin MVVM attempt

I am attempting to build a MVVM framework over Vaadin leveraging Annotation, Annotation Processor to generate codes, the ultimate goal is to create a framework that is

• suitable for rapid development - via code generation
• at the same time very flexible
  • assume default in most cases
  • allow override / customization over generated codes - but not "code over generated"
• type safe
  • no text based model / configurations
    • they are prone to errors
    • lacks tool support
  • everything based on java and annotation
    • strong typed
    • compiler / tool support
• Loose couple
  • use CDI as much as possible, so components are equipped with their own needs
• No "hidden secret"
  • generated codes can be viewed and are clear, so as allow developer to understand what's under the hood

References

http://msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx

Parts

Model

• plain java bean
• no knowledge to any framework
• annotations to indicate to be handled by the framework (annotation processor)
• pure business methods
• validations - via bean validation

Default View Specification (generated, suffix "DefaultViewSpec")

• Logic behind
  • needs some place to specify
  • model - not good place
    • model should be pure from view / view model
    • there might be multiple views to the same model
  • use FieldViewSpecification class
    • developer clearly know what can be specified with help of tool and checked by compiler
    • adding a specification does not break existing codes
    • default is provided in one place
• generated by annotation processor based on model
• no knowledge to any framework
• specifies the available options for the developer to specify to the view model and view
  • handle / not handle certain fields
  • hide / show certain fields
  • handle certain events
  • specify kind of UI control to handle field
  • specify if developer would override certain function
• implementation:
  • class FieldViewSpecification
    • define what can be specified towards a field, include
      • generate / not generate
      • hide / show
      • events
        • local method
        • event
      • type of field
        • default
    • with default values
  • class [BeanName]DefaultViewSpec (generated)
    • for each field, a public property with value of FieldViewSpecification with default values
    • actions may be performed

Final View Specification (by developer, suffix ViewSpec):

• override View Specification
• extend view specification (with additional labels, displays that does not bind to model, etc.)
• no knowledge of any framework
• change values of default view specification as needed

View Model Default Implementation (generated, suffix VMDefault)

• generated by annotation processor based on Final View Specification
• to avoid naming conflict, every prefix should be like "VMxxx"
• generated methods should be either final or abstract
• members
  • FieldGroup instance - creating and holding the fields; provides caching
  • // FieldGroupFieldFactory - the factory - maybe this is unnecessary;
  • Field
    • represents data at UI
    • is UI
    • generated by specification or abstract
    • (??) type safe
    • to be added into view and
    • bind to Property,
    • one for each field
  • Property
    • represents data at model
    • bind to model datasource, or directly from model
    • given to fields as data source
  • methods
    • constructor - with item / with bean
      • calls build and bind fields
    • receive Item
    • receive bean
    • actions (save, discard, etc.) - generated or abstract
    • bind view (give fields in right order with name)
    • event handling methods - listener method call - abstract
    • commit - call field group commit
    • discard - call field group discard
• generated by annotation processor based on Final View Specification
• abstract
• framework specific
• from specification, if behaviour is default, generate code (maybe designate "final" to prevent overriding)
• from specification, if developer want to override / implement, generate abstract code and surrounding code
• UI / UI related logic is here

View Model Final Implementation (by developer, suffix VM)

• extends default implementation
• implement abstract methods

View

• suffix: "View"
• focus on how components are displayed
• no knowledge of view model
  • view model controls fields
  • view model binds fields
• UI logic - only not related to view model
• no need to unit test
• behaviors
  • default constructor
  • accepts components from view model
    • (addComponent - name, Component, section [optional], specification [optional])
  • may expose UI components - tab, panel, etc.; all controlled by view model
• implementation
  • as simple as a layout; or
  • via some interface contract, provide more choices to view model
  • view model know how to handle such view according to Final View Specification