1. IntelliJ has surpassed Eclipse as the preferred IDE among ZK users.
2. While some have migrated to Jakarta EE, half of our users remain loyal to Java EE.
3. Maven reigns as the top build tool, with Gradle not meeting anticipated popularity.
4. 80% of users rely on JUnit for app testing.
5. Baeldung emerges as the go-to learning hub for developers.
6. Stack Overflow and the ZK Forum are key resources for problem-solving.
7. AI integration remains low, with less than 10% of users adopting it.

We hope these insights provide valuable context for your work and access to useful resources.

If you have submitted a contact request when filling out the survey, we will reach out to you soon, thank you for your patience!

Unlike most tools that require reverting to 2D/tabular data before conducting detailed analyses, Ottava empowers users to directly input, explore, and derive insights from multi-dimesional reports. This distinctive capability streamlines the analytical process, saving valuable time and providing users with a seamless experience.

Ottava seamlessly combines our expertise in Web development (ZK), Spreadsheet technology (Keikai), and SaaS solutions (Quire). This platform simplifies data management, chart creation, and analysis, bridging the gap between user requirements and complex data tools. We invite you to explore Ottava firsthand and share your invaluable feedback.

Get started at ottava.io >>

Learn more about Why we created Ottava.

If you have questions or feedback or would like to schedule a personalized demo, feel free to reach us at feedback@ottava.io.

Now, ZK Charts 11 will be available soon, upgrading the underlying Highcharts library to the latest version 11.2.0. This will bring in new chart types and a refreshing look & feel.

Highlights

• Upgrade underlying Highcharts from 10.3.3 to 11.2.0
• New Pictorial Chart
• New Audio Chart
• New look & feel

Other fixes and features

• Over 70 bugs fixed
• Dropped IE8 support
• For more information, please look at highcharts’ change log.

While we are testing the new version, we would like to invite everyone to try out the ZK Charts 11.2.0.0 freshly-release, to make sure that it also works well in your project.

To try out ZK Charts 11, use the evaluation repository: https://mavensync.zkoss.org/eval/ and specify the zk charts version number as 11.2.0.0-FL-20231106-Eval (or later).

Please let us know how it works for you. If you run into any issues, let us know early so we can get them addressed before the official release. Thanks and we look forward to hearing from you!

To facilitate a smooth transition to Client MVVM, ZK Team has developed ZK Client MVVM Linter — a tool specifically designed for identifying potential compatibility issues in Server MVVM files before upgrading. In this blog post, we will guide you through the entire process of setting up and running the linter, covering everything from basic configuration to advanced customization.

Basic Configuration

To run the linter on your project, follow these steps:

• Clone the zk-client-mvvm-linter-starter repository from our zkoss-demo page.
• Open the app.properties file in the root directory of the cloned repository and set the zulDir and javaDir properties to relative paths to your Zul and Java source directories.
• Open your terminal and execute ./gradlew runLinter in the root directory of the cloned repository. The linter will analyze your project and report potential compatibility issues.
• Review the reported issues and make decisions best suited for your project, whether that means keeping your existing Server MVVM code or making modifications required for upgrading to Client MVVM.

Sample result from running the linter on F86-ZK-4028.zul and B86-ZK-4211.zul:

INFO: --------------------------------------------------------------------------- 
INFO: Checking /zk/zktest/src/main/webapp/test2/F86-ZK-4028.zul 
INFO: /zk/zktest/src/main/webapp/test2/F86-ZK-4028.zul 
WARNING:  108: 25       Zul files supplied via path binding not checked 
INFO: --------------------------------------------------------------------------- 
INFO: Checking /zk/zktest/src/main/webapp/test2/B86-ZK-4211.zul 
INFO: /zk/zktest/src/main/webapp/test2/B86-ZK-4211.zul 
WARNING:   36: 10       ViewModel without fully-qualified class name not checked 
INFO: ---------------------------------------------------------------------------

• The linter did not find any incompatibility. However, while the linter covers most scenarios, manual checks might still be necessary for certain cases. Please manually check those Zul or Java files against the lint rules listed in the RULES.md file.

