Comparison: ZK vs Vaadin

Joonas Lehtinen

There is an excellent blog post about Vaadin in http://www.dzone.com/links/for_the_love_of_vaadin_java_rias_done_right.html.

The linked blog post has discussions that compare Vaadin to ZK (and others). I'll cut-n-paste some of the Vaadin-ZK comparisons here:

Quick comparison:

Vaadin uses GWT for the rendering, ZK uses proprietary client-side. This makes it a lot easier to add more widgets to Vaadin – it can be done in pure Java and there are a lots of good books about Google Web Toolkit that help.

ZK embraces XML for user interface declarations. Although you can use pure Java in both frameworks to define user interfaces, Vaadin is designed from scratch to be programmed in 100% Java.

Vaadin community is much more active in contributing add-ons to the framework. Today these add-ons are scattered around forums and svn, but starting from Mar 30. Vaadin.com has a good directory where you can just drag and drop new widgets, datasources and other add-ons to your project. In launch there will be about 100 add-ons next week to choose from.

Vaadin is released under Apache 2.0 license. ZK has two versions – limited community edition under LGPL 3.0 and full version released under commercial license.

Q&A:

”Vaadin uses GWT but it has different lifecycle. For example, you can’t use GWT builtin components directly.”. True – you must implement one additional method to widget to use it in Vaadin (updateFromUIDL()). Still – IMO – this is a lot better than having to write JavaScript in order to extend the framework.

“Vaadin requires to load all JS code no matter a component is used or not.” Not true. You can select to only include widgets you use on the client-side. In practice including all Vaadin standard widgets required 159kb of HTML+JS to be loaded. This is all needed to run Vaadin Sampler demo for example. Starting up ZK Explorer demo loads 158kb of HTML+JS initially when demo is started. While using demo, total amount of HTML+JS grows to 346kb (this does not include any third party integrations like Google Maps or Simile). From this I would say that Vaadin is considerably leaner on client-side.

“I were surprised Vaadin does not support Drag&Drop which shall be ready many years ago.” – Vaadin 6.3 includes comprehensive Drag and Drop support. This includes component to component drags, reordering of components, client and server-side drag handlers, HTML5 support for dragging resources from the Desktop. You can use 6.3 today (just download a nightly build) and 6.3.0 RC will be released this week.

“ZK has very strong integration with Java technology, from Spring, JPA, MVC… and up to the recent CDI. I don’t see much support in Vaadin”. You should look harder. There are several application stack examples on Spring integration, several JPA integrations, OSGi integrations, etc. Just type your choice of integration to the search field on vaadin.com

“ZK has very powerful components, such as calendar and spreadsheet, that cannot be found in Vaadin (including their roadmap)”. Full featured Vaadin Calendar will be released in couple of weeks, but here is no spreadsheet component for Vaadin. On the other hand there are lots of components for vaadin not available for ZK – for example a proper lazy loading timeline component: http://demo.vaadin.com/timeline

“Vaadin’s Ajax update is too coarse grained — it tends to invalidate the whole widget if what we need is to change an attribute.” Not true – this is decided on widget by widget basis. In most widgets only the changed attribute is updated.

“The strongest point of Vaadin is everything in Java. But, while GWT is a client-side solution, developers, ironically, can’t access the client directly with Vaadin. Every request has to go back the server.”. The idea here is to do everything in Java on the server-side. Client-side only comes to picture when you want to extend the framework by adding new widgets. Then being able to use Java on the client-side is a really strong point.

Ondrej Medek

Hi Joonas,

I develop with ZK, do not know Vaadin. I have just a few comments:

Vaadin design (CSS) is much more prettier then ZK.
ZK indeed has lack of community components or addons. One reason is that ZK 5 differs to ZK 3. Other reason is unfortunate license for ZK 5.
I like ZK way of defining user interface in XML. It is more readable for non-Java (CSS, HTML) developers. It also nicely enforces developers to separate controller from the view.
I think the to use Vaadin or ZK is more about to use GWT or not to use GWT. Otherwise both ZK and Vaading have similar philosophy.

