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.
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.
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:
Let's take a deeper look into the image above.
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.
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,...
Starting is easy and specialy when you can start with an existing project.
So, let's share this maven project.