End of MVC is near, let's learn MVVM with ZK

Monday, September 4, 2017

The end of MVC, what are you talking about?

Model View Controller (​MVC), we all know it, we all learned it, and most of us use it.
​But like every technology, there is competition. Model View Presenter (MVP) and Model-View-ViewModel (MVVM).
The main thing of MVVM is separation of development. But it's more than that : Reusing ViewModels on other Views, or reusing views on other ViewModels.
​The learning curve for MVVM is also faster than for MVC.

​Let's dive into the ZK framework which implemented MVVM into their GUI framework and see why you'll want to use it.
​Is the end near? Well, it depends on you. If you like it, use it and share the word.

​Sounds to good, what's the catch?

Well as a developer you can actually let your designer create your GUI pages and set up a contract.
In ZK, this means creating zul pages (think aspx pages) and in the end he can't complain about the terrible GUI you created, it's on him.
​The contract is in fact an interface, so you know what methods your Viewmodel needs to have.
​I know, some of us are also the designer and we don't want to write endless series of interfaces.
​Well, again you don't have to. Interfaces aren't needed as long your ViewModel has everything your GUI need.
​Maybe the biggest catch: ViewModels are POJO's. No interface or abstract class needed.
​ZK has also the documentation on how MVVM is handled in the backend, if you want to explore the whole magic.

​First example, returning back to the real component.

One of the most greatest things in MVVM is that we can return to our initial components.
​Let's examine this Use case: I want to disable a button when all the fields are not filled in.
​Simple Use case, think of login screen. But why do we need to add eventlisteners to our textboxes in MVC? 
​It makes it hard to find problems, certainly when more input fields are involved.
​Personally I want my button to watch all the states in order to disable himself.
With MVVM this is possible.
​We don't add eventlisteners to our inputs but the button watches the state of the objects behind the input fields.
This is a ​simple and innovating technique. On top of that, it is easy to debug and maintain because I only need to look at one place

As you can see in the code, the disabled property of the button has a reference to two String properties in the VM.
​When a textbox is updated (without instant="true" it will be triggered when focus is lost of the textbox, in order to reduce network traffic) the binder will notify the button to evaluate the condition.
​As you can see, ZK uses in the zul pages the complete EL-3 expressions.
​A small explication about the annotations used in the zul:

  • ​@init : this means the object will be checked once, further changes to the object will not been seen;
  • @load : This means only load the data of the object => changes in browser will not be persisted to server or make object changes;
  • @save : This is the other way as @load. We don't fetch the data but changes in the browser will be persisted to the server;
  • @bind : This is a shortcut for @load() @save(), so in this case we load and persist the browser data;
  • @command : The action that must be activated when that event is triggered.

Second example: two separate views, one VM.

Let's take a deeper look into the image above.

  1. ​Same Viewmodel is used in the two pages: mvvm.CollectionVM
  2. ​In the viewmodel there are the following rules :
    1. VM needs a Collection<Object> getPersons() and the object in the list must have getFirstName() and getLastName()
    2. ​Needs a command with the name delete.
    3. Needs a command with the name showPersons.

If you look close you see it are two whole different pages, one page can even delete a person while the other one not.
With the following rules, a possible VM could be:


This VM will work for the two GUI pages created.
​The most intresting part is when refactoring code, the two pages are up to date.

Thirth example: one view, two VM's.

We can take for this example the exact same GUI page as in previous example.
​But we can change the VM to the next one:

You see the difference?
​If you look closely, we don't return Person but we return User. Of course, User has also a first and lastname property but doesn't need to have a common interface.
​Secondly, the implementation of our action is completly different.
If you don't see the advantages here: think that you can set a completly different viewmodel when loading a page, just depending on some security settings, system properties,...

​​How can I start?

Starting is easy and specialy when you can start with an existing project.
So, let's share this maven project.



Stay up to date with our newsletter.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.