Presentation Patterns

In ZK
Simon Massey
(Revised Q2 2012)

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
zktodo2 repository at 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

Overview

Why Patterns?

Patterns recap of View and Model

Model, View, Who? The third part

Best practices for each layer

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

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

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 'how'
<attribute name=onClick><![CDATA[

MyDao myDao = ; // get

daoand
viarender
jndi mixed
Update
myDao.buyBook(user.id, hiddenBookId.value);
statusLabel.value = Thanks! Buy another book?;
]]></attribute>
</button>
<label id=statusLabel value=/>

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

The Triumvirate
View
View

Model
Model

who?
who?

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

The View
View
View

Model

who?

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)

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"

ZK Micro-Model == View
Listbox

Composer

ListModelList
ListModelList
(view layer)
Collection<Book> books
(business domain layer)

The Business Domain (Macro) Model

View

Model
Model

who?

Model Best Practices

The Business Domain Model should have no

compile time dependencies to the presentation
framework
EL and DataBinder 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)

The Other Bit...

View

Model

who?
who?

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

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(!!!)

Controller Of What?
View
View
?

Model
Model

Controller
Controller

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?

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

Model-View-Presenter
Legend

View

Model

compiles to
events

Presenter
Presenter

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 "

Model-View-Controller
Legend

View

compiles to
bindings
events

Model

Controller
Controller

Enter The Binder

View observes the state of the Model using

databinding
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!)

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

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"

ViewModel Nirvna

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-ViewBinder (MVB) highlights the key part

Model-View-Binder
View
Binder
Binder
<<reflection>>

ViewModel

Legend
compiles to
command

DomainModel

load

Model-View-Binder (Simplified)
View

Legend
compiles to
updates

Binder
Binder
<<reflection>>

Application Model
(has internal layers)

loads

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() { }

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

ViewModel Choices

Is ViewModel a Mediator to your Model? Is their

lots of plumbing to access your services?
Whether you "pull" through your ViewModel
"push" through Controller to BindModel is key
choice
My vote is to first attempt a strong ViewModel
with no Controller (but do what works for you)
ZK6 has GlobalEvents concept so that
Controllers can notify ViewModel
Nested ViewModels? Mix and match? Why not?

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

Summary (Cont 1)

"B" is for Binder which plays a part in MVC

"Supervising Controller" and major part of
MVVM "Presentation Model" patterns. There is
no "B" required for MVP "Passive View" pattern
The Microsoft Binder is powerful and a core
part of their framework. They promote 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!

Summary (Cont 2)

ZK has DataBinder for rendering POJO data values

and state (visible/disabled) into ZK AJAX RIA Desktop
Components
ZK6 adds CommandBinder to fire application methods
on the ViewModel
The binding information is embedded into the Page
(View) as "XML annotations"
ViewModel has no compile time dependencies on ZK
Components; can heavily junit with mock services
Using MVVM / MVB pattern is simply about getting the
most out of the framework Binder

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

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 2012: Slide 21 had crossed the wires on Passive

View and Supervising Controller