This document discusses different patterns for separating the view, model, and controller/presenter layers in a ZK application. It describes the MVP, MVC, and MVVM/MVB patterns and compares their approaches. It provides best practices for implementing each layer, such as avoiding business logic in the view and using databinding to sync the view and model. The document emphasizes that the view model pattern focuses on separating application state and behavior from the view using databinding annotations.

1. Presentation Patterns
In ZK
Simon Massey
(Revised Q2 2012)

2. Introduction
First version of this presentation was given to the
2010 UK ZK Users Group
The "ZK ToDo 2" patterns sample code is in the
zkforge project svn repository github.com
Sample code has the same screen implimented
three times; as MVP, MVC and MVVM (MVB)
Published articles document the MVP and MVC
versions. Article coming soon about MVVM...
See references at the end

3. Overview
Why Patterns?
Patterns recap of View and Model
Model, View, Who? The third part
Best practices for each layer

4. Why Patterns? Evolving Software
A business sponsor talks about the screens but
requires a flexible business solution
Screens are likely to change all the way through
to go-live and well beyond
Features evolve slowly over time whilst the
screens can change drastically
Can you easily reskin / re-layout / rearrange your
app to freshen your user experience?
Making flexible and adaptable solutions is more
rewarding than making brittle apps

5. Why Patterns? A Challenge!
Reuse a "buy now" feature of your website in an
iphone app (as XML over HTTP)
This requires separation of View from Model

6. Programming In The View
Business state stored in
view
<label id=”hiddenBookId” value=”${book.id}” visible=”false”/>
<button label=”Buy Book”>
View knows 'who' and
<attribute name=”onClick”><![CDATA[
'how'
MyDao myDao = … ; // get daoand render mixed
Update via jndi
myDao.buyBook(user.id, hiddenBookId.value);
statusLabel.value = ”Thanks! Buy another book?”;
]]></attribute>
</button>
<label id=”statusLabel” value=””/>

7. Avoid Coding In The View
"Separated Presentation” is a core pattern
Presentation is incidental to what the customer is
logically doing which is the Use Case / User
Story (e.g. "customer buys book")
The presentation changes fast and often so
separate it out from the business logic
Junit testing of the presentation is tricky
Business logic within the View stunts the
flexibility of your software design

8. The Triumvirate
View
Model who?

9. Micro vs. Macro
Much of the literature about MVC describes the
fine grained "micro-MVC" used to implement
graphical components such as Swing/JSF
When reading articles it helps to think "Is this
micro-MVC or macro-MVC?"
This century we tend to pick a winning UI
component framework (ZK!) and focus on
"macro-MVC" for complex business screens
This presentation talks about the macro world
unless explicitly stated

10. The View
View
Model who?

11. View Best Practices
"ZK Desktop == View" so mixing Java business
logic into ZK code is mixing business logic into
the View
View components should not become business
components:
BuyNowButton extends Button // avoid!
The View should observe the Model using the
databinder (more on this later):
org.zkoss.zkplus.databind.AnnotateDataBinder

12. View Has Micro Models
A BindingModel is an "push through" to update
the View. Writing to it updates the bound View
These micro models are not business domain
models which organise application features
ListModelList is binding model class for Listbox
listModelList = (ListModelList)listbox.getModel();
AnnotateDataBinder uses such micro-models as
part of its logic to sync data into the View
Intbox and Datebox have "value" property as
micro-Model as well as "visible" and "disabled"

13. ZK Micro-Model == View
Listbox Composer
ListModelList
(view layer)
Collection<Book> books
(business domain layer)

14. The Business Domain (Macro) Model
View
Model who?

15. Model Best Practices
The Business Domain Model should have no
compile time dependencies to the presentation
framework
EL and AnnotateDataBinder should load data
from the Model into the View (avoid coding)
Ideally the Model should be a rich Domain Model
have both behaviour as well as state
Beware designs of proceedural code loading and
saving DTOs as this is weak OO
Try test driven development of encapsulated
layers ("POJOs In Action" book)

16. The Other Bit...
View
Model who?

17. Alphabet Soup
MVC: Model-View-Controller
Often cited but do we really know it as well as we
believe?
MVP: Model-View-Presenter
A specialism of MVC with a dominant controller
MVVM: Model-View-ViewModel
The Microsoft WPF pattern of the Application Model
but how do we use it with ZK?
MVB: Model-View-Binder
A clearer moniker for "MVVM" with ZK

18. MVC Has Many Interpretations
Martin Fowler:
Different people reading about MVC in different
places take different ideas from it and describe
these as 'MVC'.
Anon on c2.com:
Stuff nearest the User becomes the View, stuff
nearest the database becomes the Model, stuff in
between becomes the Controller. Marketects then
refer to their project's architecture as "MVC",
borrowing that acronym's impressive lineage(!!!)

19. Controller Of What?
View
? ?
Model ? Controller

20. The Controller Revisited
Typically org.zkoss.zk.ui.util.Composer but what
are it's responsibilities?
Does Controller read/write the Model? Yes
Does Controller read/write the View? Perhaps
Does View read/write the Model? Possibly
Is separation of behaviour (Controller) from state
(Model) the only game in town? No
Is databinding with AnnotateDataBinder part
View, part Controller, or a separate thing?

