Technology Guidelines"

From Documentation
m (remove empty version history (via JWB))
 
(110 intermediate revisions by 6 users not shown)
Line 3: Line 3:
 
{{TOC limit|limit=2}}
 
{{TOC limit|limit=2}}
  
ZK provides end-to-end solutions from UI design, development, testing to production. Here is the technology guidelines to help developers to make choices along the way.  
+
ZK provides end-to-end solutions from UI design, development, testing to production. Here are the technology guidelines to help developers to make choices along the way.  
  
If you are new to ZK and prefer to understand ZK first, you could skip this section and go back later after you understand ZK more.
+
If you are new to ZK and prefer to have some prior knowledge of ZK first, you could skip this section and come back later when you understand more about ZK.
  
=[[ZK Developer's Reference/MVC|MVC]] vs. [[ZK Developer's Reference/UI Composing/ZUML/Scripts in ZUML|ZScript]]=
+
=[[ZK Developer's Reference/MVC|MVC]] vs. [[ZK Developer's Reference/MVVM|MVVM]] vs. [[ZK Developer's Reference/UI Composing/ZUML/Scripts in ZUML|ZScript]]=
  
They serve different purposes and could work together. However, some developers got confused about these two technologies.
+
They serve different purposes and could work together. However, some developers get confused about these technologies.
  
==When to use MVC==
+
==When to use MVC and/or MVVM ==
  
[[ZK Developer's Reference/MVC|MVC]] (Model-View-Control) is a design pattern that separates the model, view and controller clearly. It is easy to collaborate, develop and maintain. In addition, the performance is great since it is done in compiled Java code. MVC is strongly suggested for development, especially for production systems.
+
[[ZK Developer's Reference/MVC|MVC]] (Model-View-Control; aka., Model-View-Presenter) and [[ZK Developer's Reference/MVVM|MVVM]] (Model-View-ViewModel; aka., Presentation Model) are both design patterns that isolate the dependency among the domain data, the domain logic and the user interface. They are both supported by ZK, and they are praised for their [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and thus easy to collaborate, develop and maintain. For a production system, it is strongly suggested to take either MVC or MVVM  approach.
  
==When to use zscript==
+
MVC separates the design into three roles: Model, View, and Controller.  The controller is the ''middle-man'' gluing the view and the model (aka., data).
 +
 
 +
On the other hand, MVVM has three roles: Model, View, and ViewModel. The View and Model play the same roles as they do in MVC. The ViewModel in MVVM acts like a special controller. Unlike MVC, ViewModel introduces additional abstraction, so it can be written without any detailed knowledge of the view. In other words, the change of the view will have much less impact on the ViewModel. However, the extra abstraction requires extra design thinking.
  
[[ZK Developer's Reference/UI Composing/ZUML/Scripts in ZUML|Zscript]] allows you to embed Java code in ZUML pages. It speeds up the design cycle, so it could be a good approach for prototyping, POC and testing. It is also good for exploiting ZK features and reporting bugs to ZK. However, Like any interpreter, the performance is not good, and tends to be error prone, so it is ''not'' suggested to use in production systems.
+
In most cases, MVVM is suggested for better separation of concerns. On the other hand, MVC is good for small user interfaces and new ZK users, because it is quite straightforward.
  
==MVC Extractor==
+
==When to use zscript==
  
[[ZK Studio Docs|ZK Studio]] provides a tool called [[ZK Studio Essentials/Features of ZK Studio/Zscript to MVC Extractor|MVC Extractor]] that can convert zscript to MVC automatically. It simplifies to transfer the code from prototyping to production.
+
[[ZK Developer's Reference/UI Composing/ZUML/Scripts in ZUML|Zscript]] allows you to embed Java code in ZUML pages. It speeds up the design cycle, so this can be a good approach for prototyping, POC and testing. Zscript is also good for exploiting ZK features and reporting bugs to ZK. However, like any other interpreter, the performance is not very good as it tends to be error-prone. For this reason, it is ''not'' suggested to use zscript for production systems.
  
 
==Documentation links==
 
==Documentation links==
{| border='0'
+
{| class='wikitable' | width="100%"
 
|- valign="top"
 
|- valign="top"
 
| MVC:
 
| MVC:
 
|
 
|
 
* [[ZK Developer's Reference/MVC|ZK Developer's Reference: MVC]]
 
* [[ZK Developer's Reference/MVC|ZK Developer's Reference: MVC]]
 +
* [[ZK Developer's Reference/MVVM|ZK Developer's Reference: MVVM]]
 
* [[ZK Developer's Reference/Performance Tips/Use Compiled Java Codes|ZK Developer's Reference: Performance Tips]]  
 
* [[ZK Developer's Reference/Performance Tips/Use Compiled Java Codes|ZK Developer's Reference: Performance Tips]]  
* <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc> and <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>
+
* <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc> and <javadoc>org.zkoss.zk.ui.select.SelectorComposer</javadoc>
 
|- valign="top"
 
|- valign="top"
 
| ZSCRIPT:
 
| ZSCRIPT:
Line 38: Line 41:
 
|}
 
|}
  
=[[ZK Developer's Reference/Data Binding|Data Binding]]=
+
=[[ZK Developer's Reference/MVVM/Data Binding|Data Binding]]=
 
==When to use==
 
==When to use==
[[ZK Developer's Reference/Data Binding|Data Binding]] automates the data-copy plumbing code (CRUD) between UI components and the data source. It is strongly suggested whenever applicable, because it boosts the productivity a lot and the code is easy to read and maintain.
+
[[ZK Developer's Reference/MVVM/Data Binding|Data Binding]] automates the data-copy plumbing code (CRUD) between UI components and the data source. It is strongly suggested to use Data Binding whenever applicable because it can help boost programmers' productivity and the code is easy to read and maintain.
  
 
==When not to use==
 
==When not to use==
  
Barely. However, it requires more knowledge to learn than [[ZK Developer's Reference/UI Composing/ZUML/EL Expressions|EL expressions]], so EL expressions is an alternative for people, such as UI designer, not familiar with ZK, especially in the UI design phase.
+
Barely. However, as Data Binding requires more time and effort to learn than [[ZK Developer's Reference/UI Composing/ZUML/EL Expressions|EL expressions]], EL expressions provide an alternative for people not familiar with ZK, especially during the UI design phase.
 
 
The other limitation is that it could not be applied a component that is created later (after the page is initialized)<ref>This limitation will be resolved in the upcoming Data Binding 2).</ref>.
 
 
 
<blockquote>
 
----
 
<references/>
 
</blockquote>
 
  
 
==Documentation links==
 
==Documentation links==
  
* [[ZK Developer's Reference/Data Binding|ZK Developer's Reference: Data Binding]]
+
* [[ZK Developer's Reference/MVVM/Data Binding|ZK Developer's Reference: Data Binding]]
  
 
=[[ZK Developer's Reference/UI Composing/ZUML|ZUML]] vs. [[ZK Developer's Reference/UI Composing/Richlet|Richlet]] vs. [[ZK_JSP_Docs|JSP]]=
 
=[[ZK Developer's Reference/UI Composing/ZUML|ZUML]] vs. [[ZK Developer's Reference/UI Composing/Richlet|Richlet]] vs. [[ZK_JSP_Docs|JSP]]=
 
==When to use ZUML==
 
==When to use ZUML==
  
[[ZK Developer's Reference/UI Composing/ZUML|ZUML]] is XML-based approach to declare UI. It does not require programming knowledge, and works well with [[ZK Developer's Reference/MVC|MVC]], [[ZK Developer's Reference/Data Binding|Data Binding]] and others. It is strongly suggested unless you have different preferences (such as pure Java and JSP).
+
[[ZK Developer's Reference/UI Composing/ZUML|ZUML]] is an XML-based approach to declare UI. It does not require any programming knowledge and it works well with [[ZK Developer's Reference/MVC|MVC]], [[ZK Developer's Reference/MVVM/Data Binding|Data Binding]] and others. ZUML is strongly suggested for usage unless you have different preferences (such as pure Java and JSP).
 +
 
 +
However, if most parts of a page are in HTML scripts (such as header and footer) and the UI designer is not familiar with ZUML, you could still use JSP to define the page and then include ZUML page(s) for the part that requires ZK components.
  
Notice that using ZUML does not prevent you from creating components dynamically in Java. In fact, it is a common practice to use ZUML to layout the theme of the Web application, and then use pure Java to manipulate it dynamically.
+
Notice that using ZUML does not prevent you from creating components dynamically in Java. In fact, it is a common practice to use ZUML to layout the theme of a Web application, and then use pure Java to manipulate it dynamically.
  
 
==When to use Richlet==
 
==When to use Richlet==
  
A [[ZK Developer's Reference/UI Composing/Richlet|richlet]] is a small Java program that composes a user interface in Java for serving user's request. You could use it if you prefer to compose UI in pure Java (like Swing).
+
A [[ZK Developer's Reference/UI Composing/Richlet|richlet]] is a small Java program that composes a user interface in Java for serving a user's request. You could try to use it if you prefer to compose UI in pure Java (like Swing).
  
 
==When to use JSP==
 
==When to use JSP==
  
If you'd like to use ZK in legacy JSP pages, you could use one of following approaches:
+
If you would like to use ZK in legacy JSP pages, you could try one of following approaches:
  
#Use <code>&lt;jsp:include&gt;</code> to include a ZUL page.
+
#Include <code>&lt;jsp:include&gt;</code> in a ZUML page.
#Use [http://www.zkoss.org/product/zkjsp.dsp ZK JSP Tags] in a JSP page directly.
+
#Apply [http://www.zkoss.org/product/zkjsp.dsp ZK JSP Tags] to a JSP page directly.
  
Notice that ZUML support the use of HTML tags well (without JSP). For more information, please refer to [[ZK Developer's Reference/UI Patterns/HTML Tags|ZK Developer's Reference: HTML Tags]].
+
As described above, if most of a page consists of pure HTML code and the UI designer is not familiar with ZUML, you could use JSP to design the page and then include it in ZUML pages if necessary.
 +
 
 +
Notice that ZUML supports the use of HTML tags well (without JSP). For more information, please refer to the [[ZK Developer's Reference/UI Patterns/HTML Tags|ZK Developer's Reference: HTML Tags]].
  
 
==Documentation links==
 
==Documentation links==
  
{| border='0'
+
{| class='wikitable' | width="100%"
 
|- valign="top"
 
|- valign="top"
 
| ZUML:
 
| ZUML:
Line 96: Line 96:
  
 
=[[ZK Developer's Reference/UI Patterns/Browser History Management|Bookmarks]] vs. Multiple Pages=
 
=[[ZK Developer's Reference/UI Patterns/Browser History Management|Bookmarks]] vs. Multiple Pages=
A traditional page-based Web framework forces developers split an applications into pages. On the other hand, Ajax (ZK) allows developers to group a set of functionality into a single desktop-like page that enables a more friendly user experiences.
+
A traditional page-based Web framework forces developers to split an application into pages. On the other hand, Ajax (ZK) allows developers to group a set of functionality into a single desktop-like page that enables a more friendly user experience.
  
Grouping is better to base on the functionality, unless it is a small application. For example, it might not be a good idea to group administration with, say, data entry. Here are some guidelines:
+
Grouping is much better based on the functionality, unless it is a small application. For example, it might not be a good idea to group administration with, let's say, data entry. Here are some guidelines:
  
* If a set of functionality is a logical unit to use and/or to develop, you might group it as a single page.
+
* If a set of functionality is a logical unit to use and/or to develop, you might want to group it into a single page.
* If SEO (i.e., able to be indexed by search engine) is important, it is better to split into multiple pages (and turn on [[ZK Configuration Reference/zk.xml/The system-config Element/The crawlable Element|the crawlable option]]).
+
* If SEO (i.e., able to be indexed by search engine) is important, it is better to split UI into multiple pages (and turn on [[ZK Configuration Reference/zk.xml/The system-config Element/The crawlable Element|the crawlable option]]).
  
Whether UI shares the same template (such as header and footer) does not matter, since it is easy to make multiple pages to appear similarly (by use [[ZK Developer's Reference/UI Composing/ZUML/Include|inclusion]], [[ZK Developer's Reference/UI Patterns/Templating|templating]] and [[ZK Developer's Reference/UI Composing/Composite Component|composite]]).
+
It does not matter whether the UI shares the same template (such as header and footer) or not because it will be easy anyway to create similar multiple pages (by the use of [[ZK Developer's Reference/UI Composing/ZUML/Include|inclusion]], [[ZK Developer's Reference/UI Patterns/Templating|templating]] and [[ZK Developer's Reference/UI Composing/Composite Component|composite]]).
 
   
 
   
 
==When to use bookmarks (in single page)==
 
==When to use bookmarks (in single page)==
After grouping a set of functionality into a single page, you could still allow users to use BACK and FORWARD to switch among the states of the single page and even bookmark on a particular state, as if there are multiple pages. It can be done by use of so-called [[ZK Developer's Reference/UI Patterns/Browser History Management|Browser History Management]] (aka., bookmarks). You might consider it is a technique to simulate multiple pages (for a single page with multiple states).
+
After grouping a set of functionality into a single page, users can still click on the BACK and the FORWARD button to switch among the states of the single page and even bookmark on a particular state, as if there are multiple pages. This can be done by using [[ZK Developer's Reference/UI Patterns/Browser History Management|Browser History Management]] (aka., bookmarks). You might consider this as a technique to simulate multiple pages (for a single page with multiple states).
  
 
==When to use multiple pages==
 
==When to use multiple pages==
If a set of functionality is logically independent of another, you could make them as separated pages. To jump from one page to another, you could use the so-called [[ZK Developer's Reference/UI Patterns/Forward and Redirect|send-redirect]] technique.
+
If a set of functionality is logically independent of one another, you could make them as separated pages. To jump from one page to another, you could use the so-called [[ZK Developer's Reference/UI Patterns/Forward and Redirect|send-redirect]] technique.
  
 
==Documentation links==
 
==Documentation links==
  
{| border='0'
+
{| class='wikitable' | width="100%"
 
|- valign="top"
 
|- valign="top"
 
| Bookmarks:
 
| Bookmarks:
Line 126: Line 126:
 
|}
 
|}
  
=[[ZK Developer's Reference/UI Patterns/HTML Tags/The native Namespace|Native]] vs. [[ZK Developer's Reference/UI Patterns/HTML Tags/The XHTML Component Set|HTML Components]]=
+
=[[ZK Developer's Reference/UI Patterns/HTML Tags/The native Namespace|Native Namespace]] vs. [[ZK Developer's Reference/UI Patterns/HTML Tags/The XHTML Component Set|XHTML Components]]=
  
ZK provides [[ZK Developer's Reference/UI Patterns/HTML Tags|several ways]] to mix HTML tags in a ZUML document.  
+
ZK provides [[ZK Developer's Reference/UI Patterns/HTML Tags|several ways]] to use XHTML tags in a ZUML document. Here we will discuss [[ZK Developer's Reference/UI Patterns/HTML Tags/The native Namespace|native namespace]] vs. [[ZK Developer's Reference/UI Patterns/HTML Tags/The XHTML Component Set|XHTML components]]. In a ZUML document, they basically mean the same thing except for the XML namespace. Therefore it should be easy to switch between them.
  
==When to use native==
+
==When to use native namespace ==
  
By use of a XML namespace called [[ZK Developer's Reference/UI Patterns/HTML Tags/The native Namespace|the native namespace]], you could declare any tags in ZUML as long as it is valid to the client (i.e., any HTML tags for a browser). It is suggested to use this technology if the HTML tags are static, i.e., you won't change the content dynamically with Ajax. The header, sidebar, footer and layout elements are typical examples. It saves the memory at the server.
+
With the use of an XML namespace called [[ZK Developer's Reference/UI Patterns/HTML Tags/The native Namespace|the native namespace]], you could declare any tags in ZUML as long as they are valid to the client (i.e., any HTML tags for a browser). It is suggested to use this technology if the HTML tags are static. For example, you will not be able to change the content dynamically with Ajax. The header, sidebar, footer and the layout elements are typical examples. It saves the memory on the server.
  
==When to use HTML==
+
==When to use XHTML components==
  
ZK also provides a set of components to represent each HTML tag at the server. It is suggested if you want to change their content dynamically, since they behave the same as other ZK components. However, since it is a component, it consumes the server's memory.
+
ZK also provides a set of components to represent each XHTML tag on the server. Unlike the native namespace, these are the 'real' ZK components.
 +
 
 +
It is suggested that you change their content dynamically because they behave the same as other ZK components. However, since it is a component, it consumes the server's memory.
  
 
==Documentation links==
 
==Documentation links==
Line 145: Line 147:
 
=[[ZK Developer's Reference/UI Composing/ZUML/Include|Include]], [[ZK Developer's Reference/UI Composing/Macro Component|Macro]], [[ZK Developer's Reference/UI Composing/Composite Component|Composite]] and [[ZK Developer's Reference/UI Patterns/Templating|Templating]] =
 
=[[ZK Developer's Reference/UI Composing/ZUML/Include|Include]], [[ZK Developer's Reference/UI Composing/Macro Component|Macro]], [[ZK Developer's Reference/UI Composing/Composite Component|Composite]] and [[ZK Developer's Reference/UI Patterns/Templating|Templating]] =
  
They allow developers to modularize the UI such that it is easier to develop, maintain and reuse.
+
They allow developers to modularize the UI such that it becomes easier to develop, maintain and reuse.
  
 
==When to use include==
 
==When to use include==
  
[[ZK Component Reference/Essential Components/Include|Include]] allows you to include a ZUML page, a static page, a JSP page or the result of a servlet. It is suggested if you'd like to:
+
[[ZK Component Reference/Essential Components/Include|Include]] allows you to include a ZUML page, a static page, a JSP page or the result of a servlet. This is the most suitable for usage if you would like to:
  
 
# Include a non-ZUML page
 
# Include a non-ZUML page
Line 162: Line 164:
 
==When to use macro components==
 
==When to use macro components==
  
[[ZK Developer's Reference/UI Composing/Macro Component|Macro components]] allow developers to define a new component with a ZUML page. It is suggested if you'd like to reuse a ZUML page across different pages, because
+
[[ZK Developer's Reference/UI Composing/Macro Component|Macro components]] allow developers to define a new component with a ZUML page. So if you would like to reuse a ZUML page across different pages, you can use it because
  
 
#Though optional, you could [[ZK Developer's Reference/UI Composing/Macro Component/Implement Custom Java Class|encapsulate the behavior in a Java class]]
 
#Though optional, you could [[ZK Developer's Reference/UI Composing/Macro Component/Implement Custom Java Class|encapsulate the behavior in a Java class]]
 
#It is easier to map a macro component to another URI, if necessary
 
#It is easier to map a macro component to another URI, if necessary
#The use of a macro component is no different from other components
+
#There is no difference between the use of a macro component and other components
  
 
==When to use composite components==
 
==When to use composite components==
[[ZK Developer's Reference/UI Composing/Composite Component|Composite component]] is another way to define a new component<ref>It is more a particular pattern of extending an existent component than a technology.</ref>. With this approach, you could extend it from any existent component. However, you must implement a Java class to represent the component, and then, unlike macro components, handle the component creation from a ZUML page by yourself<ref>It could be done easily with <javadoc method="createComponents(java.lang.String, org.zkoss.zk.ui.Component, java.util.Map)">org.zkoss.zk.ui.Executions</javadoc>.
+
[[ZK Developer's Reference/UI Composing/Composite Component|Composite component]] is another way to define a new component. With this approach, you could extend a new component from any existent components. However, you must implement a Java class to represent the component<ref>Here is an example of composite components in [http://www.zkoss.org/zkdemo/composite/composite_component ZK Demo]</ref>. Unlike macro components, you have to handle the component creation from a ZUML page by yourself<ref>There is a utility called [https://github.com/zanyking/ZK-Composite ZK Composite]. It allows to define a composite component with Java annotations. Please refer to [[Small Talks/2011/December/Define Composite Component using Java Annotation in ZK6|Small Talks: Define Composite Component using Java Annotation in ZK6]] for the details.</ref>.
  
It is suggested if you want to inherit the behavior from an existent component, such as <javadoc>org.zkoss.zul.Window</javadoc> and <javadoc>org.zkoss.zul.Listitem</javadoc>.
+
Feel free to use composite components if you want to inherit the behavior from an existent component, such as <javadoc>org.zkoss.zul.Window</javadoc> and <javadoc>org.zkoss.zul.Cell</javadoc>, and enhance it to have child components defined in a ZUML document.
  
 
<blockquote>
 
<blockquote>
Line 180: Line 182:
 
==When to use templating==
 
==When to use templating==
  
[[ZK Developer's Reference/UI Patterns/Templating/Composition|Templating]] allows developers to define UI fragments, and how to assemble them into a complete UI at runtime. Its use is very different from other approaches. However, it is suggested if you'd like the overall layout to be decided at runtime based on, say, user's role or preference.
+
[[ZK Developer's Reference/UI Patterns/Templating/Composition|Templating]] allows developers to define UI fragments and define how to assemble them into a complete UI at runtime. Its use is very different from other approaches. Feel free to use templating if you would like the overall layout to be decided at runtime based on, let's say, users' roles or preferences.
  
=Performance=
+
=Performance and Security=
  
For production systems, it is strongly recommended to take a look at [[ZK Developer's Reference/Performance Tips|Performance Tips]] first.
+
For production systems, it is strongly recommended to take a look at the [[ZK Developer's Reference/Performance Tips|Performance Tips]] and [[ZK Developer's Reference/Security Tips|Security Tips]] sections first.
  
 
=JSF=
 
=JSF=
  
 
==When to use==
 
==When to use==
JSF is a page-based framework and too complicated. We strongly recommend to use ZK instead of JSF. ZK can do whatever JSF can, and better. However, if you have to use ZK with legacy JSF, please refer to the [[ZK Developer's Reference/Integration/Embed ZK Component in Foreign Framework|Embed ZK Component in Foreign Framework]] section<ref>Notice that [[ZK_JSF_Docs|ZK JSF Components]] is no longer supported.</ref>.
+
JSF is a page-based framework. Because it is too complicated to use, we strongly recommend you to deploy ZK. ZK can do whatever JSF can do or even better. However, if you have to use ZK with legacy JSF, please refer to the [[ZK Developer's Reference/Integration/Embed ZK Component in Foreign Framework|Embed ZK Component in Foreign Framework]] section<ref>Notice that [[ZK_JSF_Docs|ZK JSF Components]] is no longer supported.</ref>.
  
 
<blockquote>
 
<blockquote>
Line 196: Line 198:
 
</blockquote>
 
</blockquote>
  
=Version History=
+
 
{{LastUpdated}}
 
{| border='1px' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 10:23, 5 February 2024


Technology Guidelines


ZK provides end-to-end solutions from UI design, development, testing to production. Here are the technology guidelines to help developers to make choices along the way.

If you are new to ZK and prefer to have some prior knowledge of ZK first, you could skip this section and come back later when you understand more about ZK.

MVC vs. MVVM vs. ZScript

They serve different purposes and could work together. However, some developers get confused about these technologies.

When to use MVC and/or MVVM

MVC (Model-View-Control; aka., Model-View-Presenter) and MVVM (Model-View-ViewModel; aka., Presentation Model) are both design patterns that isolate the dependency among the domain data, the domain logic and the user interface. They are both supported by ZK, and they are praised for their separation of concerns and thus easy to collaborate, develop and maintain. For a production system, it is strongly suggested to take either MVC or MVVM approach.

MVC separates the design into three roles: Model, View, and Controller. The controller is the middle-man gluing the view and the model (aka., data).

On the other hand, MVVM has three roles: Model, View, and ViewModel. The View and Model play the same roles as they do in MVC. The ViewModel in MVVM acts like a special controller. Unlike MVC, ViewModel introduces additional abstraction, so it can be written without any detailed knowledge of the view. In other words, the change of the view will have much less impact on the ViewModel. However, the extra abstraction requires extra design thinking.

In most cases, MVVM is suggested for better separation of concerns. On the other hand, MVC is good for small user interfaces and new ZK users, because it is quite straightforward.

When to use zscript

Zscript allows you to embed Java code in ZUML pages. It speeds up the design cycle, so this can be a good approach for prototyping, POC and testing. Zscript is also good for exploiting ZK features and reporting bugs to ZK. However, like any other interpreter, the performance is not very good as it tends to be error-prone. For this reason, it is not suggested to use zscript for production systems.

Documentation links

MVC:
ZSCRIPT:

Data Binding

When to use

Data Binding automates the data-copy plumbing code (CRUD) between UI components and the data source. It is strongly suggested to use Data Binding whenever applicable because it can help boost programmers' productivity and the code is easy to read and maintain.

When not to use

Barely. However, as Data Binding requires more time and effort to learn than EL expressions, EL expressions provide an alternative for people not familiar with ZK, especially during the UI design phase.

Documentation links

ZUML vs. Richlet vs. JSP

When to use ZUML

ZUML is an XML-based approach to declare UI. It does not require any programming knowledge and it works well with MVC, Data Binding and others. ZUML is strongly suggested for usage unless you have different preferences (such as pure Java and JSP).

However, if most parts of a page are in HTML scripts (such as header and footer) and the UI designer is not familiar with ZUML, you could still use JSP to define the page and then include ZUML page(s) for the part that requires ZK components.

Notice that using ZUML does not prevent you from creating components dynamically in Java. In fact, it is a common practice to use ZUML to layout the theme of a Web application, and then use pure Java to manipulate it dynamically.

When to use Richlet

A richlet is a small Java program that composes a user interface in Java for serving a user's request. You could try to use it if you prefer to compose UI in pure Java (like Swing).

When to use JSP

If you would like to use ZK in legacy JSP pages, you could try one of following approaches:

  1. Include <jsp:include> in a ZUML page.
  2. Apply ZK JSP Tags to a JSP page directly.

As described above, if most of a page consists of pure HTML code and the UI designer is not familiar with ZUML, you could use JSP to design the page and then include it in ZUML pages if necessary.

Notice that ZUML supports the use of HTML tags well (without JSP). For more information, please refer to the ZK Developer's Reference: HTML Tags.

Documentation links

ZUML:
Richlet:
JSP:

Bookmarks vs. Multiple Pages

A traditional page-based Web framework forces developers to split an application into pages. On the other hand, Ajax (ZK) allows developers to group a set of functionality into a single desktop-like page that enables a more friendly user experience.

Grouping is much better based on the functionality, unless it is a small application. For example, it might not be a good idea to group administration with, let's say, data entry. Here are some guidelines:

  • If a set of functionality is a logical unit to use and/or to develop, you might want to group it into a single page.
  • If SEO (i.e., able to be indexed by search engine) is important, it is better to split UI into multiple pages (and turn on the crawlable option).

It does not matter whether the UI shares the same template (such as header and footer) or not because it will be easy anyway to create similar multiple pages (by the use of inclusion, templating and composite).

When to use bookmarks (in single page)

After grouping a set of functionality into a single page, users can still click on the BACK and the FORWARD button to switch among the states of the single page and even bookmark on a particular state, as if there are multiple pages. This can be done by using Browser History Management (aka., bookmarks). You might consider this as a technique to simulate multiple pages (for a single page with multiple states).

When to use multiple pages

If a set of functionality is logically independent of one another, you could make them as separated pages. To jump from one page to another, you could use the so-called send-redirect technique.

Documentation links

Bookmarks:
Multiple Pages:

Native Namespace vs. XHTML Components

ZK provides several ways to use XHTML tags in a ZUML document. Here we will discuss native namespace vs. XHTML components. In a ZUML document, they basically mean the same thing except for the XML namespace. Therefore it should be easy to switch between them.

When to use native namespace

With the use of an XML namespace called the native namespace, you could declare any tags in ZUML as long as they are valid to the client (i.e., any HTML tags for a browser). It is suggested to use this technology if the HTML tags are static. For example, you will not be able to change the content dynamically with Ajax. The header, sidebar, footer and the layout elements are typical examples. It saves the memory on the server.

When to use XHTML components

ZK also provides a set of components to represent each XHTML tag on the server. Unlike the native namespace, these are the 'real' ZK components.

It is suggested that you change their content dynamically because they behave the same as other ZK components. However, since it is a component, it consumes the server's memory.

Documentation links

Include, Macro, Composite and Templating

They allow developers to modularize the UI such that it becomes easier to develop, maintain and reuse.

When to use include

Include allows you to include a ZUML page, a static page, a JSP page or the result of a servlet. This is the most suitable for usage if you would like to:

  1. Include a non-ZUML page
  2. Use a page (Page) to encapsulate a ZUML page[1][2]

The limitation of Include is that you can not encapsulate its behavior in a Java class (like macro or composite components do).

  1. You have to specify mode="defer" to create a Page instance.
  2. Whether a page is required really depends on developer's preference. Introducing a page is more complicated but logically more loosely-coupled.

When to use macro components

Macro components allow developers to define a new component with a ZUML page. So if you would like to reuse a ZUML page across different pages, you can use it because

  1. Though optional, you could encapsulate the behavior in a Java class
  2. It is easier to map a macro component to another URI, if necessary
  3. There is no difference between the use of a macro component and other components

When to use composite components

Composite component is another way to define a new component. With this approach, you could extend a new component from any existent components. However, you must implement a Java class to represent the component[1]. Unlike macro components, you have to handle the component creation from a ZUML page by yourself[2].

Feel free to use composite components if you want to inherit the behavior from an existent component, such as Window and Cell, and enhance it to have child components defined in a ZUML document.


  1. Here is an example of composite components in ZK Demo
  2. There is a utility called ZK Composite. It allows to define a composite component with Java annotations. Please refer to Small Talks: Define Composite Component using Java Annotation in ZK6 for the details.

When to use templating

Templating allows developers to define UI fragments and define how to assemble them into a complete UI at runtime. Its use is very different from other approaches. Feel free to use templating if you would like the overall layout to be decided at runtime based on, let's say, users' roles or preferences.

Performance and Security

For production systems, it is strongly recommended to take a look at the Performance Tips and Security Tips sections first.

JSF

When to use

JSF is a page-based framework. Because it is too complicated to use, we strongly recommend you to deploy ZK. ZK can do whatever JSF can do or even better. However, if you have to use ZK with legacy JSF, please refer to the Embed ZK Component in Foreign Framework section[1].


  1. Notice that ZK JSF Components is no longer supported.



Last Update : 2024/02/05

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.