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 :
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).
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 :
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?
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 component, you may extend it and use the same name (so you override the original component) or you can use a new name . 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 .
Cool, we should mix the 2 frameworks as we have support for both of them in the same forum
Joonas, your explanation about licensing above is interesting, that’s a fair way of managing licence across development and maintenance phase
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
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.
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.
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.
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.
We have an exception when we click on “Submit Change Request” from the page
Comparison
Just to mention ZK 6.01 is also available as the comparison table is about ZK 5.0.8
Does the Vaadin demo really reflect the Vaadin gui capabilities ? There were issues mentionned about that if i remember (i can only remember of smooth animation…) but don’t see much changes in the sampler demo.
I do not use Vaadin, I do not know it, so I’ll not write about it.
After 4 year, I still like the xml approach, I started with zk in 2009, with version 3, now I’m using the 7 and I’m going to use 8.
In my experience, using MVVM in xml give a lot of time saving and clean code.
I’ve programmed a lot in swing, and the 100% java approach (I’ve done it in zk a lot before get usual with MVC and after with MVVM) put all the load on server side.
Now I delegate same part of UI to jquery (zk from version 5 is built with jquery).
With zk I can choose, use Java as swing like, use MVVM, use jquery.
Using MVVM I’m writing business logic (view model) with no legancy to ZK and make unit testing on it.
This save from a lot of problems.
Put MVVM in Vaadin and I’ll take a look.