Last updated on Mar, 30th 2010

Joonas Lehtinen

Ondrej Medek: Hi Joonas,

I am a ZK developer, do not know Vaadin. I have just a few comments:

Vaadin design (CSS) is much more prettier then ZK.

ZK indeed has lack of community components or addons. One reason is that ZK 5 differs to ZK 3. Other reason is unfortunate license for ZK 5.

I like ZK way of defining user interface in XML. It is more readable for non-Java (CSS, HTML) developers. It also nicely enforces developers to separate controller from the view.

I think the to use Vaadin or ZK is more about to use GWT or not to use GWT. Otherwise both ZK and Vaading have similar philosophy.

Thanks for the comments!

I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin. I even released an experimental XML-based declarative UI support for Vaadin while thinking about this. Still unsure if this idea is a good or not. But this is clearly a matter of opinion.

So at the moment - if XML based declarative UI is important, one should take a look of ZK. If extensibility is important and you are allergic to JavaScript, Vaadin is the way to go. In any case - both frameworks share the same Server-side RIA philosophy.

michele mazzei

Ondrej Medek: Hi Joonas,

Thanks for the comments!

I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin. I even released an experimental XML-based declarative UI support for Vaadin while thinking about this. Still unsure if this idea is a good or not. But this is clearly a matter of opinion.

So at the moment - if XML based declarative UI is important, one should take a look of ZK. If extensibility is important and you are allergic to JavaScript, Vaadin is the way to go. In any case - both frameworks share the same Server-side RIA philosophy.

I've used ZK for our internal web projects and we found it very useful.
Now I'm new to Vaadin, I will use it to compare with ZK, JSF and GWT in general.
I think Vaadin uses a better license strategy than ZK (which extensions are free and which not? which components are free and which not?) and in fact it has a huge number of plugin.

IMHO an xml file, that describes the UI, could be better than plain Java code: because XML syntax is the best choice
for describing "objects", while the Java language is better for implementing algorithms.

Last but not least: the demo is very beautiful!Congratulations!

Andrey Fink

1) About xml configuration:

Please! Add better Spring support, and you will have xml configuration for free ;-)
And also auto-configuration with annotations.

"better" means: no getBean calls, no aspect-j class modification
Example of good integration: http://click.apache.org/
http://click.apache.org/docs/extras-api/org/apache/click/extras/spring/SpringClickServlet.html
it is seamless, you just write your Page classes and DI/IoC just works, out-of-box.

Also for example look at this:
http://community.livejournal.com/ru_java/460539.html#comments
A Swing application declared in Spring xml, nothing special, only core old Spring.

2) log4j / slf4j / logback author thinks that "configuration files written in Groovy which are more convenient than configuration files written in XML".

I dislike Groovy, but main idea here is: use DSL for your domain.

So may be alternative configuration in DSL written in Clojure will be good addition to Vaadin.

Ondrej Medek

Andrew P Fink: 1) About xml configuration:

Andy, we are talking about XML based UI, not XML configuration in this thread. And we are comparing RIA frameworks, and do not discuss integration with Spring.

Andrey Fink

Wow. 3 contrary assertion in one post ;-)

I think this forum thread about "Comparison: ZK vs Vaadin".

>we are talking about XML based UI, not XML configuration in this thread.
If you can make your UI in xml, do really worry "what exact type this xml is"?
I think well-known xml are far better.

"integration with Spring" is big plus (I think "must have") for RIA framework (if you compare them, remember?)
It has higher priority than "XML based UI".

The main problem with ZK: its next-one language to learn.

With "standard" spring xml you will kill 2 hares:
- you will have "standard" xml configuration for web application, and with
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/extensible-xml.html
it can be not so verbose.

- spring integration

Andrey Fink

Andrew P Fink:
"integration with Spring" is big plus (I think "must have") for RIA framework

When somebody see this http://www.zkoss.org/product/zkspring.dsp
he thinks "ZK is better"

Last updated on Jul, 28th 2010

David Kilmer

