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

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.

​Enjoy.