UI Design Patterns - seandenigris/SeansPlayground GitHub Wiki

http://martinfowler.com/eaaDev/uiArchs.html

• MVC - View and Controller each communicate directly with the Model
• Separated Presentation - a key takeaway from MVC. Even Unix got this right i.e. graphical and command line interfaces to same library

Options for handling application-specific UI logic e.g. updating a model value changes the font color in the widget:

• Higher-level view (e.g. Window) observes lower-level e.g. TextView
• Subclass widget view e.g. Colored TextView
• Presentation Model - object representating the UI adds app-specific UI logic e.g. buttons enabled based on list selection PropertyObject - turns a property, like #name-> aString into an object with a standard interface (#value) and possibility of being observed onChangedSend:to:
  • ValueHolder wraps value
  • AspectAdapter holds object and aspect (e.g. #name)

##Autonomous View - drawbacks are possibly complex and hard to test, but in Morphic, the GUI is on the same level, so simple message sends drive the UI; although if you wanted to support multiple UIs it might be a problem. You tested the Morphic UI but if you also deploy to Seaside, how will you test the logic in the web client?

Simplify View, if don't want to test through it, or feel it's too complex

MVP

####Supervising Controller - lets the views handle things with the model unless it needs to jump in e.g. one field affects another list ###Passive View - handles all updates, not just when no other option

###Application Model - model of the GUI window as a whole, so views just need simple sync