Joonas Lehtinen: I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin.

I'm a ZK user contemplating a move to Vaadin. I'm working on an XML composer for Vaadin, and I thought it might be useful to share my reasons for wanting XML-based layout definitions. A good composer, in my opinion, goes beyond just laying out components. It also auto-wires declared components and event methods.

Here are my reasons for liking XML-based composition.

1. You can make changes to the layout of the container at runtime, which allows you to fiddle with the layout and get it just right without recompiling/redeploying a bunch of times.

2. You can provide several different layouts with the same Java class behind them. This is useful if you want to layout your components differently in, say, a mobile application.

3. It makes the code much cleaner by performing all of the component creation, attribute setting, parenting, etc. in the composer. Your Java class is focused on list models and other logic-type things rather than the mechanics of laying stuff out.

4. Events are more clear in the code when they are wired by the composer. A method called "onClick$okButton" makes it easier for maintenance coders to figure out where the real action happens.

Just some thoughts. In all, I'm starting to think that Vaadin is the stronger product of the two. My only complaint is that the event model is a tiny bit scattered -- it would be nice if all Vaadin events had a common interface.

Doug Ly

Joonas Lehtinen:

I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin. I even released an experimental XML-based declarative UI support for Vaadin while thinking about this. Still unsure if this idea is a good or not. But this is clearly a matter of opinion.

So at the moment - if XML based declarative UI is important, one should take a look of ZK. If extensibility is important and you are allergic to JavaScript, Vaadin is the way to go. In any case - both frameworks share the same Server-side RIA philosophy.

You may want to look at this post here.
http://vaadin.com/forum/-/message_boards/message/234396

I'm still developing the XML based UI for Vaadin. It looks pretty promising (for me :-))

Cheers

Last updated on Nov, 22nd 2010

michele mazzei

I used Zk and I enjoyed very much.

I used Zk for a small (internal) project and I found it very productive.

Then I tried Vaadin for a joke, and I was very impressed!

IMHO today Zk and Vaadin are the two best Java Web Frameworks.

I think that in future I will invest on Vaadin because of its open license.

I would like to ask a question:

I noticed that the Zk's table component is very powerful because you can put any complicated panel inevery table-cell (i.e. you can put in every cell anything you want),
on the other side with Vaadin I noticed that this is not possible.

Is it correct?

Do you have planned to improve the grid component (and the tree component too) ?

Bye.
Michele

Jouni Koivuviita

michele mazzei: I noticed that the Zk's table component is very powerful because you can put any complicated panel inevery table-cell (i.e. you can put in every cell anything you want),
on the other side with Vaadin I noticed that this is not possible.

Is it correct?

You can place other components inside table cells. Just set the column type to a component class. In theory you could even put a table inside another table, but I don't recommend it :)

michele mazzei

Thank you.
It's correct according to the manual:

components table

Bye
Mike

Last updated on Jan, 13th 2011

Kynao Yooky

I never gave Vaadin a try but looking at it for a long time and it's pleasant to see talented people keeping the good work on the road, congratulations for its improvements over time. I'm also glad to see that Vaadin is, little by little, closing the gap with ZK. Push is finally coming which is good news.

Quick comparison:
Vaadin uses GWT for the rendering, ZK uses proprietary client-side. This makes it a lot easier to add more widgets to Vaadin

Well, first, it has to be proved, second, it's a lot easier when the widgets are available :grin:. Advanced widgets are available into ZK, i didn't really see them into Vaadin. Maybe i didn't look the same showcases as the people saying that :bashful:
Third, i like the GWT approach but in practise, if i want my user not coming back, it's a good idea to use GWT widgets as they're everything except appealing... until someone deliver a good quality gwt widget kit. Anyway, can we use GWT designer in any way with Vaadin ?

[*] ZK embraces XML for user interface declarations. Although you can use pure Java in both frameworks to define user interfaces, Vaadin is designed from scratch to be programmed in 100% Java.

Ok but where are the advantages ? For example, David Kilmer exposed here valuable reasons why XML-based composition has also its advantages.