21. Model-View-ZKComposer
org.zkoss.zk.ui.util.Composer usually used as the
3rd part of the pattern
Whether it is a Controller or a Presenter depends
on the interactions with View and Model:
Presenter – pushes to Passive View
Controller – updates a model observed by the View
("Supervising Controller")
Any mix or match of the above will be called
MVC. People say "traditional MVC" to mean
View observes the Model updated by Controller

22. Model-View-Presenter
Legend
compiles to
View
events
Model Presenter

23. Model-View-Presenter
The View is the fully owned by the Presenter
ZkToDoControllerV1 implements Composer
Pushes all updates into the Passive View
ZkToDoControllerV1 implements ListitemRender
Presenter reacts to View Event notifications and
updates the Model
ZkToDo2 app example zktodo2_a.zul
For code write-up google "Massey Small Talks/2008/
November/ZK "

24. Model-View-Controller
Legend
compiles to
View
bindings
events
Model Controller

25. Enter The Binder
View observes the state of the Model using
databinding
<?init class=”org.zkoss.....AnnotateDataBinderInit”?>
Uses EL annotations within the ZUL page
<textbox value=”@{person.firstname}”/>
The @{pojo.property} annotations automatically
reads/write your POJOs (no UI event handling
code required as ZK Binder does the work
automatically!)
Google "site:dzone.com mvc zk massey"

26. Controller Best Practices
Aim to have the Controller and View not
communicate with one another. Let the binder
to the work
Have the binder pull the data from the Model with
load hints rather than having the composer
push data into the view model
<textbox value=”@{person.firstname,
load-after='buyButton.onClick'}”/>
zktodo2_b.zul example should have used
more 'load-after' hints and less Java code (see
weather-station-mvvm.zul)

27. Model-View-ViewModel
ViewModel (Microsoft) is similar to an
ApplicationModel (Smalltalk)
Binder syncs application state into the View
Binder maps View Events onto application
methods (ICommand types in .Net C#)
Gather both state and behaviour into one
application model (stronger OO design)
Binder is part of the View world. The application
model is its model: so called it a "ViewModel"

28. ViewModel Nirvāna
Josh Smith (msdn.microsoft.com):
"ViewModel classes are easy to unit test … Views and
unit tests are just two different types of ViewModel
consumers"
"ViewModel classes can assist in properly designing
user interfaces that are easy to skin"
"It is easy to just rip one view out and drop in a new view
to render a ViewModel"
It's all about the Binder. The name Model-View-
Binder (MVB) highlights the key part

29. Model-View-Binder (Simplified)
Legend
View compiles to
updates
Binder loads
<<reflection>>
Application Model
(has internal layers)

30. Model-View-Binder
View
Binder
<<reflection>>
Legend
ViewModel compiles to
command
DomainModel load

31. Model-View-ZKBind
Components are bound to ViewModel by the
Binder:
<listcell label="@load(reminder.name)"/>
UI Events are dispatched to ViewModel methods
by the Binder:
<button label="Save" onClick="@command('save')"/
>
ViewModel has annotations to inform Binder of
any properties changed under the covers
@NotifyChange({"reminders","selectedReminder"})
public void save() { … }

32. MVB/MVVM Best Practices
View Model has no references to View Objects
only @Command and @NotifyChange annotations
Create ViewModel classes which are "naked
screens" onto which you overlay a zul skin
ViewModel is the Mediator of the Binder to the
Model; it orchestrates the services
Use Dependency Injection of service interfaces
into the View Mode
ViewModel uses application services to get
detached entites which it exposes to the Binder

33. Summary
Presentation patterns are all about modelling the
features of our application independently of the
frequently changing screens
MVC, MVP, MVVM all have in common a
separated view
Modelling of the Model will lead to internal layers
Labels such as "ViewModel" or "DataModel" or
"ApplicationModel" are suggestions as to what
is trying to be organised where

34. Summary (Cont 1)
"B" is for Binder which plays a big part in MVC
and major part of MVVM patterns. There is no
"B" required for MVP
The Microsoft Binder is powerful and a core part
of their framework. They invented MVVM as the
best practice to organise a screen Model to
leverage their Binder
MVB is a moniker that names the new power in
modern Separated View patterns: long live the
Binder!

35. Summary (Cont 2)
ZK has a mature AnnotateDataBinder for rendering
POJO data values and state (visible/disabled) into ZK
AJAX RIA Desktop Components
The binding information is embedded into the Page
(View) as "XML annotations"
Add ZKToDo2 CommandBinder to fire application
methods on the ViewModel
ViewModel has no compile time dependencies on ZK
framework; can heavily junit with mock services
Using MVVM / MVB pattern is simply about getting the
most out of the framework Binder

36. Summary (Cont 3)
ZkToDo patterns demo code implements the
same screen in each of MVP (zktodo_a.zul),
MVC (zktodo_b.zul) and MVVM (zktodo_e.zul)

37. References
MVC article Desktop MVC Patterns ZK, Spring & JPA
Original MVP article
SmallTalks 2008 Best MVC Patterns
Book on how to build a layered domain model with
Spring POJOs In Action
ZK MVC Screen for POJOs In Action book code
Test Driving ZK FoodToGo
Book on designing ”domain objects first” for supple code
Evans Domain Driven Design
Martin Fowler GUI Patterns pages UI Architectures
Josh Smith's inspirational Microsoft .Net MVVM Article

38. Corrections
March 2012: Slide 13 had totally miss attributed Fowler where I
was using the term "Presentation Model" to mean something
totally different. Edited to call my concept "BindingModel"
March 212: Slide 21 had miss labelled Passive View as
Supervising Controller