Sample result from running the linter on F00633.zul:

INFO: --------------------------------------------------------------------
INFO: Checking /zk/zktest/src/main/webapp/bind/issue/F00633.zul
INFO: /zk/zktest/src/main/webapp/bind/issue/F00633.zul
WARNING:   22: 22       onClick="..." should be @command
INFO: /zk/zktest/src/main/java/org/zkoss/zktest/bind/issue/F00633.java
WARNING:   69: 13       `@ContextParam(ContextType.BINDER)` not supported
WARNING:   90: 28       `@BindingParam Label` not supported
WARNING:   95: 24       `Object` type casting not supported
WARNING:  105: 26       `@BindingParam Label` not supported
INFO: --------------------------------------------------------------------

• The linter found an incompatible usage of onClick on line 22 column 22 and four other potential issues in its ViewModel F00633.java file. You can fix these issues before upgrading to Client MVVM or skip upgrading the incompatible ViewModel.
• For more information on how you can upgrade to Client MVVM, please reference this small talk.

Additional properties in the app.properties file:

• tabSize: By default, the linter assumes a tab size of 4 spaces. If your project uses a different tab size, you can set the tab size to ensure that the reported column numbers match the actual visual positions.
• jarFiles: If your project relies on external Jar files, providing their absolute paths enables the linter to perform a thorough analysis.
• disableRules: In cases where certain rules are not applicable to your project, you can selectively disable a subset of the lint rules.

Logging properties in the logger.properties file:

• handler: By default, the linter uses ConsoleHandler to display output in the terminal. If you prefer to store output in a file, you can switch to FileHandler.
• java.util.logging.XXX.level: By default, the logging level is set to INFO, which only displays incompatible MVVM files. If you want to see all MVVM files checked by the linter, you can switch to FINE.

To create custom lint rules, follow these steps:

• Create a new Java class that extends the Rule class and override the getDescription method to provide a short description.
• Override the newZulFileVisitor and/or newJavaFileVisitor method to return a new instance of your custom ZulFileVisitor or JavaFileVisitor.
• Inside your custom file visitor, override the visit method for the specific node type you want to inspect and use the report method to publish warnings.
• Add the package name or the fully-qualified class name to the customRules property in the app.properties file for the rule to be integrated into the linter.

Here’s a sample custom rule class:

package my.pkg;

public class MyRule extends Rule {
    @Override
    protected String getDescription() {
        return "My Custom Rule";
    }

    @Override
    public ZulFileVisitor newZulFileVisitor() {
        return new ZulFileVisitor() {
            @Override
            protected void visitElement(Element node) {
                if (/* insert your conditional logic here */) {
                    report(node, getDescription());
                }
            }
        };
    }

    @Override
    public JavaFileVisitor newJavaFileVisitor() {
        return new JavaFileVisitor() {
            @Override
            protected void visitVariable(VariableTree node) {
                if (/* insert your conditional logic here */) {
                    report(node, getDescription());
                }
            }
        };
    }
}

Through identifying potential compatibility issues, ZK Client MVVM Linter enables developers to make upgrade decisions best suited for their projects, whether that means directly upgrading existing code to ZK 10 Server MVVM or making modifications required for upgrading to Client MVVM.

𝗧𝗔𝗟𝗟𝗘𝗥 | 𝗭𝗞 𝗘𝗡 𝗖𝗔𝗦𝗧𝗘𝗟𝗟𝗔𝗡𝗢
¡Sumate a nuestro taller sobre ZK, y adquirí los conocimientos esenciales para aprender a desarrollar con este framework! 

 Inicio: 03 de abril 2023

 Modalidad: virtual-sincrónico por Meet

 Costo: 80 USD | Participantes argentinos: $15.200

El material del taller estará habilitado en la plataforma Moodle y, además, tendremos encuentros virtuales semanales exclusivos para interactuar con nuestro facilitador experto en ZK.

This event is brought to you by ZK’s partner Raiz Digital Foundation. For more information, please contact Raiz Digital directly:

 comunidad@raizdigital.org

 http://raizdigital.org/#!/-bienvenido/