[*] Vaadin community is much more active in contributing add-ons to the framework.

So why ZK has more numerous sophisticated widgets ? In terms of widgets and as i see, ZK is nearly comparable with ext GWT and smartGWT. Vaadin is not (yet i hope) in the same "world". By the way, i didn't see mobile target in vaadin as we have it in extjs, ZK and SmartGWT [i'm not sure to well understand by apparently Vaadin 6.6 would begin the mobile support, to verify as it seems the need of the pro account]

- Today these add-ons are scattered around forums and svn, but starting from Mar 30. Vaadin.com has a good directory where you can just drag and drop new widgets, datasources and other add-ons to your project. In launch there will be about 100 add-ons next week to choose from.

Ah, i have to give a better look into this, that would be excellent news to see the valuable components we see into ZK, i'm dying to see them :) as i'm currently searching reasons to dive into Vaadin instead of ZK; and widgets are among the things difficult to ignore :) except when killing features are available in one product and not in the other. For example, if Vaadin applications could work on a cluster automatically and without additional work, that is the zero-state scalability like we have into SmartGWT and soon in Wicket, then i would care less of widgets and would be ready to completly forget ZK :love: . By the way, will we see a visual builder like ZK studio ? (Apparently a visual designer is mentionned in the roadmap)

[*] Vaadin is released under Apache 2.0 license. ZK has two versions – limited community edition under LGPL 3.0 and full version released under commercial license.

Yes, nothing to say here, that's a clear very important Vaadin advantage... Except one thing :O take into account Vaadin commercial add-on and it seems Vaadin is finally more expensive, i didn't check for ZK but i'm pretty sure Vaadin would be much more expensive than smartgwt :bored: that left me pensive 8o

Both Vaadin and ZK allow building dynamic web app into one page so some would say that SEO needs would be irrelevant, i would not agree :), not natural yes, but irrelevant, no. By the way, ZK is SEO friendly :P. As GWT is not friendly with SEO needs, i guess Vaadin is not adapted too.

Final note : in fact the thing that would be bun and would calm down the widget debate, is to support LGPL Smart Gwt as an add-on, that is the client side. By the way, that would cover much of the missing points of this comparison table :) http://www.smartclient.com/product/competition.jsp and instead of only framework competition, it would be by part framework collaboration :) even if on the competion side, Vaadin with such an add-on would become better than ZK or extGWT :smug:.

Last updated on Mar, 28th 2011

Joonas Lehtinen

Kynao Yooky: Advanced widgets are available into ZK, i didn't really see them into Vaadin. Maybe i didn't look the same showcases as the people saying that :

See the widgets and demos in http://Vaadin.com/directory

Kynao Yooky: Will we see a visual builder like ZK studio ? (Apparently a visual designer is mentionned in the roadmap

Yes. Just install it from eclipse marketplace or from vaadin directory today.

Jorg Heymans

my thoughts on vaadin vs smartgwt :

- vaadin has a 300page high quality manual right there for your developers to start with. This documentation alone will enable your developers to build very solid apps. I did not find the same quality documentation for smartgwt, but maybe it is in their commercial offering that is being referred to so often from their site.
- vaadin is an evolution of 10 years of work and this clearly shows in their API and component model. It has a clean design, responsibility and focus and a very consistent 'no suprises' policy. Keeping a product going and its backing company profitable for such a long time counts towards a lot in my book, it is certainly reassuring and gives a 'these guys really know what they are doing' feeling.
- In smartgwt i get the idea that the api is rushed and just a thin bridge over the underlying javascript library with little added framework value. It just allows you to do whatever the js lib can do, coated with some java syntactic sugar. Also you never really get away from the js/html side (methods like getInnerHtml(), getDOM(), getJsObj) which opens the door for all sorts of black magic hackery that becomes unmaintainable over time. I want my framework to be a framework and add a useful and just-enough flexible abstraction, Vaadin does that.
- Vaadin could do with more widgets. They should just hire a widget developer for a year and bring the framework more or less in line with nowadays 'rich and fancy widget' market, so that this becomes less of an argument in comparisons because it is the first thing users complain about. Not that many people will actually end up using any of those fancy spreadsheet widgets though (for this they will just use excel ;)

just my 0.05€,
Jorg (30 days Vaadin user)

Kynao Yooky

Joonas Lehtinen:

Kynao Yooky: Advanced widgets are available into ZK, i didn't really see them into Vaadin. Maybe i didn't look the same showcases as the people saying that :

See the widgets and demos in http://Vaadin.com/directory

Yes, i had already looked every pages of that space :) but in the context of the comparison, subject of this thread, i would say that community add-ons are a great added value for a product but are not basically the strengh of the product. That's why, to my mind, we can't compare whatever zk, smartgwt versus vaadin + community addons.

