User:MontyPan/Ch03

When to Do with ZK

It all depends on how we look at things, and not on how they are themselves. -- Carl Jung

Although we all (should) familiar with ZK, but we come to look at ZK architecture and design thinking.

ZK provide a server centric architecture, developer only need to write Java code on server side to render and control DOM element on client side. Developer don't worry about any communication detail between client and server like Ajax or server push, all are handled by ZK.

In order to achieve this purpose, ZK must maintain a UI data structure (ZK components) on server side and also maintain another data structure (ZK widgets) on client side. ZK will synchronize data between two sides, and render screen on browser by ZK widgets' data.

To Web Artist

Conqueror Clipper : What are you talking about? I have no idea...

OK! In short words, with ZK, Mummy can coding on server side and control the browser's screen. In most case, the url does not need to change.

Conqueror Clipper : So what? I heard you can do it by jQuery or AJAX or ...... whatever.

True, jQuery and other JS library can do it. But ZK let you build website in pure "Java way", hence Java business logic model and UI will integrate more seamlessly. That' why ZK is very productive.

Conqueror Clipper : No wonder Mummy look like goof-off recently.

Follow this thread, we can find the goal of ZK is (always) RIA (Rich Internet Application). ZK do a lot of works to approach. Hence, if you want build a static content page, ZK will be slower then pure HTML/JSP when rendering, not to mention server side loading.

Mummy Pythian : Aha! Don't have to wait system online! A case of beer! Cheer!

Shake Spear : Wait a minute! I must defend to the death the beer! When I read the ZK documents, there are some skill can raise performance like native namespace or stubonly attribute.

Great! You are really a serious system architect.

Mummy Pythian : Huh? What's that?

Don't hang around, Mummy, started studying hard like Shake! We also take this opportunity to look at several alternatives.

Alternatives of Build UI

Besides standard ZK components, ZK provide some alternatives for different build UI requirement :

• Html(ZK Component)
• XHTML components
• native namespace
• stubonly attribute

To System Architect

Actually we miss ZKJSP in above list. We don't discuss ZKJSP, because it's a ZK product not in core ZK. If you consider your develop workflow or website requirement is very "JSP-like", it is worth to think about the ZKJSP.

Html（ZK Component）

Html is a ZK component. You can assign a HTML string to it and this string will be render directly without convert character like < to <.

Because Html is still a ZK component, it will occur the same performance as other components. But Html will be a little fast then the same layout build with ZK components, the reason is content of Html is a string not a data structure. With the same reason, you can only operate the string, can't mix other ZK component. In real product is useless -- or say is only suitable for "output a pure HTML" situation. We don't recommend to use this component in general case.

Please refer to "Html component reference" and "The html Component" for more information.

XHTML components

We can use XHTML components to control XHTML tag just like ZK component. In other words, XHTML components is similiar to ZK components in ZK architecture.

Generally speaking, XHTML components is focused on small area which built with pure XHTML tag in ZUL. Hence, you can design layout more easier, dynamic update content. It is convenient but not designed for performance issue. Actually if you use a set of XHTML components to build a grid, it could be more slower then use Grid directly. That's because the amount of component in ZUL is increase.

Please refer to "The XHTML Component Set" for more information.

native namespace

The native namespace is a HTML tag set of ZUL. ZK will sent them to browser directly, rather than translate to ZK component. The difference between native namespace and Html, you can arbitrarily mix native namespace element and ZK component. If you only compare the rendering result, native namespace element is the same as XHTML components, but in ZK architecture there are pole apart. The key point is that server will not keep any instance of native namespace element, they only exist on client side. Hence you can't handle them on server side whatever content or behavior.

In real product, use native namespace element appropriately can improve ZK application's performance dramatically

Please refer to "Use Native Namespace instead of XHTML Namespace" for more information.

stubonly attribute

Different from Html, [XHTML component] and native namespace element, stubonly is not a component or tag set, it is an attribute of ZK component.

When you set stubonly="true" of a ZK component, server will replace original ZK component instance by StubComponent instance. StubComponent only maintain minimum component data, receive StubEvent event. Thus, the memory footprint of component with stubonly="true" is minimum. If business logic don't care about the component's state and won't operate them, for example Hlyaout and Vlayout, add this attribute will decrease server loading significantly.

Btw, there is another characteristic, you can only use it in ZK EE version /

Please refer to "Specify Stubonly for Client-only Components" for more information.

Mummy Pythian : Arghhhhh... my free beer.....

Shake Spear : Who care about the beer, the question is not answered! Since the efficiency can be resolved through these skill, why you say "Can't build whole website with ZK?"

Maybe use native namespace or stubonly can resolve performance issue, but it only resolve the server side part. We must think about the client side issues and web artist's production.

Conqueror Clipper : What? Me?

Client Side Issues

Although ZK is a server-centric architecture, developer usually write the server side code, but end user eventually operate your application on browser. So we can't ignore the client side issue.

First is still performance issue. Because ZK use JavaScript to control DOM to rendering instead of output HTML directly, and ZK will execute some routine, for example hflex, before rendering, we can't expect the rendering speed is faster then pure HTML/JSP. Sure, ZK works on these issues. You can use Client ROD、fulfill attribute、renderdefer attribute to improve client side performance. It is undeniable that end user will have longer waiting time. * (Well, you know it, end user don't care about what develop tool you used, no matter ZK or Klinon language) *

On the other hand, if whole website create by ZK, web artist's production will be a problem.

Of course we hope the web artist to learn ZUL and some ZK basic feature. *(From ZK fundamentalism and marketing department: ZUL is easy to learn! Basic logic is the same as HTML, but is more powerful!) * Actually, most web artists can only write HTML/CSS. They usually must create icon image, layout and focus on "visual effect is the same on every browser" issue. Is it a good idea let web artist to learn ZK? Maybe not.

The fundamental problem is "The goal of ZK is simplify the development of RIA". For web artist, the DOM structure of ZK component is too complex and fat, elements assign CSS condition is hard. They can't design expected layout and visual effect simply. They use XHTML components or native namespace may not be handy and must work in ZK environment, not to mention XHTML components exist performance issue. Some client visual effect along with business logic must rewrite with ZK (will occur performance issue again).

Shake Spear : Fine, you convince me. It's so stupid if I use ZK anywhere. But problem is still there: "How do I design the architecture of [ToDoZK]?"

Well, it's time to publish answer : Use JSP as a layout skeleton, implement RIA part with ZK.

Shake Spear & Mummy Pythian : WHAT?

We conclude this chapter first. Next section we will introduce how to build [ToDoZK] with JSP + ZK architecture step by step.