ZK 6: Upgrade Notes"

From Documentation
m (correct highlight (via JWB))
 
(24 intermediate revisions by 6 users not shown)
Line 12: Line 12:
 
First, you have to upgrade the following addons if you ever use them:
 
First, you have to upgrade the following addons if you ever use them:
  
 +
* <code>zel.jar</code> replaces <code>zcommons-el.jar</code> to support EL 2.2. It is shipped with [[ZK Installation Guide/ZK Background/The Content of ZK Binary Distribution|ZK's binary distribution]], so just copy it from the <code>dist/lib</code> folder.<ref>If you prefer EL 1.1 (i.e., backward compatible with ZK 5), please remove <code>zel.jar</code> and copy <code>zcommons-el.jar</code> to your project instead. Notice that ZK Bind (our new generation of data binding) utilizes EL 2.2 to support two-way binding, so don't use <code>zcommons-el.jar</code> if you want to use the new data binding.</ref>. Though optional, it is suggested to remove <code>zcommons-el.jar</code>.
 
* ZK JSP 2.0 or later. [http://code.google.com/p/zkjsp/downloads/list Download here].
 
* ZK JSP 2.0 or later. [http://code.google.com/p/zkjsp/downloads/list Download here].
 
* ZK Calendar 2.1.1 or later. [http://code.google.com/p/zkcalendar/downloads/list Download here].
 
* ZK Calendar 2.1.1 or later. [http://code.google.com/p/zkcalendar/downloads/list Download here].
Line 18: Line 19:
 
Second, you have to remove <code>breeze.jar</code> since [[#Breeze is the default theme|breeze has become the standard theme]]. Without removing the old <code>breeze.jar</code>, it might cause some CSS conflicts.
 
Second, you have to remove <code>breeze.jar</code> since [[#Breeze is the default theme|breeze has become the standard theme]]. Without removing the old <code>breeze.jar</code>, it might cause some CSS conflicts.
  
Third, search if you implemented any renderer in zscript, such as <javadoc type="interface">org.zkoss.zul.ListitemRender</javadoc>,  <javadoc type="interface">org.zkoss.zul.RowRender</javadoc> and <javadoc type="interface">org.zkoss.zul.TreeitemRender</javadoc><ref>If you implement them in pure Java, the compiler will identify the errors for you.</ref>. If so, please refer to [[#The_render_method_of_ListitemRender.2C_RowRender.2C_TreeitemRender_and_ComboitemRender_are_changed|this section]] for how to fix them.
+
Third, search if you implemented any renderer in zscript, such as <javadoc type="interface">org.zkoss.zul.ListitemRenderer</javadoc>,  <javadoc type="interface">org.zkoss.zul.RowRenderer</javadoc> and <javadoc type="interface">org.zkoss.zul.TreeitemRenderer</javadoc><ref>If you implement them in pure Java, the compiler will identify the errors for you.</ref>. If so, please refer to [[#The_render_method_of_ListitemRender.2C_RowRender.2C_TreeitemRender_and_ComboitemRender_are_changed|this section]] for how to fix them.
  
Fourth, clean and compile your project. If there is a compile error, please check the corresponding section below. On the other hand, it is OK to ignore the warnings of deprecation and generic-type checks, though it is a good idea to fix them too.
+
Fourth, If you ever use the autowiring feature of [[ZK Developer's Reference/UI Composing/Macro Component/Implement Custom Java Class|macro components]] (i.e., wiring child components to data members automatically), please refer to [[#Autowiring_of_macro_components_are_changed|this section]] for how to fix it.
  
Finally, <tt>zcommons-el.jar</tt> is replaced with <tt>zel.jar</tt> supporting EL 2.2<ref>If you prefer EL 1.1 (i.e., backward compatible with ZK 5), please remove <tt>zel.jar</tt> and copy <tt>zcommons-el.jar</tt> to your project instead. Notice that ZK Bind (our new generation of data binding) utilizes EL 2.2 to support two-way binding, so don't use <tt>zcommons-el.jar</tt> if you want to use the new data binding.</ref>. Though optional, it is suggested to remove <code>zcommons-el.jar</code>.
+
Finally, clean and compile your project. If there is a compile error, please check the corresponding section below. On the other hand, it is OK to ignore the warnings of deprecation and generic-type checks, though it is a good idea to fix them too.
  
 
<blockquote>
 
<blockquote>
Line 32: Line 33:
 
==org.zkoss.zk.zul.api.* are removed==
 
==org.zkoss.zk.zul.api.* are removed==
  
The component's API interfaces (<tt>org.zkoss.zk.ui.api.*</tt>, <tt>org.zkoss.zul.api.*</tt>...) are removed<ref>The reason to remove them is they cause more confusion than the abstraction benefit. In additions, they are costly and error-prone to maintain.</ref>. Please replace them with the concrete classes. For example, use <tt>org.zkoss.zul.Window</tt> instead of <tt>org.zkoss.zul.api.Window</tt>.
+
The component's API interfaces (<code>org.zkoss.zk.ui.api.*</code>, <code>org.zkoss.zul.api.*</code>...) are removed<ref>The reason to remove them is they cause more confusion than the abstraction benefit. In additions, they are costly and error-prone to maintain.</ref>. Please replace them with the concrete classes. For example, use <code>org.zkoss.zul.Window</code> instead of <code>org.zkoss.zul.api.Window</code>.
  
 
You could use the search-and-replace or refactor feature in your IDE to replace the package name. Here is an example [http://screencast.com/t/sR1V9XczXD that uses Eclipse to replace the package name].
 
You could use the search-and-replace or refactor feature in your IDE to replace the package name. Here is an example [http://screencast.com/t/sR1V9XczXD that uses Eclipse to replace the package name].
Line 43: Line 44:
 
==The render method of ListitemRender, RowRender, TreeitemRender and ComboitemRender are changed==
 
==The render method of ListitemRender, RowRender, TreeitemRender and ComboitemRender are changed==
  
For sake of performance and consistency, the render method of <javadoc type="interface">org.zkoss.zul.ListitemRender</javadoc>, <javadoc type="interface">org.zkoss.zul.RowRender</javadoc>, <javadoc type="interface">org.zkoss.zul.ComboitemRender</javadoc>, <javadoc type="interface">org.zkoss.zul.TreeitemRender</javadoc> are changed. An addition argument called index was introduced. You can use it instead of accessing the component's index (such as <javadoc method="getIndex()">org.zkoss.zul.Listitem</javadoc> for better performance.
+
For sake of performance and consistency, the render method of <javadoc type="interface">org.zkoss.zul.ListitemRenderer</javadoc>, <javadoc type="interface">org.zkoss.zul.RowRenderer</javadoc>, <javadoc type="interface">org.zkoss.zul.ComboitemRenderer</javadoc>, <javadoc type="interface">org.zkoss.zul.TreeitemRenderer</javadoc> are changed. An additional argument called index was introduced. You can use it instead of accessing the component's index (such as <javadoc method="getIndex()">org.zkoss.zul.Listitem</javadoc> for better performance.
  
Notice that, while Java compiler will detect the changes, you have to maintain zscript manually if you ever implemented them in zscript.
+
Notice that while Java compiler will detect the changes automatically, you have to maintain zscript manually if you have implemented them in zscript.
 +
 
 +
==addSelection/removeSelection methods of Selectable are changed==
 +
 
 +
For ease of understanding, addSelection method of <javadoc type="interface">org.zkoss.zul.ext.Selectable</javadoc> has been changed to addToSelection(), while removeSelection method of <javadoc type="interface">org.zkoss.zul.ext.Selectable</javadoc> has been changed to removeFromSelection().
  
 
==org.zkoss.zk.ui.util.Initiator is simplified==
 
==org.zkoss.zk.ui.util.Initiator is simplified==
  
For easy extension and better consistency<ref>Most initiators need to override the <tt>doInit</tt> method</tt>, and it is consistent with <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc>.</ref>, the <javadoc type="interface">org.zkoss.zk.ui.util.Initiator</javadoc> class now has only one method called <tt>doInit</tt>. The <tt>doAfterComposer</tt>, <tt>doCatch</tt> and <tt>doFinally</tt> methods are moved to <javadoc type="interface">org.zkoss.zk.ui.util.InitiatorExt</javadoc>. In other words, if you'd like to override any of these methods, your initiator has to implement both <javadoc type="interface">org.zkoss.zk.ui.util.Initiator</javadoc> and <javadoc type="interface">org.zkoss.zk.ui.util.InitiatorExt</javadoc>.
+
For easy extension and better consistency<ref>Most initiators need to override the <code>doInit</code> method</code>, and it is consistent with <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc>.</ref>, the <javadoc type="interface">org.zkoss.zk.ui.util.Initiator</javadoc> class now has only one method called <code>doInit</code>. The <code>doAfterComposer</code>, <code>doCatch</code> and <code>doFinally</code> methods are moved to <javadoc type="interface">org.zkoss.zk.ui.util.InitiatorExt</javadoc>. In other words, if you'd like to override any of these methods, your initiator has to implement both <javadoc type="interface">org.zkoss.zk.ui.util.Initiator</javadoc> and <javadoc type="interface">org.zkoss.zk.ui.util.InitiatorExt</javadoc>.
  
 
<blockquote>
 
<blockquote>
Line 57: Line 62:
  
 
==org.zkoss.xel.FunctionMapper is simplified==
 
==org.zkoss.xel.FunctionMapper is simplified==
For easy extension<ref>The <tt>getClassNames</tt> and <tt>resolveClass</tt> methods are useful only for special evaluators, such as MVEL and OGNL</ref>, the <tt>getClassNames</tt> and <tt>resolveClass</tt> methods of the <tt>org.zkoss.xel.FunctionMapper</tt> class are removed. On the other hand, <tt>org.zkoss.xel.FunctionMapperExt</tt> was introduced to have these methods. In other words, you'd like to implement any of these methods, you have to implement both <tt>FunctionMapper</tt> and <tt>FunctionMapperExt</tt>.
+
For easy extension<ref>The <code>getClassNames</code> and <code>resolveClass</code> methods are useful only for special evaluators, such as MVEL and OGNL</ref>, the <code>getClassNames</code> and <code>resolveClass</code> methods of the <code>org.zkoss.xel.FunctionMapper</code> class are removed. On the other hand, <code>org.zkoss.xel.FunctionMapperExt</code> was introduced to have these methods. In other words, you'd like to implement any of these methods, you have to implement both <code>FunctionMapper</code> and <code>FunctionMapperExt</code>.
  
 
<blockquote>
 
<blockquote>
Line 74: Line 79:
 
==The selection and opened objects are maintained in model, not UI==
 
==The selection and opened objects are maintained in model, not UI==
  
The selection and opened objects are maintained in model, such as <javadoc type="interface">org.zkoss.zul.ListModel</javadoc> and <javadoc type="interface">org.zkoss.zul.TreeModel</javadoc>. The application shall access the model rather than the component. The component (such as <javadoc>org.zkoss.zul.Listbox</javadoc>) will reflect the change in the model to UI automatically.
+
In ZK 5, we didn't draw a clear line between when to access component and when to access the model. For example, there is no easy way to change the selection in Java<ref>It is also important to note that the selection and other information in the component might not be complete because of render-on-demand. For example, if the first and the last item are both selected, then <javadoc method="getSelectedItems()">org.zkoss.zul.Listbox</javadoc> might return only the first item, since the last item is not loaded and rendered (for sake of better performance). Thus, the application shall access the model where all data are available.</ref>, and two components can't share the same model. To make the code more solid and the spec more flexible, since ZK 6, all information, including selection, opened objects, sorting and multiple selection, shall be maintained in the model, and the application shall only access the model. It is the component's job to update the change of the model to UI, while the implementation of the model has to fire the event to notify the change.
  
Furthermore, if the application invokes <javadoc method="sort(java.util.Comparator, boolean)">org.zkoss.zul.ext.Sortable</javadoc> of the model, the component will be updated to reflect the result automatically. Of course, it also means your implementation has to fire the data change event correctly.
+
For example, the application shall invoke <javadoc type="interface" method="addToSelection(E)">org.zkoss.zul.ext.Selectable</javadoc> (of the model) to add the selection, invoke <javadoc type="interface" method="getSelection()">org.zkoss.zul.ext.Selectable</javadoc> to retrieve the selection, and invoke <javadoc method="sort(java.util.Comparator, boolean)">org.zkoss.zul.ext.Sortable</javadoc> (of the model) to sort the data rather than manipulating the component directly. Of course, it also means your implementation of the model, if any, has to fire the data change event correctly.
  
It is also important to note that the selection and other information in the component might not be complete because of render-on-demand. For example, if the first and the last item are both selected, then <javadoc method="getSelectedItems()">org.zkoss.zul.Listbox</javadoc> might return only the first item, since the last item is not loaded and rendered (for sake of better performance). Thus, the application shall access the model where all data are available.
+
To simplify the upgrading from ZK 5, <javadoc method="setMultiple(boolean)">org.zkoss.zul.Listbox</javadoc> and <javadoc method="setMultiple(boolean)">org.zkoss.zul.Tree</javadoc> can be called and the state will be reflected to the model automatically (of course, changing the <code>multiple</code> state of the model will be reflected to the UI too). However, the calling sequence is important. For example, if your old model doesn't maintain the <code>multiple</code> state, you shall assign model first and then multiple, such as
 +
 
 +
<source lang="xml">
 +
<listbox model="${foo}" multiple="true">
 +
...
 +
</source>
 +
 
 +
<blockquote>
 +
----
 +
<references/>
 +
</blockquote>
  
 
==The selection and open contract between Tree and TreeModel become TreeSelectableModel and TreeOpenableModel==
 
==The selection and open contract between Tree and TreeModel become TreeSelectableModel and TreeOpenableModel==
  
For better performance, <javadoc type="interface">org.zkoss.zul.ext.TreeSelectableModel</javadoc> and <javadoc type="interface">org.zkoss.zul.ext.TreeOpenableModel</javadoc> are introduced to replace <javadoc>org.zkoss.zul.Selectable</javadoc> and <javadoc type="interface">org.zkoss.zul.Openable</javadoc> for maintaining the selection and open objects. In short, they depend on the tree path rather than the data objects.
+
For better performance, <javadoc type="interface">org.zkoss.zul.ext.TreeSelectableModel</javadoc> and <javadoc type="interface">org.zkoss.zul.ext.TreeOpenableModel</javadoc> are introduced to replace <javadoc>org.zkoss.zul.ext.Selectable</javadoc> and <javadoc type="interface">org.zkoss.zul.ext.Openable</javadoc> for maintaining the selection and open objects. In short, they depend on the tree path rather than the data objects.
  
For backward compatibility, <javadoc>org.zkoss.zul.AbstractTreeModel</javadoc> also implements <javadoc>org.zkoss.zul.Selectable</javadoc> and <javadoc>org.zkoss.zul.Openable</javadoc>. Application is free to access it, though ZK doesn't count on them. However, since their contract is based the data objects, <javadoc type="interface" method="getPath(E)">org.zkoss.zul.TreeModel</javadoc> will be called to get the tree path. Thus, make sure your implementation is good if you invoke them a lot.
+
For backward compatibility, <javadoc>org.zkoss.zul.AbstractTreeModel</javadoc> also implements <javadoc>org.zkoss.zul.ext.Selectable</javadoc> and <javadoc>org.zkoss.zul.ext.Openable</javadoc>. Application is free to access it, though ZK doesn't count on them. However, since their contract is based the data objects, <javadoc type="interface" method="getPath(E)">org.zkoss.zul.TreeModel</javadoc> will be called to get the tree path. Thus, make sure your implementation is good if you invoke them a lot.
  
 
==SimpleTreeModel and SimpleTreeNode are removed==
 
==SimpleTreeModel and SimpleTreeNode are removed==
  
The <tt>org.zkoss.zul.SimpleTreeModel</tt> and <tt>org.zkoss.zul.SimpleTreeNode</tt> classes are removed<ref>It was deprecated in ZK 5.0.6.</ref>, and replaced with <javadoc>org.zkoss.zul.DefaultTreeModel</javadoc> and <javadoc>org.zkoss.zul.DefaultTreeNode</javadoc>.
+
The <code>org.zkoss.zul.SimpleTreeModel</code> and <code>org.zkoss.zul.SimpleTreeNode</code> classes are removed<ref>It was deprecated in ZK 5.0.6.</ref>, and replaced with <javadoc>org.zkoss.zul.DefaultTreeModel</javadoc> and <javadoc>org.zkoss.zul.DefaultTreeNode</javadoc>.
  
 
<blockquote>
 
<blockquote>
Line 94: Line 109:
 
<references/>
 
<references/>
 
</blockquote>
 
</blockquote>
 +
 +
==Autowiring of macro components are changed==
 +
 +
The default autowiring of data members in [[ZK Developer's Reference/UI Composing/Macro Component|a macro component]] becomes CSS-selector based. In other words, it is the same approach as <javadoc>org.zkoss.zk.ui.select.SelectorComposer</javadoc> does.
 +
 +
If you want to autowire by name convention feature of macro components (i.e., wiring child components to data members automatically), you can specify the library property called [[ZK Configuration Reference/zk.xml/The Library Properties/org.zkoss.zk.ui.macro.autowire.convention|org.zkoss.zk.ui.macro.autowire.convention]] to <code>true</code> in <code>WEB-INF/zk.xml</code>.
 +
 +
<source lang="xml">
 +
<library-property>
 +
<name>org.zkoss.zk.ui.macro.autowire.convention</name>
 +
  <value>true</value>
 +
<library-property>
 +
</source>
 +
 +
On the other hand, if you prefer to use the CSS-selector approach, you can refer to [[ZK Developer's Reference/MVC/Controller/Wire Components|ZK Developer's Reference: Wire Components]] to upgrade your implementation.
  
 
==The isClose and setClose methods of <javadoc type="interface">org.zkoss.zul.GroupsModel</javadoc> are deprecated==
 
==The isClose and setClose methods of <javadoc type="interface">org.zkoss.zul.GroupsModel</javadoc> are deprecated==
  
To be consistent with the naming of other models, these two methods are replaced with <javadoc type="interface" method="isGroupOpen()">org.zkoss.zul.GroupsModel</javadoc>, <javadoc type="interface" method="addOpenGroup(int)">org.zkoss.zul.GroupsModel</javadoc> and <javadoc type="interface" method="removeOpenGroup(int)">org.zkoss.zul.GroupsModel</javadoc>.
+
To be consistent with the naming of other models, these two methods are replaced with <javadoc type="interface" method="isGroupOpened(int)">org.zkoss.zul.GroupsModel</javadoc>, <javadoc type="interface" method="addOpenGroup(int)">org.zkoss.zul.GroupsModel</javadoc> and <javadoc type="interface" method="removeOpenGroup(int)">org.zkoss.zul.GroupsModel</javadoc>.
  
 
==GenericForwardComposer and GenericAutowireComposer won't wire variables defined in zscript and variable resolvers==
 
==GenericForwardComposer and GenericAutowireComposer won't wire variables defined in zscript and variable resolvers==
  
For sake of better performance, <tt>org.zkoss.zk.ui.util.GenericForwardComposer</tt> and <tt>org.zkoss.zk.ui.util.GenericAutowireComposer</tt> won't wire variables defined in zscript and variable resolvers. If you prefer to write them as ZK 5 and earlier  does, you could specify the library properties called <tt>org.zkoss.zk.ui.composer.autowire.zscript</tt> and <tt>org.zkoss.zk.ui.composer.autowire.xel</tt> to <tt>true</tt>.
+
For sake of better performance, <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc> and <javadoc>org.zkoss.zk.ui.util.GenericAutowireComposer</javadoc> won't wire variables defined in zscript and variable resolvers. If you prefer to write them as ZK 5 and earlier  does, you could specify the library properties called [[ZK Configuration Reference/zk.xml/The Library Properties/org.zkoss.zk.ui.composer.autowire.zscript|org.zkoss.zk.ui.composer.autowire.zscript]] and [[ZK Configuration Reference/zk.xml/The Library Properties/org.zkoss.zk.ui.composer.autowire.xel|org.zkoss.zk.ui.composer.autowire.xel]] to <code>true</code>.
  
 
==API returns Iterable instead Iterator==
 
==API returns Iterable instead Iterator==
  
To use with Java 5's for statement, the return type of the following APIs are changed to <tt>java.lang.Iterable</tt>:
+
To use with Java 5's for statement, the return type of the following APIs are changed to <code>java.lang.Iterable</code>:
  
* <tt>org.zkoss.zk.ui.Exectuion</tt>: <tt>getHeaders</tt> and <tt>getHeaderNames</tt>
+
* <javadoc type="interface">org.zkoss.zk.ui.Execution</javadoc>: <code>getHeaders</code> and <code>getHeaderNames</code>
* <tt>org.zkoss.zk.ui.WebApp</tt>: <tt>getInitParameterNames</tt>
+
* <javadoc type="interface">org.zkoss.zk.ui.WebApp</javadoc>: <code>getInitParameterNames</code>
* <tt>org.zkoss.zk.ui.RichletConfig</tt>: <tt>getInitParameterNames</tt>
+
* <javadoc type="interface">org.zkoss.zk.ui.RichletConfig</javadoc>: <code>getInitParameterNames</code>
  
 
==Window, Messagebox and Fileupload won't throw InterruptedException==
 
==Window, Messagebox and Fileupload won't throw InterruptedException==
  
<tt>Window</tt>, <tt>Messagebox</tt> and <tt>Fileupload</tt> won't throw <tt>java.lang.InterruptedException</tt> anymore, since it won't happen if the event processing thread is disabled (default). If the event processing thread is enabled, <tt>InterruptedException</tt> will be wrapped with <javadoc>org.zkoss.zk.ui.UiException</javadoc>.
+
<javadoc>org.zkoss.zul.Window</javadoc>, <javadoc>org.zkoss.zul.Messagebox</javadoc> and <javadoc>org.zkoss.zul.Fileupload</javadoc> won't throw <code>java.lang.InterruptedException</code> anymore, since it won't happen if the event processing thread is disabled (default). If the event processing thread is enabled, <code>InterruptedException</code> will be wrapped with <javadoc>org.zkoss.zk.ui.UiException</javadoc>.
  
 
==addEventListener allows the same listener registered multiple times==
 
==addEventListener allows the same listener registered multiple times==
  
Component's <tt>addEventListener</tt> now allows the same listener being registered multiple times, and the listener will be called multiple times.
+
Component's <code>addEventListener</code> now allows the same listener being registered multiple times, and the listener will be called multiple times.
  
If you prefer to ignore the second registration of the same listener (i.e., backward compatible with ZK 5 and earlier), you could specify a library property called <tt>org.zkoss.zk.ui.EventListener.duplicateIgnored</tt> to <tt>true</tt> in <tt>WEB-INF/zk.xml</tt>.
+
If you prefer to ignore the second registration of the same listener (i.e., backward compatible with ZK 5 and earlier), you could specify a library property called <code>org.zkoss.zk.ui.EventListener.duplicateIgnored</code> to <code>true</code> in <code>WEB-INF/zk.xml</code>.
  
 
==The return type of <javadoc method="getAttributes()" type="interface">org.zkoss.zk.ui.metainfo.Annotation</javadoc> is changed==
 
==The return type of <javadoc method="getAttributes()" type="interface">org.zkoss.zk.ui.metainfo.Annotation</javadoc> is changed==
Line 127: Line 157:
 
==UiFactory's newComponent is changed==
 
==UiFactory's newComponent is changed==
  
The <tt>newComponent</tt> method of the <tt>org.zkoss.zk.ui.sys.UiFactory</tt> is changed. In additions, two new methods <tt>newComposer</tt> and <tt>newServerPush</tt> were introduced to allow developers have more control of the instantiations.
+
The <code>newComponent</code> method of the <javadoc type="interface">org.zkoss.zk.ui.sys.UiFactory</javadoc> is changed. In additions, two new methods <code>newComposer</code> and <code>newServerPush</code> were introduced to allow developers have more control of the instantiations.
  
 
==The support of Comet is available in PE==
 
==The support of Comet is available in PE==
  
The support of Comet is available in ZK PE, while ZK EE supports Servlet 3 Asynchronous Processing-based Comet.
+
The support of [http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Server_Push/Configuration Comet] is available in ZK PE, while ZK EE supports [http://books.zkoss.org/wiki/Small_Talks/2012/February/New_Features_of_ZK_6#ZK_Comet_supports_Servlet_3_Asynchronous_Processing Servlet 3 Asynchronous Processing-based Comet].
  
 
==Component's newChildren and newExtraCtrl are removed==
 
==Component's newChildren and newExtraCtrl are removed==
  
The <tt>newChildren</tt> and <tt>newExtraCtrl</tt> methods of <javadoc>org.zkoss.zk.ui.AbstractComponent</javadoc> are removed since they are redundant. Please override the <tt>getChildren</tt> and <tt>getExtraCtrl</tt> instead.
+
The <code>newChildren</code> and <code>newExtraCtrl</code> methods of <javadoc>org.zkoss.zk.ui.AbstractComponent</javadoc> are removed since they are redundant. Please override the <code>getChildren</code> and <code>getExtraCtrl</code> instead.
  
 
==Component's setVariable is removed==
 
==Component's setVariable is removed==
  
Component's <tt>setVariable</tt> method is removed<ref>It was deprecated in ZK 5, since we don't maintain a separate namespace for each ID space.</ref>. Please use <tt>Component.setAttribute(name, value, SPACE_SCOPE)</tt> instead. In other words, you could store the variables in the attributes of the space owner (<javadoc method="getSpaceOwner()">org.zkoss.zk.ui.Component</javadoc>).
+
Component's <code>setVariable</code> method is removed<ref>It was deprecated in ZK 5, since we don't maintain a separate namespace for each ID space.</ref>. Please use <code>Component.setAttribute(name, value, SPACE_SCOPE)</code> instead. In other words, you could store the variables in the attributes of the space owner (<javadoc method="getSpaceOwner()">org.zkoss.zk.ui.Component</javadoc>).
  
 
<blockquote>
 
<blockquote>
Line 148: Line 178:
 
==ListX, TreeArray and CheckableTreeArray are removed==
 
==ListX, TreeArray and CheckableTreeArray are removed==
  
The <tt>org.zkoss.util.ListX</tt>, <tt>org.zkoss.util.TreeArray</tt> and <tt>org.zkoss.util.CheckableTreeArray</tt> are removed. Please use <tt>java.util.LinkedList</tt> or <tt>java.util.ArrayList</tt> instead.
+
The <code>org.zkoss.util.ListX</code>, <code>org.zkoss.util.TreeArray</code> and <code>org.zkoss.util.CheckableTreeArray</code> are removed. Please use <code>java.util.LinkedList</code> or <code>java.util.ArrayList</code> instead.
 +
 
 +
If you need them, please copy the code from [https://github.com/zkoss/zk/tree/5.0 ZK 5's Git repository].
  
 
==ClassWebServlet and several other never-used classes are removed==
 
==ClassWebServlet and several other never-used classes are removed==
Line 166: Line 198:
 
==ListModelExt, TreeModelExt and GroupsModelExt are deprecated==
 
==ListModelExt, TreeModelExt and GroupsModelExt are deprecated==
  
The <tt>org.zkoss.zul.ListModelExt</tt> and <tt>org.zkoss.zul.TreeModelExt</tt> interface are deprecated, and replaced with <javadoc type="interface">org.zkoss.zul.ext.Sortable</javadoc>. Also, <tt>org.zkoss.zul.GroupsModelExt</tt> is deprecated and replaced with <javadoc type="interface">org.zkoss.zul.ext.GroupsSortableModel</javadoc>.
+
The <code>org.zkoss.zul.ListModelExt</code> and <code>org.zkoss.zul.TreeModelExt</code> interface are deprecated, and replaced with <javadoc type="interface">org.zkoss.zul.ext.Sortable</javadoc>. Also, <code>org.zkoss.zul.GroupsModelExt</code> is deprecated and replaced with <javadoc type="interface">org.zkoss.zul.ext.GroupsSortableModel</javadoc>.
  
 
==org.zkoss.zk.ui.event.Express is deprecated==
 
==org.zkoss.zk.ui.event.Express is deprecated==
  
The <tt>org.zkoss.zk.ui.event.Express</tt> interface is deprecated. Please use the <javadoc method="addEventListener(int, String, EventListener)" type="interface">org.zkoss.zk.ui.Component</javadoc> instead, and assign the priority as 1000.
+
The <code>org.zkoss.zk.ui.event.Express</code> interface is deprecated. Please use the <javadoc method="addEventListener(int, java.lang.String, org.zkoss.zk.ui.event.EventListener)" type="interface">org.zkoss.zk.ui.Component</javadoc> instead, and assign the priority as 1000.
  
 
==HTMLs, StyleSheet and JavaScript are moved==
 
==HTMLs, StyleSheet and JavaScript are moved==
  
The <tt>HTMLs</tt>, <tt>StyleSheet</tt> and <tt>JavaScript</tt> classes are moved to the package called <tt>org.zkoss.html</tt>.
+
The <code>HTMLs</code>, <code>StyleSheet</code> and <code>JavaScript</code> classes are moved to the package called <code>org.zkoss.html</code>.
  
Notice the previous classes are still available but deprecated (not found in JavaDoc).
+
Notice the previous classes are still available but deprecated (and not found in JavaDoc).
  
 
=Theme and UI=
 
=Theme and UI=
Line 182: Line 214:
 
==Breeze is the default theme==
 
==Breeze is the default theme==
  
The breeze theme has become the default styling, without the need to include <tt>breeze.jar</tt>. Please make sure you remove <tt>breeze.jar</tt> from your project. On the other hand, the sapphire and silvertail themes are packaged and delivered as they were in ZK 5. Of course, you have to upgrade to the version shipped with ZK 6's binary distribution.
+
The breeze theme has become the default styling, without the need to include <code>breeze.jar</code>. Please make sure you remove <code>breeze.jar</code> from your project. On the other hand, the sapphire and silvertail themes are packaged and delivered as they were in ZK 5. Of course, you have to upgrade to the version shipped with ZK 6's binary distribution.
  
 
==Tablechildren and Columnchidlren support any child==
 
==Tablechildren and Columnchidlren support any child==
Line 190: Line 222:
 
==Groupbox's zclass is renamed to z-groupbox==
 
==Groupbox's zclass is renamed to z-groupbox==
  
To be consistent, the zclass  of Groupbox's default mold is renamed to <tt>z-groupbox</tt>(it was called <tt>z-fieldset</tt> in ZK 5). The zclass of the 3d mold is renamed to <tt>z-groupbox-3d</tt> (it was called <tt>z-groupbox</tt>).
+
To be consistent, the zclass  of Groupbox's default mold is renamed to <code>z-groupbox</code>(it was called <code>z-fieldset</code> in ZK 5). The zclass of the 3d mold is renamed to <code>z-groupbox-3d</code> (it was called <code>z-groupbox</code>).
  
 
==The z-class names of menuitem, menupopup, menuseparator and panelchlidren are changed==
 
==The z-class names of menuitem, menupopup, menuseparator and panelchlidren are changed==
Line 196: Line 228:
 
To be consistent with other naming, we rename their z-class name as follows. Please update your CSS file if you ever override them.
 
To be consistent with other naming, we rename their z-class name as follows. Please update your CSS file if you ever override them.
  
* <tt>z-menu-item -> z-menuitem</tt>
+
* <code>z-menu-item -> z-menuitem</code>
* <tt>z-menu-popup -> z-menupopup</tt>
+
* <code>z-menu-popup -> z-menupopup</code>
* <tt>z-menu-separator -> z-menuseparator</tt>
+
* <code>z-menu-separator -> z-menuseparator</code>
* <tt>z-panel-children -> z-panelchildren</tt>
+
* <code>z-panel-children -> z-panelchildren</code>
  
 
==Some nested CSS class names of calendar are changed==
 
==Some nested CSS class names of calendar are changed==
Line 205: Line 237:
 
To avoid confusion with other components, the CSS class names must follow the same rule: <code><i>z-class</i>-xxxx</code>. We fix calendar to follow this rule. Please update your CSS file if you ever override them.
 
To avoid confusion with other components, the CSS class names must follow the same rule: <code><i>z-class</i>-xxxx</code>. We fix calendar to follow this rule. Please update your CSS file if you ever override them.
  
* <tt>.z-weekend -> .z-calendar-caldow .z-calendar-wkend</tt>
+
* <code>.z-weekend -> .z-calendar-caldow .z-calendar-wkend</code>
* <tt>.z-weekday -> .z-calendar-caldow .z-calendar-wkday</tt>
+
* <code>.z-weekday -> .z-calendar-caldow .z-calendar-wkday</code>
* <tt>.z-outside -> .z-calendar-outside</tt>
+
* <code>.z-outside -> .z-calendar-outside</code>
  
 
==The vflex and hflex of Panelchildren are deprecated==
 
==The vflex and hflex of Panelchildren are deprecated==
The hflex/vflex properties of Panelchildren are determined by its parent Panel's hflex/vflex properties. The <tt>setHflex</tt> and <tt>setVflex</tt> methods of Panelchildren will throw UnsupportedOperationException. In other words, you shall control Panel rather than Panelchildren.
+
The hflex/vflex properties of Panelchildren are determined by its parent Panel's hflex/vflex properties. The <code>setHflex</code> and <code>setVflex</code> methods of Panelchildren will throw UnsupportedOperationException. In other words, you shall control Panel rather than Panelchildren.
  
 
==The hflex and width of Treerow,  Rows... is deprecated==
 
==The hflex and width of Treerow,  Rows... is deprecated==
As the sizing of Grid/Listbox/Tree are controlled by Grid/Listbox/Tree and the header components (such as Treecol, Listheader and Column). By others, the hflex and width properties of them are irrelevant. Their <tt>setHflex</tt> and <tt>setWidth</tt> methods are deprecated. These components include:
+
As the sizing of Grid/Listbox/Tree are controlled by Grid/Listbox/Tree and the header components (such as Treecol, Listheader and Column). By others, the hflex and width properties of them are irrelevant. Their <code>setHflex</code> and <code>setWidth</code> methods are deprecated. These components include:
 
Treeitem, Treerow, Treecell, Treechildren, Treecols, Treefoot, Rows, Columns, Row, Cell, Foot, Listitem, Listcell, Listhead, Listfoot.
 
Treeitem, Treerow, Treecell, Treechildren, Treecols, Treefoot, Rows, Columns, Row, Cell, Foot, Listitem, Listcell, Listhead, Listfoot.
  
 
==Messagebox's template is changed==
 
==Messagebox's template is changed==
  
Messagebox's template (i.e., <tt>~./zul/html/messagebox.zul</tt>) is changed to support the new features such as reordering and custom labels. If you ever customized it, please refer to [https://github.com/zkoss/zk/blob/6.0/zul/src/archive/web/zul/html/messagebox.zul the source code] for the details.
+
Messagebox's template (i.e., <code>~./zul/html/messagebox.zul</code>) is changed to support the new features such as reordering and custom labels. If you ever customized it, please refer to [https://github.com/zkoss/zk/blob/6.0/zul/src/archive/web/zul/html/messagebox.zul the source code] for the details.
  
 
==iZUML uses #{...} to represent an expression==
 
==iZUML uses #{...} to represent an expression==
  
The format of the expression used in iZUML (client-side ZUML) has become <tt>#{...}</tt>, such that it is easier to embed in a ZUML page where <tt>${...}</tt> is used. In additions, iZUML is supported by ZK CE since ZK 6.
+
The format of the expression used in iZUML (client-side ZUML) has become <code>#{...}</code>, such that it is easier to embed in a ZUML page where <code>${...}</code> is used. In additions, iZUML is supported by ZK CE since ZK 6.
  
 
==The library property called org.zkoss.zul.Separator.spaceWithMargin is removed==
 
==The library property called org.zkoss.zul.Separator.spaceWithMargin is removed==
Line 232: Line 264:
 
==Use ZK Bind instead of old data binding==
 
==Use ZK Bind instead of old data binding==
  
ZK Bind (<tt>org.zkoss.bind.*</tt>) is our new generation of data binding. It is more powerful and controllable, though the first version of data binding (<tt>org.zkoss.zkplus.databind.*</tt>) is still maintained. For more information, please refer to [[Small Talks/2011/October/Envisage ZK 6: The Next Generation Data Binding System|Envisage ZK 6: The Next Generation Data Binding System]].
+
ZK Bind (<code>org.zkoss.bind.*</code>) is our new generation of data binding. It is more powerful and controllable, though the first version of data binding (<code>org.zkoss.zkplus.databind.*</code>) is still maintained. For more information, please refer to [[Small Talks/2011/October/Envisage ZK 6: The Next Generation Data Binding System|Envisage ZK 6: The Next Generation Data Binding System]] and [[ZK Developer's Reference/MVVM/Data Binding|ZK Developer's Reference: Data Binding]].
  
Notice that ZK Bind supports both data binding and MVVM. Data binding, as you are already familiar with, minimizes the effort to access database, while [[Small Talks/2011/November/Hello ZK MVVM|MVVM]] introduces additional abstract layer isolating the view dependence from the controller.
+
Notice that ZK Bind supports both data binding and MVVM. Data binding, as you are already familiar with, minimizes the effort to access database, while [[ZK Developer's Reference/MVVM|MVVM]] introduces additional abstract layer isolating the view dependence from the controller.
  
 
==Use SelectorComposer instead of GenericForwardComposer==
 
==Use SelectorComposer instead of GenericForwardComposer==
  
 
The <javadoc>org.zkoss.zk.ui.select.SelectorComposer</javadoc> class provides more control how to wire the members. It is generally recommended. Of course, some might find <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>'s wire-by-convention is more convenient to use, and it is still supported.
 
The <javadoc>org.zkoss.zk.ui.select.SelectorComposer</javadoc> class provides more control how to wire the members. It is generally recommended. Of course, some might find <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>'s wire-by-convention is more convenient to use, and it is still supported.
 +
 +
=ZK Bind Since 6.0.2=
 +
==Accessing children and custom attribute in @Init method is no longer supported==
 +
The invocation of current @Init tagged method in VM class is moved from BindComposer's doAfterCompose to earlier stage doBeforeComposeChildren, which means it's no longer applicable if you want to initiate your VM based on host component scope (ex: child components and custom attributes) in an @Init tagged method.
 +
Instead you should use @AfterCompose tagged method which is newly introduced since this version.
 +
 +
==AnnotateBinder API definition change==
 +
Since 6.0.2, compare to old AnnotateBinder#init() current  AnnotateBinder#init() will only take care of  super#init(), you'll have to call AnnotateBinder#initAnnotatedBindings() separately  to initiate and register Bindings based on Zul component's annotation.
  
 
{{Template:CommentedSmalltalk_Footer|
 
{{Template:CommentedSmalltalk_Footer|
 
|name=Potix Corporation
 
|name=Potix Corporation
 
}}
 
}}

Latest revision as of 04:19, 20 January 2022

ZK 6: Upgrade Notes

Author
ZK Team, Potix Corporation
Date
February 14, 2012
Version
ZK 6

Overview

In additions to new features, ZK 6 also cleans up some API that are confusing, redundant or over complicated. The effort to upgrade depends on what features your application uses. Many of them shall run without modification. It is suggested to re-compile the applications and replace the code that use the deprecated API.

The must-do upgrade steps

First, you have to upgrade the following addons if you ever use them:

  • zel.jar replaces zcommons-el.jar to support EL 2.2. It is shipped with ZK's binary distribution, so just copy it from the dist/lib folder.[1]. Though optional, it is suggested to remove zcommons-el.jar.
  • ZK JSP 2.0 or later. Download here.
  • ZK Calendar 2.1.1 or later. Download here.
  • ZK CKeditor 3.6.0.1 or later. It is shipped with ZK's binary distribution, so just copy it from the dist/lib/zkforge folder.

Second, you have to remove breeze.jar since breeze has become the standard theme. Without removing the old breeze.jar, it might cause some CSS conflicts.

Third, search if you implemented any renderer in zscript, such as ListitemRenderer, RowRenderer and TreeitemRenderer[2]. If so, please refer to this section for how to fix them.

Fourth, If you ever use the autowiring feature of macro components (i.e., wiring child components to data members automatically), please refer to this section for how to fix it.

Finally, clean and compile your project. If there is a compile error, please check the corresponding section below. On the other hand, it is OK to ignore the warnings of deprecation and generic-type checks, though it is a good idea to fix them too.


  1. If you prefer EL 1.1 (i.e., backward compatible with ZK 5), please remove zel.jar and copy zcommons-el.jar to your project instead. Notice that ZK Bind (our new generation of data binding) utilizes EL 2.2 to support two-way binding, so don't use zcommons-el.jar if you want to use the new data binding.
  2. If you implement them in pure Java, the compiler will identify the errors for you.

API that are changed

org.zkoss.zk.zul.api.* are removed

The component's API interfaces (org.zkoss.zk.ui.api.*, org.zkoss.zul.api.*...) are removed[1]. Please replace them with the concrete classes. For example, use org.zkoss.zul.Window instead of org.zkoss.zul.api.Window.

You could use the search-and-replace or refactor feature in your IDE to replace the package name. Here is an example that uses Eclipse to replace the package name.


  1. The reason to remove them is they cause more confusion than the abstraction benefit. In additions, they are costly and error-prone to maintain.

The render method of ListitemRender, RowRender, TreeitemRender and ComboitemRender are changed

For sake of performance and consistency, the render method of ListitemRenderer, RowRenderer, ComboitemRenderer, TreeitemRenderer are changed. An additional argument called index was introduced. You can use it instead of accessing the component's index (such as Listitem.getIndex() for better performance.

Notice that while Java compiler will detect the changes automatically, you have to maintain zscript manually if you have implemented them in zscript.

addSelection/removeSelection methods of Selectable are changed

For ease of understanding, addSelection method of Selectable has been changed to addToSelection(), while removeSelection method of Selectable has been changed to removeFromSelection().

org.zkoss.zk.ui.util.Initiator is simplified

For easy extension and better consistency[1], the Initiator class now has only one method called doInit. The doAfterComposer, doCatch and doFinally methods are moved to InitiatorExt. In other words, if you'd like to override any of these methods, your initiator has to implement both Initiator and InitiatorExt.


  1. Most initiators need to override the doInit method, and it is consistent with Composer.

org.zkoss.xel.FunctionMapper is simplified

For easy extension[1], the getClassNames and resolveClass methods of the org.zkoss.xel.FunctionMapper class are removed. On the other hand, org.zkoss.xel.FunctionMapperExt was introduced to have these methods. In other words, you'd like to implement any of these methods, you have to implement both FunctionMapper and FunctionMapperExt.


  1. The getClassNames and resolveClass methods are useful only for special evaluators, such as MVEL and OGNL

i3-label.properties is renamed to zk-label.properties

To avoid confusion, the default properties file for the internationalization labels is renamed to zk-label.properties[1].


  1. For backward compatibility, i3-label.properties will be loaded if zk-label.properties is not found.

The selection and opened objects are maintained in model, not UI

In ZK 5, we didn't draw a clear line between when to access component and when to access the model. For example, there is no easy way to change the selection in Java[1], and two components can't share the same model. To make the code more solid and the spec more flexible, since ZK 6, all information, including selection, opened objects, sorting and multiple selection, shall be maintained in the model, and the application shall only access the model. It is the component's job to update the change of the model to UI, while the implementation of the model has to fire the event to notify the change.

For example, the application shall invoke Selectable.addToSelection(E) (of the model) to add the selection, invoke Selectable.getSelection() to retrieve the selection, and invoke Sortable.sort(Comparator, boolean) (of the model) to sort the data rather than manipulating the component directly. Of course, it also means your implementation of the model, if any, has to fire the data change event correctly.

To simplify the upgrading from ZK 5, Listbox.setMultiple(boolean) and Tree.setMultiple(boolean) can be called and the state will be reflected to the model automatically (of course, changing the multiple state of the model will be reflected to the UI too). However, the calling sequence is important. For example, if your old model doesn't maintain the multiple state, you shall assign model first and then multiple, such as

<listbox model="${foo}" multiple="true">
...

  1. It is also important to note that the selection and other information in the component might not be complete because of render-on-demand. For example, if the first and the last item are both selected, then Listbox.getSelectedItems() might return only the first item, since the last item is not loaded and rendered (for sake of better performance). Thus, the application shall access the model where all data are available.

The selection and open contract between Tree and TreeModel become TreeSelectableModel and TreeOpenableModel

For better performance, TreeSelectableModel and TreeOpenableModel are introduced to replace Selectable and Openable for maintaining the selection and open objects. In short, they depend on the tree path rather than the data objects.

For backward compatibility, AbstractTreeModel also implements Selectable and Openable. Application is free to access it, though ZK doesn't count on them. However, since their contract is based the data objects, TreeModel.getPath(E) will be called to get the tree path. Thus, make sure your implementation is good if you invoke them a lot.

SimpleTreeModel and SimpleTreeNode are removed

The org.zkoss.zul.SimpleTreeModel and org.zkoss.zul.SimpleTreeNode classes are removed[1], and replaced with DefaultTreeModel and DefaultTreeNode.


  1. It was deprecated in ZK 5.0.6.

Autowiring of macro components are changed

The default autowiring of data members in a macro component becomes CSS-selector based. In other words, it is the same approach as SelectorComposer does.

If you want to autowire by name convention feature of macro components (i.e., wiring child components to data members automatically), you can specify the library property called org.zkoss.zk.ui.macro.autowire.convention to true in WEB-INF/zk.xml.

<library-property>
 <name>org.zkoss.zk.ui.macro.autowire.convention</name>
  <value>true</value>
<library-property>

On the other hand, if you prefer to use the CSS-selector approach, you can refer to ZK Developer's Reference: Wire Components to upgrade your implementation.

The isClose and setClose methods of GroupsModel are deprecated

To be consistent with the naming of other models, these two methods are replaced with GroupsModel.isGroupOpened(int), GroupsModel.addOpenGroup(int) and GroupsModel.removeOpenGroup(int).

GenericForwardComposer and GenericAutowireComposer won't wire variables defined in zscript and variable resolvers

For sake of better performance, GenericForwardComposer and GenericAutowireComposer won't wire variables defined in zscript and variable resolvers. If you prefer to write them as ZK 5 and earlier does, you could specify the library properties called org.zkoss.zk.ui.composer.autowire.zscript and org.zkoss.zk.ui.composer.autowire.xel to true.

API returns Iterable instead Iterator

To use with Java 5's for statement, the return type of the following APIs are changed to java.lang.Iterable:

Window, Messagebox and Fileupload won't throw InterruptedException

Window, Messagebox and Fileupload won't throw java.lang.InterruptedException anymore, since it won't happen if the event processing thread is disabled (default). If the event processing thread is enabled, InterruptedException will be wrapped with UiException.

addEventListener allows the same listener registered multiple times

Component's addEventListener now allows the same listener being registered multiple times, and the listener will be called multiple times.

If you prefer to ignore the second registration of the same listener (i.e., backward compatible with ZK 5 and earlier), you could specify a library property called org.zkoss.zk.ui.EventListener.duplicateIgnored to true in WEB-INF/zk.xml.

The return type of Annotation.getAttributes() is changed

The return type is changed from Map<String, String> to Map<String, String[]>, since the annotation now allows multiple values per attribute.

UiFactory's newComponent is changed

The newComponent method of the UiFactory is changed. In additions, two new methods newComposer and newServerPush were introduced to allow developers have more control of the instantiations.

The support of Comet is available in PE

The support of Comet is available in ZK PE, while ZK EE supports Servlet 3 Asynchronous Processing-based Comet.

Component's newChildren and newExtraCtrl are removed

The newChildren and newExtraCtrl methods of AbstractComponent are removed since they are redundant. Please override the getChildren and getExtraCtrl instead.

Component's setVariable is removed

Component's setVariable method is removed[1]. Please use Component.setAttribute(name, value, SPACE_SCOPE) instead. In other words, you could store the variables in the attributes of the space owner (Component.getSpaceOwner()).


  1. It was deprecated in ZK 5, since we don't maintain a separate namespace for each ID space.

ListX, TreeArray and CheckableTreeArray are removed

The org.zkoss.util.ListX, org.zkoss.util.TreeArray and org.zkoss.util.CheckableTreeArray are removed. Please use java.util.LinkedList or java.util.ArrayList instead.

If you need them, please copy the code from ZK 5's Git repository.

ClassWebServlet and several other never-used classes are removed

The following classes are removed, since they are never used and introduce unnecessary complication to API:

org.zkoss.web.util.resource.ClassWebServlet, org.zkoss.web.servlet.ForwardServlet, org.zkoss.web.servlet.http.HttpServlet, org.zkoss.io.PrintWriterX, org.zkoss.io.FileWatchdog, org.zkoss.media.Photo, org.zkoss.lang.WarningException, org.zkoss.lang.Warning, org.zkoss.util.InvalidValueException, org.zkoss.util.ModificationException, org.zkoss.util.ScalableTimer, org.zkoss.util.ScalableTimerTask, org.zkoss.util.ScalableTimerTask, org.zkoss.util.ThreadLocalCache

If you need them, please copy the code from ZK 5's Git repository.

The configuration of logging is changed

ZK core's logging is still based on Java standard logging. However, the configuration is simplified and changed. Please refer to ZK Developer's Reference: Logger if you need it.

API that are deprecated

ListModelExt, TreeModelExt and GroupsModelExt are deprecated

The org.zkoss.zul.ListModelExt and org.zkoss.zul.TreeModelExt interface are deprecated, and replaced with Sortable. Also, org.zkoss.zul.GroupsModelExt is deprecated and replaced with GroupsSortableModel.

org.zkoss.zk.ui.event.Express is deprecated

The org.zkoss.zk.ui.event.Express interface is deprecated. Please use the Component.addEventListener(int, String, EventListener) instead, and assign the priority as 1000.

HTMLs, StyleSheet and JavaScript are moved

The HTMLs, StyleSheet and JavaScript classes are moved to the package called org.zkoss.html.

Notice the previous classes are still available but deprecated (and not found in JavaDoc).

Theme and UI

Breeze is the default theme

The breeze theme has become the default styling, without the need to include breeze.jar. Please make sure you remove breeze.jar from your project. On the other hand, the sapphire and silvertail themes are packaged and delivered as they were in ZK 5. Of course, you have to upgrade to the version shipped with ZK 6's binary distribution.

Tablechildren and Columnchidlren support any child

Tablechildren and Columnchildren support any kind of child components, not limited to Panel. Thus, if you don't need the feature of Panel, you could remove it from your UI to make the layout structure simpler.

Groupbox's zclass is renamed to z-groupbox

To be consistent, the zclass of Groupbox's default mold is renamed to z-groupbox(it was called z-fieldset in ZK 5). The zclass of the 3d mold is renamed to z-groupbox-3d (it was called z-groupbox).

The z-class names of menuitem, menupopup, menuseparator and panelchlidren are changed

To be consistent with other naming, we rename their z-class name as follows. Please update your CSS file if you ever override them.

  • z-menu-item -> z-menuitem
  • z-menu-popup -> z-menupopup
  • z-menu-separator -> z-menuseparator
  • z-panel-children -> z-panelchildren

Some nested CSS class names of calendar are changed

To avoid confusion with other components, the CSS class names must follow the same rule: z-class-xxxx. We fix calendar to follow this rule. Please update your CSS file if you ever override them.

  • .z-weekend -> .z-calendar-caldow .z-calendar-wkend
  • .z-weekday -> .z-calendar-caldow .z-calendar-wkday
  • .z-outside -> .z-calendar-outside

The vflex and hflex of Panelchildren are deprecated

The hflex/vflex properties of Panelchildren are determined by its parent Panel's hflex/vflex properties. The setHflex and setVflex methods of Panelchildren will throw UnsupportedOperationException. In other words, you shall control Panel rather than Panelchildren.

The hflex and width of Treerow, Rows... is deprecated

As the sizing of Grid/Listbox/Tree are controlled by Grid/Listbox/Tree and the header components (such as Treecol, Listheader and Column). By others, the hflex and width properties of them are irrelevant. Their setHflex and setWidth methods are deprecated. These components include: Treeitem, Treerow, Treecell, Treechildren, Treecols, Treefoot, Rows, Columns, Row, Cell, Foot, Listitem, Listcell, Listhead, Listfoot.

Messagebox's template is changed

Messagebox's template (i.e., ~./zul/html/messagebox.zul) is changed to support the new features such as reordering and custom labels. If you ever customized it, please refer to the source code for the details.

iZUML uses #{...} to represent an expression

The format of the expression used in iZUML (client-side ZUML) has become #{...}, such that it is easier to embed in a ZUML page where ${...} is used. In additions, iZUML is supported by ZK CE since ZK 6.

The library property called org.zkoss.zul.Separator.spaceWithMargin is removed

We don't support the margin approach found in ZK 2 any more.

Optional but suggested

Use ZK Bind instead of old data binding

ZK Bind (org.zkoss.bind.*) is our new generation of data binding. It is more powerful and controllable, though the first version of data binding (org.zkoss.zkplus.databind.*) is still maintained. For more information, please refer to Envisage ZK 6: The Next Generation Data Binding System and ZK Developer's Reference: Data Binding.

Notice that ZK Bind supports both data binding and MVVM. Data binding, as you are already familiar with, minimizes the effort to access database, while MVVM introduces additional abstract layer isolating the view dependence from the controller.

Use SelectorComposer instead of GenericForwardComposer

The SelectorComposer class provides more control how to wire the members. It is generally recommended. Of course, some might find GenericForwardComposer's wire-by-convention is more convenient to use, and it is still supported.

ZK Bind Since 6.0.2

Accessing children and custom attribute in @Init method is no longer supported

The invocation of current @Init tagged method in VM class is moved from BindComposer's doAfterCompose to earlier stage doBeforeComposeChildren, which means it's no longer applicable if you want to initiate your VM based on host component scope (ex: child components and custom attributes) in an @Init tagged method. Instead you should use @AfterCompose tagged method which is newly introduced since this version.

AnnotateBinder API definition change

Since 6.0.2, compare to old AnnotateBinder#init() current AnnotateBinder#init() will only take care of super#init(), you'll have to call AnnotateBinder#initAnnotatedBindings() separately to initiate and register Bindings based on Zul component's annotation.


Comments



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