In more details : for more than one reason, i'm glad Vaadin has a successful add-on directory around a community contribution, that's something quite usual in php frameworks but not so usual in java frameworks, so that's an advantage over smartgwt or even zk for which such a space is not very much formalized and everything is almost in the package.

On the other side, i would not compare community work over what is included into the related product in the first place for many reasons :

- whatever the product (framework, cms, dms,..), i can't remember a community place where the contributions status like experimental, alpha, beta... were not in majority over stable contributions. I even don't talk about certified status :V

- community add-ons are very unusually backup by a company. Most often, the nice person behind an add-on either stop before the add-on reach an interesting status or finally does not maintain it. :kid:

- when i mention "maintenance", i mean maintenance over the releases of the underlying product... Depending of the add-on nature, some addons are not really reasonable to be found in a community directory instead of the product itself. For example, building a cms with the help of Vaadin, i can tell you that i would be far more confident to see ckeditor support into Vaddin itself instead of the community add-on. Another example : when we have no other solution, that's cool to see an add-on bringing push capabilities but that's far more cool to see it in the core. There are add-on nature which correspond perfectly to an add-on directory, i don't see my 2 examples fitting the situation.

I see community add-ons as an added value, not a replacement

Last updated on Mar, 29th 2011

Henri Muurimaa

Jorg Heymans: - Vaadin could do with more widgets. They should just hire a widget developer for a year and bring the framework more or less in line with nowadays 'rich and fancy widget' market, so that this becomes less of an argument in comparisons because it is the first thing users complain about. Not that many people will actually end up using any of those fancy spreadsheet widgets though (for this they will just use excel ;)

13 of those 160+ add-ons in the Directory are offered and maintained by Vaadin Ltd. They are add-ons mostly because we don't want to bloat the core.

We're also very interested in what kind of component our users need and want, so please let us know if you have ideas. The best way to suggest ideas to us is to create a ticket about it in the Trac (free registration required). That way the discussion stays in one place, though you could also link a ticket here in the forum for added visibility.

Also, if you are a Vaadin Pro Account subscriber you can vote for the ticket :)

Jorg Heymans

Henri Muurimaa:
13 of those 160+ add-ons in the Directory are offered and maintained by Vaadin Ltd. They are add-ons mostly because we don't want to bloat the core.

How would adding more widgets bloat the core ? Would it take longer to initialize and load a new application in the browser if Vaadin had let's say 1000 widgets in the core then if it only had 100 ? (even if the application just uses 10 widgets?) .. My guess is not and i hope i'm not wrong. Unless you mean that adding new widgets inevitably means adding new features in the core to support the creation and features of those widgets, then yes i can see the core getting bloated.

Jorg

Amit Ramaswamy

Henri Muurimaa: Also, if you are a Vaadin Pro Account subscriber you can vote for the ticket :)

Hmmm... that's interesting. We need to pay Vaadin to have the right to vote.

On the other hand, how can we make sure our request will be implemented? Do we need to pay more?

http://vaadin.com/feature-voting