Well, not anymore. With the zk-types NPM package, you can now use TypeScript to customize the ZK 10 frontend with an experience similar to programming in Java.

Benefits of TypeScript

TypeScript is a statically-typed language that compiles to JavaScript. TypeScript syntax is based on JavaScript but comes closer to Java syntax. Being statically typed, TypeScript provides the following benefits that Java developers enjoy but were out of reach with pure JavaScript.

1. Reliable auto-completion; one doesn’t have to wade through API references on the Web.
2. Easy code navigation by clicking on names instead of searching the whole codebase.
3. Eliminate typos (e.g., misspelling isAlign as isalign) and mismatching types (passing a string when a number is expected).
4. Safe inter-op between various module systems (ESM, CommonJS, SystemJS AMD, and global UMD). One can even import a JSON file directly as a type-safe object.
5. Enable type-aware lint rules. This allows us to craft custom ESLint rules to enforce project wide conventions which can also be automatically fixed by the linter.
6. Automatic link validation and name/type matching in JSDoc, ensuring stronger synchronization between the documentation and the actual code.

These are the vast improvements we experienced first-hand on a daily basis while working with TypeScript. All in all, TypeScript enables an enormous amount of automated validations and automatic corrections that make ZK 10 easy and safer to use.

zk-types is Optional and Backward-compatible

ZK-types is a new way to customize the ZK 10 frontend that brings smart IDE feedbacks and a more Java-like programming experience.

[Since ZK 10]

If you have been customizing the ZK frontend with JavaScript, those customizations will continue to work. The purpose of zk-types is merely to boost developer experience with TypeScript. Also, zk-types completely covers all existing ZK frontend API without breaking existing behavior.

ZK10 + TypeScript with zk-types

Having reaped the benefits of a statically-typed ZK framework, we would like to share the gospel with you so that you can enjoy the same benefits when customizing the frontend. See the demo at zk-types-demo. The setup is minimal, but you can also just clone the demo:

1. Open a new project.
2. Get the types with: npm install zk-types
3. Install TypeScript with: npm install typescript
4. Create the template TypeScript configuration: npx tsc --init
5. Modify tsconfig.json to have "types":["zk-types"]
6. Create a .ts file and start programming. Start typing zk., and you should see the IDE showing auto-complete hints; IDE support is detailed in the box below.
7. Compile the .ts file with npx tsc (do not specify the filename). You should see an emitted .js file. Copy the .js file to wherever appropriate.

Note that the zk-types NPM package is very lean (under 1 MB); it contains only the type definitions (.d.ts files) for the ZK framework. This is another benefit that TypeScript brings: the possibility to code against type definitions then link with existing JavaScript in deployment, much like how C programmers code against a few header files then link with existing binaries on whatever machine they are targeting.

Visual Studio Code and IntelliJ IDEA Ultimate are known to support TypeScript out-of-the-box. IntelliJ IDEA Community does not; please read the this announcement. You will have the best experience when using the supported IDEs.

Exemplary Features of zk-types

From our experience with other JavaScript libraries that also migrated to TypeScript, we noticed how the quality of type annotation affects developer experience. Thus, when preparing ZK 10, we went to lengths to remodel the whole JavaScript codebase with TypeScript appropriately:

1. Prefer ES6+ syntax, as transpilation, down-leveling, and polyfills will be automatically done.
2. Replace ad-hoc conventions with first-class language features. The most significant being the deprecation of the zk.$extends pattern in favor of ES6 classes.
3. Provide a painless deprecation story. Despite replacing zk.$extends with ES6 classes throughout the codebase, we made sure that zk.$extends (1) works as it previously did, (2) can successfully inherit from ES6 classes, (3) allows ES6 classes to successfully inherit from it, and (4) type-annotated in detail.
4. Aim for null-safety. We made infrequent and consistent the use of null, undefined, uninitialized variables, and optional parameters.
5. Use generics to model the DOM element type of zk.Widget and the value type of zul.inp.InputWidget.
6. Narrow down the specification of types. E.g., specify HTMLDivElement instead of the wider HTMLElement, and prefer concrete types to any or unknown.
7. Incorrect type annotation is the most damaging of all. Since it is easy to introduce typos and other defects during the migration from JavaScript to TypeScript, a large part of the migration is automated.

