ZK Dos and Donts Part2"
| Line 72: | Line 72: | ||
=='''Call notify on non ViewModel Objects'''== | =='''Call notify on non ViewModel Objects'''== | ||
| − | MVVM data-binding enable efficient communication between the view and the view model. In most cases, a command from the view will result in a change notification from the view model. Automatic updates are triggered by methods annotated with @NotifyChanges or @ | + | MVVM data-binding enable efficient communication between the view and the view model. In most cases, a command from the view will result in a change notification from the view model. Automatic updates are triggered by methods annotated with @NotifyChanges<ref> http://books.zkoss.org/zk-mvvm-book/8.0/syntax/notifychange.html </ref> or @DependsOn<ref> http://books.zkoss.org/zk-mvvm-book/8.0/syntax/dependson.html </ref>, but a more granular control can be achieved, resulting in an increased efficiency and lowered response times over a large number of operations. |
In part 1, we showcased a few patterns making use of the build-in notifications of the ListModel classes, such as ListModelList. We can apply some of these improvements to POJOs, beans and basically any object used in data binding. For example, you can decide to only update the value of a POJO field such as: | In part 1, we showcased a few patterns making use of the build-in notifications of the ListModel classes, such as ListModelList. We can apply some of these improvements to POJOs, beans and basically any object used in data binding. For example, you can decide to only update the value of a POJO field such as: | ||
<source lang="java" >BindUtils.postNotifyChanges(null,null,myPojo,”myField”);</source> | <source lang="java" >BindUtils.postNotifyChanges(null,null,myPojo,”myField”);</source> | ||
Revision as of 03:12, 2 June 2016
Matthieu Duchemin, Engineer, Potix Corporation
June 2, 2016
ZK 8
ZK Do's and Don'ts Part 2
ZK Framework offers many features to simplify the creation of Java-based web applications. Some of these features are not always well known. From time to time, we come across suboptimal implementation. Usually, it only takes a few simple steps to make them simpler and easier. These aren't necessarily broken or damaging, but improving them can have very positive effects with few changes or efforts. You will find here a few cases where ZK efficiency can be maximized. For more ZK do's and don'ts, check out part1.
Example project available here
Choosing the most appropriate way to add reusable UI fragments to a page
Creating a page by inserting code fragments from external files is a very efficient way to create a dynamic page while avoiding code repetition and sometime you may need to include a completely different document in your layout. To that effect, ZK offers different ways to add external code to your layout:
html component works like an HTML SPAN tag enclosing the HTML fragment. It will output the html directly.
Iframe Creates and HTML iframe. Delegate a portion of the display to another URL, loaded by the browser by sending a request to the specified URL.
Include Insert the output of another document in the current page. By default, include will use the "auto" mode which selects "instant" or "defer" based on the included content. Include mode will cause different behavior and DOM structure in instant or defer mode, for example a new page instance is create for the content in defer mode.
Apply [shadow element] Resolve a zul template and insert its content directly in the current page structure. The zul template will behave as if directly written in the current zul structure.
Do:
- Use apply whenever possible, especially to avoid includes and macro-components complexity.
- Use apply to re-use code fragments in multiple locations.
- Use apply to dynamically change the content of a document based on conditions and zul fragments.
- Use include to insert zuml pages or zul fragments in a zuml document.
- Use Iframe to insert a full html page (with an <html> element) in a zuml document.
- Use Iframe to insert external references or full documents (html pages, pdf files, etc.) in your layout.
Don’t:
- Use Iframe if you want your page to communicate easily with the inserted content.
- Use include to insert a full document, such as a full html page.
- Output user-generated html without verification with the HTML component, as this compon doesn't perform checks for malicious code
Resolving the “Component definition not found: [shadow element]” exception
ZK 8 introduced shadow elements to help developers create dynamic pages based on templates. These shadow elements are introduced here When using one of these shadow elements, you may encounter one of the following exceptions:
- Component definition not found: apply in [LanguageDefinition: xul/html]
- Component definition not found: choose in [LanguageDefinition: xul/html]
- Component definition not found: forEach in [LanguageDefinition: xul/html]
- Component definition not found: if in [LanguageDefinition: xul/html]
- Component definition not found: otherwise in [LanguageDefinition: xul/html]
- Component definition not found: when in [LanguageDefinition: xul/html]
Shadow elements require the zuti.jar, so this would likely be caused by a missing zuti dependency. Zuti is available in ZK Eval and EE packages. If you are using maven, make sure that the zuti dependency is declared in your Pom.xml file:
<dependency>
<groupId>org.zkoss.zk</groupId>
<artifactId>zuti</artifactId>
<version>${zk.version}</version>
</dependency>If you are manually managing your dependencies, make sure to add the zuti jar to your project. See the example project pom.xml file for an example on how maven dependencies can be used to resolve this package.[link to pom.xml file]
Do:
- Use shadow elements to easily create dynamic layouts when appropriate for your project.
Don’t:
- Forget to include the zuti jar in your dependencies.
Call notify on non ViewModel Objects
MVVM data-binding enable efficient communication between the view and the view model. In most cases, a command from the view will result in a change notification from the view model. Automatic updates are triggered by methods annotated with @NotifyChanges[1] or @DependsOn[2], but a more granular control can be achieved, resulting in an increased efficiency and lowered response times over a large number of operations. In part 1, we showcased a few patterns making use of the build-in notifications of the ListModel classes, such as ListModelList. We can apply some of these improvements to POJOs, beans and basically any object used in data binding. For example, you can decide to only update the value of a POJO field such as:
BindUtils.postNotifyChanges(null,null,myPojo,”myField”);
Keep also in mind that @NotifyChanges(“myVmField”) is equivalent to:
BindUtils.postNotifyChanges(null,null,this,”myVmField”);
Do:
- Use BindUtils.postNotifyChanges or @NotifyChanges when reasonable to update the view.
- Try to send the smallest possible updates when updating the view.
Don’t:
- Update a whole container or a whole collection when a single value has changed to avoid unnecessary exchanges.
- Use @NotifyChanges if you only need to update part of your object.
Using multiple sizing mechanisms on the same components
ZK offers multiple options to specify sizes on components when creating a layout. While some of these options can be used in conjunction, it is generally easier to avoid using multiple sizing methods on the same components. Some sizing mechanisms can also give unexpected results when used in conjunction, when the result isn’t logical. When using flex min on a container, you instruct it to size up to host all of its content. If you set flex true on the content, it will try to size up to fill its container. In that case, the end result will depend on which component calculate its size first.
Do:
- Use the most appropriate sizing mechanism for your control.
- Swap sizing mechanisms anytime you need.
Don’t:
Use multiple sizing mechanisms on the same component at the same time when a simpler solution is available.
CRUD operations on ListModels using MVVM
When updating a ListModel in MVVM, calling NotifyChange on the whole ListModel is the simplest way to update the view. However, this will cause the whole ListModel to be resent to the client. When performing CRUD operations on a ListModel, you can take it one step further and only send an incremental update for the right entries. On large or very complicated ListModels, this can make a significant difference in response size, and in client-side processing. You will find some examples of such operations here. This example illustrates a few ways to optimize exchanges between the View Model and the View for CRUD operations, but specific implementations can vary depending on the requirements.
Do:
- try to keep updates as light as possible by using targeted update mechanisms.
Don’t:
- Update a whole ListModel when changing a single or a few entries.
- Use @load() on your ListModel when @init is enough. (see ZK Do’s and Don’ts part 1 here).
References
Comments
| Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License. |