Take top rank 1 (Ticket#6283) request as an example.
It was opened 3 months ago but still not closed yet even though it's voted as Top 1 priority.

Henri Muurimaa

Amit Ramaswamy: On the other hand, how can we make sure our request will be implemented? Do we need to pay more?

Development of Vaadin is funded by services sold by Vaadin Ltd., and purchasing a project to implement a feature has been possible for years. (eg. see this regarding third-party add-ons).

Take top rank 1 (Ticket#6283) request as an example.
It was opened 3 months ago but still not closed yet even though it's voted as Top 1 priority.

The Pro Account was only recently launched, and those tickets are older than the Pro Account itself.

We do listen to all of our users for feedback as ideas, as we have always done, but this new mechanism gives a more direct way for users committed to Vaadin to influence our roadmap.

The Pro Account subscribers can also prioritize a bug in Vaadin to actually force us to fix it ASAP. For all bugs prioritized this way by customers we guarantee that they will be assigned to our R&D within 2 business days.

A Pro Account also includes:

Licenses for all Vaadin Pro Add-ons
Access to our Knowledge Base that includes hundreds of curated articles about various aspects and best practices of Vaadin
The inclusion to our security alerts mailing list
Access to regression-tested custom builds that allows you to get new features and fixes faster than waiting for the next release
A support request system allowing the user to easily purchase almost any work from the Vaadin team

For further information and pricing see the Vaadin Pro Account page or contact us at proaccount@vaadin.com.

Sunil Sharma

Henri Muurimaa:
A Pro Account also includes:

Licenses for all Vaadin Pro Add-ons

Can I subscribe Vaadin Pro for just one month and then use the Vaadin Pro add-ons features/components (such as JPAContainer, timeline, calendar, etc.) forever? Is it ok that I just subscribe Pro account one month again when I need the updated version?

Does it include technical support (not just for bugs)? What's the guaranteed resolved time? Your guarantee in the time of job assignment is not enough for me.

Henri Muurimaa

Sunil Sharma: Can I subscribe Vaadin Pro for just one month and then use the Vaadin Pro add-ons features/components (such as JPAContainer, timeline, calendar, etc.) forever? Is it ok that I just subscribe Pro account one month again when I need the updated version?

No, the license is valid only while the subscription is active.

If this is unacceptable you can always purchase separate licenses for the add-ons you want to use. They are paid once and valid forever.

Does it include technical support (not just for bugs)? What's the guaranteed resolved time? Your guarantee in the time of job assignment is not enough for me.

I'm afraid that guaranteeing a resolved time is impossible, since it depends on the scope of the issue. However, we are committed to delivering the fixes ASAP, which means that the Vaadin R&D team will start working on the issue immediately.

The Pro Account also includes generic technical support in the form of support requests, but the subscription price does not include support time. Support time is purchased separately, so you only pay for what you use. See more info on the support request system here.

Last updated on Mar, 30th 2011

Kynao Yooky

Henri Muurimaa: We're also very interested in what kind of component our users need and want, so please let us know if you have ideas. The best way to suggest ideas to us is to create a ticket about it in the Trac (free registration required). That way the discussion stays in one place, though you could also link a ticket here in the forum for added visibility.

Well, good idea but that split interests and opinions around "users" and "dev" with different considerations and conclusions; or the ticket should also mention back a link to the forum for each idea :) but that will become a little complicated to follow :). Anyway, i don't see a suited forum category for hosting this feedback, maybe you could create an adapted one ?

To make things quick & easy to undersand, i will rely on competitor examples and to be realistic, i won't ask for monster widgets (grid, calendar, pivot ...) neither asking 100+ widgets :). So here are the more "simple" useful components for which i would like to see improvements on 6 of them and the creation of a new one :

Tree
Tabsheet
Layout
Accordion
Windows
Combobox
Portal

Last updated on Apr, 1st 2011

Henri Muurimaa

Very nice suggestions, thanks! Some of the use cases are already supported, but you listed several useful and valid improvements.

Pro Account subscribers, if you want to vote for the suggestions, please create separate tickets for each individual improvement and vote for those.

Artur Signell

Henri Muurimaa: Very nice suggestions, thanks! Some of the use cases are already supported, but you listed several useful and valid improvements.