Take, for instance, zk.augment, the type-safe successor of zk.override. The return value of zk.augment backs up the overridden properties of its first argument, and the return types are designed to automatically narrow down to only those overridden properties. In the illustration below, the overridden properties are the methods _init and hasNext. In fact, the method signatures are also auto-inferred as shown in the auto-complete popup: hasNext(): boolean. How convenient!

The overall zk-types experience is immediate, reliable, accurate, and delightful. We invite you to try out this new approach and let us know what you think!

We would like to invite you to explore more about them and let us know what you think! You can find related resources here:

 Background of the new features

• ZK 10 Behind the Scenes – Meet the developer of Client MVVM
• ZK 10 Behind the Scenes – Meet the developer of Stateless Components

 Youtube video resource

• ZK 10 Highlights

 Client MVVM Articles and Examples

• ZK10 Preview: 30x Lighter and 300x Faster with Client MVVM
• ZK10 Preview: Using the new and light Client MVVM
• ZK10 Preview: Knowing what to expect from Client MVVM
• ZK 10 Preview: Introducing ZK Client MVVM Linter

 Stateless Components Articles and Examples

• ZK10 Preview: ZK 10 is ready for building Cloud-Native Applications
• ZK10 Preview: Diving into Stateless Components

 Other Highlighted ZK 10 Features

• ZK 10 Preview: Customizing ZK Frontend made Easier and Safer with TypeScript

 Feedback Event

While the official release of ZK 10 is not available yet, following the examples in the articles, you can already try out these new features using our freshly releases.

Let us know how you like the features and share with us any feedback you have. Users providing the most valuable feedback and suggestions will be selected as winners of our feedback event. Each of them would receive a box of ZK-themed goods including baseball caps, pencils, T-shirts, vouchers, and more.

Feedback Forms:
ZK 10 Client MVVM: https://forms.office.com/r/v1rXpYwRgp
ZK 10 Stateless Components: https://forms.office.com/r/msPGzypbDk

We hope the latest features are beneficial, and we look forward to hearing from you!

Now, ZK Charts 10 will be available soon, upgrading the underlying Highcharts library to the latest version 10. This will bring new chart types, security fixes, and accessibility enhancements.

Highlights

• Upgrade underlying Highcharts from 8.2 to 10.2.1
• New Arc Diagram
• New Dumbbell Chart
• New Lollipop Chart
• Accessibility APIs

Other fixes and features

• ZKCHARTS-78 – Wrong encoding of Chinese characters in client-side PDF export
• ZKCHARTS-110 – hbox + splitter + zkcharts, resizing fails
• ZKCHARTS-125 – addSeriesAsDrilldown causes NPE if triggered before manual charts drill down
• ZKCHARTS-126 – charts _drilldownLevels set but empty after invalidate on setType()
• ZKCHARTS-130 – set an empty data causes a javascript error
• ZKCHARTS-137 – Upgrade PlotOptions and Series APIs to align with HighCharts v10
• ZKCHARTS-138 – breadcrumbs functionality for drill-down charts
• ZKCHARTS-139 – xAxis, yAxis, and zAxis support the Accessibility option
• For more information, please look at our tracker and highcharts’ change log.

While we are testing the new version, we would like to invite everyone to try out the ZK Charts 10 freshly-release, to make sure that it also works well in your project.

To try out ZK Charts 10, use the evaluation repository: https://mavensync.zkoss.org/eval/ and specify the zk charts version number as 10.2.1.0-FL-20220930-Eval (or later).

Please let us know how it works for you. If you run into any issues, let us know early so we can get them addressed before the official release. Thanks and we look forward to hearing from you!

James has been working in the team since 2014. He typically works on developing core ZK and ZK add-ons.

What was the starting point in the development of Client MVVM?

James: MVVM is a design pattern separating the data and logic from the presentation, which helps to reduce the code complexity. Since it was first out in ZK 6, it has been a major feature beloved by our users.