Pro Account subscribers, if you want to vote for the suggestions, please create separate tickets for each individual improvement and vote for those.

Actually I already split most of the enhancements out to separate tickets to make them more manageable. So even easier for you to vote :)

Sunil Sharma

Henri Muurimaa:
No, the license is valid only while the subscription is active.

That means I cannot continue developing my application with Vaadin after I stop the subscription, right?

Can I continue selling my application to my customers when my subscription is not active?

Can my customers use my application after my Vaadin license is not valid?

Joonas Lehtinen

Sunil Sharma: That means I cannot continue developing my application with Vaadin after I stop the subscription, right?

Right.

Sunil Sharma: Can I continue selling my application to my customers when my subscription is not active?

Yes.

Sunil Sharma: Can my customers use my application after my Vaadin license is not valid?

Yes.

In many cases you might have more people working on the application in development time than when it is maintenance. Thus you might want to get subscription for the development phase and end it when the application moves to the maintenance phase. For example, say you are implementing Product 1.0 with a team of 5 developers. The application development project takes 6 months. After the project, you keep only one developer in the project to maintain it and implement minor additional features. In such case, you could subscribe all 5 to pro account for 6 months. When the application is done you can either keep the maintainers pro account subscription or purchase the used add-on licenses (for the maintainer).

Oliver Watkins

What really important to me is, is how extensible a component is. Its all very well to declare your GUI component in XML like this :

<MyPanel>
<MyTable/>
<Button1/><Button2/>
</MyPanel>

But what if you want to use that MyPanel as a generic class? What if you want to create a subclass with different buttons for different users? How would you do that in XML?

That's the main problem I have with ZK, or for that matter, all XML declared UI languages. In that sense Vaadin sounds like the better option.

Out of curiosity, I have two components that I made in Swing on my blog :

http://blue-walrus.com/?p=253
http://blue-walrus.com/?p=173

Would create components similiar in Vaadin? Would the code look similar? Would creating them in ZK be just as easy, or will you end up in XML/javascript hell?

Ondrej Medek

Extending components in ZK is very simple. You define it in the lang-addon.xml file, check the ZK documentation. E.g. if you have a <label> component, you may extend it and use the same name <label> (so you override the original component) or you can use a new name <mylabel>. Furthermore, you can use your new component in the ZK Studio Visual Builder. Adding an attribute the your new ZK component is also very very simple - just make a getter and setter in your class. So you can have <mylabel myattribute="ZK is so simple to extend and change ..." />.

Joonas Lehtinen

Ondrej Medek: Extending components in ZK is very simple. You define it in the lang-addon.xml file, check the ZK documentation. E.g. if you have a <label> component, you may extend it and use the same name <label> (so you override the original component) or you can use a new name <mylabel>. Furthermore, you can use your new component in the ZK Studio Visual Builder. Adding an attribute the your new ZK component is also very very simple - just make a getter and setter in your class. So you can have <mylabel myattribute="ZK is so simple to extend and change ..." />.

Extending components in Vaadin:

public class MyGreatTextField extends TextField {
   // My great improvements
}

Now MyGreatTextField can be used in my code, used in Visual Editor or packaged as an add-on.

Kynao Yooky

Cool, we should mix the 2 frameworks as we have support for both of them in the same forum :grin:
Joonas, your explanation about licensing above is interesting, that's a fair way of managing licence across development and maintenance phase

Kynao Yooky

Artur Signell:

Henri Muurimaa: Very nice suggestions, thanks! Some of the use cases are already supported, but you listed several useful and valid improvements.

Pro Account subscribers, if you want to vote for the suggestions, please create separate tickets for each individual improvement and vote for those.

Actually I already split most of the enhancements out to separate tickets to make them more manageable. So even easier for you to vote :)

Ok, i will take attention for following this rule in the future.
I forgot to propose a widget, visually simple but a nice one like i love widgets to be : simples but effectives :)

Miller Columns

Henri Muurimaa

Kynao Yooky: Miller Columns

Does the Miller Columns add-on have the features you need?

Ondrej Medek

Joonas Lehtinen:
Extending components in Vaadin:
public class MyGreatTextField extends TextField {
   // My great improvements
} 

Yeah, extending in ZK can made the same way. It is necessary to change lang-addon.xml only when you want to assing a new name to your new component for use in ZUL files. If you watn to create a component in the Java code (new MyGreatTextField(...)), you can use it right away. But me, and I guess 99% of programmers in ZK, do use ZUL (or JSP with ZK tags) way of creating ZK components - such a big advantage is that.

BTW. check the Vaadin tutorial at http://vaadin.com/tutorial Does the screenshot bellow match the code on the web page? It is hard to say, you have to analyse the code. If you make a proper ZK MVC design of the application, you can pretty well guess just from the first look on the ZUL how the resulting page would look like.

Joonas Lehtinen

Ondrej Medek: BTW. check the Vaadin tutorial at http://vaadin.com/tutorial Does the screenshot bellow match the code on the web page? It is hard to say, you have to analyse the code. If you make a proper ZK MVC design of the application, you can pretty well guess just from the first look on the ZUL how the resulting page would look like.

Yes, the screenshot is from that application. Just cut and paste it to your eclipse and click run.

Benjamin Seyinbour

@Ondrej Medek

Yeah, extending in ZK can made the same way

In the context of UI, extending XML or 'proprietary XML' is like polishing dirt: XML is the wrong tool for creating UI. The purpose of XML is to facilitate the transportation of data across platforms, operating systems etc. Just because you could use it to declare UI Components doesn't mean it should be used for that purpose.

Don't forget that using XML would require reading additional XML file(s), used as the datasource, before converting it to create the UI, but as we know this is a very slow process, which is yet another reason why XML is inappropriate for UI development; not to mention the contrasting structures of XML document and UI design.

XML is more integration overheads: Integration increases complexity and as one who has used jsp, jsf, adf, trinidad, richfaces, icefaces, jsf, flex, apache pivot etc; I now have less headache since I decided to use Vaadin. Obviously, Vaadin is not perfect but why use ZUL, extend ZUL, XML and java when you could achieve a better result with just java: easier to debug, fewer third-party libraries with their own integration problems.

If [repeat:if] the reason for using XML were because of one's lack of java knowledge, then I would suggest that any of the jsf frameworks would be preferable. XML is just not the right tool for UI, and I know a few developers who are put off by frameworks like apache Pivot, ZK, JavaFX – I understand that the new JavaFX will now be pure java.

Ondrej Medek

XML is the wrong tool for creating UI.

What's the result of Vaadin? XHTML, i.e. XML. So if you think XML is the wrong tool for creating UI then you probably think all the idea behind web application is wrong. I have heard such opinions already. Usually people who likes the old good desktop application programming says that. Well, good on you. So you are happy with Vaadin, GWT, Flex because you do not need to mess with XHML, CSS and Javascript.

I like XHTML, CSS and Javascript, I like making web applications. ZUL files in ZK give me an option to easily adjust ZK components with CSS and Javascript, mix it with XHTML. I like to mess with this. And many other people like it, too. And, I [repeat] the ZUL files are just optional. If you like, you can program ZK applications just in Java code, like Vaadin.

Benjamin Seyinbour

...you probably think all the idea behind web application is wrong.

As a matter of fact, I do and as you might have noticed, desktop is the direction web application is heading – with Flex and the (new) JavaFX leading the way.

In our business, it is the user that comes first. You can say that on the one hand, we spoil the user by providing them with the desktop experience and on the other hand we force upon them the primitive web pages created with legacy languages like XHTML, CSS and Javascript that are kept being recycled and repurposed. So there you have it.

rohit prajapati

one can find the quick comparison of zk and vaadin here:
ZK vs Vaadin at jtechnoprojects

Important Notice - Forums is archived

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Comparison: ZK vs Vaadin

Important Notice - Forums is archived

Vaadin lets you build secure, UX-first PWAs entirely in Java.Free ebook & tutorial.

Comparison: ZK vs Vaadin

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.