However, as time passed, we noticed that some users with bigger projects suffered from heavy memory usage. We’ve made different efforts to enhance the server MVVM to address this concern.

Did you have this idea right from the beginning? Or did you also evaluate other ideas?

James: The server-side improvement we did was good, but we wanted something more significant, and that’s when we turned into client MVVM. It took us some time to find the appropriate JavaScript libraries: in the very beginning, we considered React and Redux. These two libraries can handle states, expressions, and variables. Later we found Mobx. After evaluating and comparing the options, we found Mobx the best candidate; it is simpler, lighter, and more powerful.

Can you tell us about the POC process?

James: The core requirement is to replicate the server MVVM behavior to the client side while keeping the users’ upgrade effort as low as possible.

We spent about two months ensuring that the client library could be used to implement the client-side version of ZK MVVM. We started with key items like load-save, expression evaluation, etc.

What are some of the difficulties that you came across in the development process?

James: The life cycle of the server-side Components and the client-side Widgets are very different. This makes it quite challenging to move the MVVM logic from the server to the client. For example, ZK shadow elements is a template engine that helps developers compose the html layout with dynamic data. However, this mechanism was available only on the server-side.

To achieve the target – effortless upgrade, we had to redesign a client version of the shadow elements and ensure that it works the same as the server version. The redesign itself, as well as the verification process (unit tests, integration tests, etc), was intense.

What are the most common scenarios one would want to use this feature?

James: It can be used against all ZK MVVM pages, as it helps to reduce the MVVM memory usage. However, it is most efficient if you use it on: pages with massive load bindings or save bindings and pages visited by many concurrent users.

Is it also for existing projects? What are the steps for upgrade?

James: Yes, the steps to upgrade to Client MVVM are easy: include the required library, add the listeners, and apply it to the ViewModel. You can follow this small talk for details.

Should we use it globally or can we use it partially? Can we mix it with existing projects?

James: Yes, you can use it globally or partially, and yes you can mix it with existing projects. Again, please check our small talk.

What are some of the limitations?

Under the MVVM pattern, one should not access the components from the server side directly. However, practically we are seeing users still accessing the components directly or mixing MVC with MVVM. Now, with the new client MVVM, the server side does not have the complete and most up-to-date information, so you can’t access and control those child components as a server-side component. Also, it won’t work when you are mixing MVC and MVVM.

Another thing I’d like to mention is that IE11 will not be supported as the underlying Mbox5 library is incompatible with IE11 (note: Microsoft ended the support for IE11 on June 15, 2022, anyway).

For other differences, please reference this small talk.

What about MVC? Why are you only optimizing MVVM?

James: ZK server MVVM saves a lot of tracking bindings on the server side for you, and that is why it is heavier. MVC is quite simple and doesn’t save the binding for you; therefore, there is no need to optimize ZK MVC.

How would you expect users to use this feature? What kind of feedback are you looking for?

James: I hope that users find the client MVVM upgrade easy and see a real improvement in performance and memory use. If you see good improvements, please let us know. Please also let us know if there’s anything we didn’t cover.

Thank you for sharing today! Can you tell us what you think is important as a good developer?

James: I think it is important to keep learning and improving technical skills. This can be done by reading tech articles, taking online courses, and doing side projects. Also, I believe it is crucial to be open-minded – always open to new ideas, suggestions, and feedback.

We hope you find this interview interesting. If you have not checked out this new stateless feature, please try it and give us your feedback! Learn more about the Feedback Event.

We are happy that we could interview the core developer behind this new feature – Jumper Chen, Director of Products and Technology at the ZK Team. 

Jumper has been working in the team for over 15 years, from JSP/JSF to Ajax to RIA to the hype of Javascript libraries and, to the cloud.

Tell us more about the Stateless Components. What was the starting point in the development of Stateless Components? 

Jumper: “Ajax without Javascript,” or the ability to build web applications in pure Java on the server side, has always been the core value of ZK. On one side, this allows developers to focus on the logic without having to worry about server-client communication. However, on the other side, due to this server-centric nature, we did notice that in some complicated use cases, the server-side memory footprint becomes a pain for our users, and the footprint will only grow as they expand their applications.  

Because of this, reducing the ZK server-side memory footprint while allowing users to continue to manipulate ZK components by using Java API at the server has become our top priority. 

Did you have this idea right from the beginning? Or did you also evaluate other ideas? 

Jumper: Reducing the footprint on the server side means keeping less information on the server side; therefore, it naturally arrived in doing stateless components.  

A stateless component, as suggested by the name, means it doesn’t hold a state on the server side. But how is that different?  Take the HTTP protocol as an example. The HTTP protocol is also implemented in a “stateless” manner. Each HTTP request is independent at the time when the server receives it. It does not depend on another request, and there’s no order. This “independence” ensures that each request can be handled by any server or service in any order, without needing additional information. This is also essential for making “stateless” possible. We believe this can also be done in terms of web applications with proper design. 

Initially, I focused on finding a feasible way to manage ZK components using Java API to achieve statelessness. I discovered that leveraging immutable instances could be a good way to retain the ZK component instances immutably at the server.  

Once the server side was ready, we needed a tool to update ZK components at the client, and this is where we came up with the new UiAgent and Updater API. 

Having the stateless ready also brings a positive side-effect: enabling modern use-cases and supporting current infrastructure needs such as micro-services and cloud-native support. 

How long did you spend doing the POC? 

Jumper: Doing POC didn’t take me a lot of time. However, over the past 10+ years, we’ve added many rich components to our library, so getting the complete Java API set ready is very time-consuming. 

What are some of your difficulties in the development process? 

Jumper: Reviewing each component’s spec takes a lot of effort. We need to make sure that they function as designed and work consistently. Often, we need to alter them several times in either Java API or JavaScript. Besides, we need to make sure that we are not breaking the backward compatibility. 

What are the most common scenarios one would want to use the stateless components? 

Jumper: Using stateless components will be most efficient when you have many boilerplate contents or static contents that don’t need to be updated often. 

Why did you go with the Immutable Builder API pattern? 

Jumper: We noticed that the Java new Time API uses the immutable builder API pattern, and we found it a good match with what we needed.  

For example,  

         LocalTime.of(6, 30).withMinute(30)… 

How to get started using the stateless components? 

Jumper: You will be composing your UI using the stateless components (I-components) and associated APIs in Java. Then, you can use ActionHandler for event handling. For detailed steps, please refer to this small talk.  

Can this be applied to an existing project? Or mix it with an existing project?  

Jumper: Yes, it can be done as an independent page of a project, or an independent section of a page. We will be releasing articles to talk about how this can be done. 

Do you recommend users use stateless components? 

Jumper: Yes, definitely, if you wish to save server-side memory. By design, we assume most of the legacy ZK pages (except for MVVM) can utilize the stateless component API.  

One important thing to note is that using stateless components doesn’t necessarily mean you are having a stateless application. Your application may still need to hold the states, such as user name and login status. 

What are some of the concerns? 

Jumper: Since it comes with a new set of Java API, it works differently from the current way. You may need to spend some time familiarizing yourself with the new API to control ZK components. 

Considering the current client-side hype, do you also plan to provide a pure-client solution? 

Jumper: We started from server-centric, and if you look at our community, I believe there is still a group of users that recognizes the value of server-side solutions where you don’t have to take care of the client side and any communication in between. We hope we can still preserve this value for our customers.  

On the other hand, we are also working on migrating the ZK component’s Java logic into Javascript. Before ZK 10, many of the components could not be used in a pure client way, but they will function smoothly in ZK 10. We are not there yet, but ideally, we are hoping to make it flexible enough so that developers can use ZK components in whichever way they are more comfortable with: either Java API or pure Javascript API. 

Thank you for giving us the insight! Before we end this interview, can you share your motivation with us? You have worked for over 15 years in Potix. What keeps you going?  

Jumper: I believe working smart is much more important than working hard. I like to challenge myself and see if I can solve a problem in the most efficient way with limited time and resources. This drives me to learn proactively and brings me confidence and motivation. 

We hope you find this interview interesting. If you have not checked out this new stateless feature, please try it out and give us your feedback! Learn more about the Feedback Event.