Article: ZK Rich Client Framework and Agile Development


News: Article: ZK Rich Client Framework and Agile Development

  1. In this article, Cameron Smith explains why rich client frameworks in general, and ZK in particular, not only allow for more pleasing, powerful UIs, but aid in applying an "Agile" development methodology. The discussion is based on the real experience of his firm which has been programming business applications with both "32-bit" and traditional web GUIs for years, but over the last year has implemented a shift towards using a rich client approach, with positive results. In the latter half of the article, he offers a tutorial through the basics of introducing ZK into your existing web application. The tutorial has a step-by-step approach but aims to highlight, from the start, the most useful structural features of ZK from the point of view of developing complex applications.

    Threaded Messages (26)

  2. Interesting. I personally like the approach of Echo2 more (pure Java, no Beanshell or any other language) or OpenLaszlo (much richer and flashier UI), but I haven't used them in a true production project to see if they fulfill their promise. Good to see that someone has actually used ZK and been successful with it. Will take it out for a spin for sure. P.S. Can you call EJBs from ZK script? In particular can you get a reference to an EJB 3.0 using the @EJB annotation?
  3. One of the things I like ZK most is they always think of the programmer and offer all the options he might need. If you prefer pure Java, you can use so-called Richlet. If you prefer markup language without BeanShell, use the use attribute and so on. If you prefer other scripting language, they have Ruby, Groovy...
  4. Screenshots?[ Go to top ]

    Interesting article. Thanks! Say, there are several "screen shots" that are mentioned in the tutorial part, but none seem to appear...? Freddy
  5. Author's replies to comments[ Go to top ]

    Thanks for the comments. I will reply to several points at once. 1. Screenshots. I did include screenshots with the original article which I sent to the TSS editor. I don't know why they were not included. I have emailed the editor and asked him to include them. 2. Typos. Sorry, I had assumed (always a dangerous thing), that TSS would proofread the article. In future I will arrange proofreading in-house. But LOC I had in fact thought people would know!! ;-) 3. Comparison Matrix. Dear Akal Inoger, I agree with your general argument. However I would like to clarify a couple of things. a. "What we need is a comprehensive feature matrix...". I agree - if you had the time to prepare one and publish it, I think it would be very popular! As I explained, we did not have the time, so we used the 80/20 rule and did a comparison which we all know is rough and ready. To do this properly (which I have done various times in my career) requires a surprising investment of time. The semantics, weighting and measurement criteria new feature in the matrix must be carefully defined. Then you must actually do the measuring. For a framework product measuring one product can take a good developer 1-2 days minimum! This is why Gartner Group et al. charge so much for their studies! b. Wood for the Trees. In my experience, about 70% of software purchasing decisions are made on the golf course, or its equivalent in your chosen country of residence. In these cases, a very large, complex study is often commissioned, and tweaked to justify the choice which, tacitly, has already been made. These studies are often heavy on detail but light on the preparatory work I mentioned in point (b). In this respect they are of dismal intellectual quality, compared to, for example, the surveys produced by professional marketing or political survey firms, where a huge amount of preparation goes into taking bias and confusion out of the survey process. 4. Echo2 Dear Tom, the link to the x-browser support comparison was very interesting, thanks. Re echo2 stability, I based my analysis on the forums, not on tests. If you use any framework on just one project, you will use a certain subset of its functionality. So you might be lucky or not. People who are not lucky, will tend to give up and use something else, leaving a "self-selecting" community. Therefore when I first considered Echo2, I looked at the forums and found many many posts which were simply not answered or required some clever workaround. More recently, when I wrote this article, I repeated the exercise, in case things had changed for the better. In my opinion, they had not. This does not mean that Echo2 is bad or that these issues are critical, or will "never be fixed". However, it was one of the criteria that I chose to use to rate the frameworks. You and anyone else, are free to disagree with my criteria and/or the rating I gave against those criteria. 5. OFBiz Aburo Baize, in fact we use ZK as a frontend to OFBiz, and it works fine. 6. Licence costs Lipman Li, I appreciate your concern. My company is also small and we are very careful with cashflow and investment. My experience has been that the use of ZK, for which we bought commercial licenses, has more than paid for itself via the improved productivity of our developers (who, naturally, receive salaries!). If they still had to do everything by hand (or semi-by-hand with DWR + Dojo), it would cost us more to develop each new feature for our project. It is rather like having a good programmer working on an old machine with a PII processor and 64Mb RAM. He will waste a lot of time every day doing recompiles, restarts and going through test cycles. A sensible company IMHO would spend USD1000 or so on buying him a new computer, and double or triple his productivity. The computer could last for 2 years, and the marginal cost relative to his salary, (which you have to pay, like it or not) is very small. Free software, in the words of Stallman, is free as in speech. But many people seem to think, morally, that it also HAS to be free as in beer. Personally, I do not think that this is always realistic, as programmers have to eat! Anyway, each company has its own way of working and cost-estimation, and you must make your own decision.
  6. I'm using ZK currently. I've found some things that I wish were handled a bit better...but you could say that about any framework. All in all, it's a very vibrant community and it is quite easy to ramp up on.... All you need is Java. Of course its still the web so a basic understanding of web development is desirable. The license has always bothered me too, but I don't knock the ZK team for that - its their decision. It would not be my choice but its not like its unusable because of the license. Anyone building a custom inhouse-only piece of software can utilize it for free, as well as open-source projects that are GPL. As one poster said, even if a license was needed, it would be well worth the money to do it rather than try to write something similar to it. Mike
  7. Re: typos... hey, I *did* proof the article, but I'm human, too, and my experience isn't in copy-editing. Copy editing takes a TON of time, folks, and I caught the ones I... well... caught. Sorry about that. I'll try to improve.
  8. Joseph: Just to be clear, I wasn't criticizing. I do realize that copy editing takes a long time. Instead, consider my comment, my contribution to the proofreading of the article :-) I would still like to know what those phrases I pointed out should have been, though.. Thanks, Freddy
  9. Responses to Frederic's points[ Go to top ]

    Hi Frederic, here you go.... 1. "the more LOC a programmer writes, the more errors a human they make." What I meant: the amount of simple errors (typos, null references, endless loops, putting something in request instead of session scope, naming something wrong in a struts-config.xml, etc) is proportional to the number of Lines Of Code that you write. 2. "roughing out new Use Cases as evolutionary prototypes, having a customer viewing, then reworking them in time for the next or next but one viewing." I believe my english is correct here, but I'll put the point in different way, by giving you a scenario. a. On monday, we visit the client and discuss a new Use Case, perhaps roughing out the screen on paper and certainly gaining a deeper understanding of the data model and data flow involved. b. By next monday, we want to have that Use Case coded up as a working screen, show that we can show the client while their mind is still warm, and they can give us good feedback. They will no doubt detect some conceptual errors both in their original thinking, and our attempted implementation. c. One more week later, we go back to the client with a fixed-up use case, and by this time it is unlikely we have any major conceptual errors (the kind that force you to rewrite chunks of your data model). This timescale thing is hugely important, because my firms clients are SMEs. So typically the key business representatives from the client are middle and senior management who spend most of their time each week actually running their company/department. They do not have the luxury to meet with us every day. And equally, if we meet only once a month (or deal with Use Case X only once a month), it will be difficult for them to remember all the rich context of the previous discussion they had about it. 3. "You still end up writing a frontend UI layout which requires the developer to know, and agreed project-specific conventions for using:" What I meant to say: I have worked on several projects in different firms which all, for example, used Struts for the frontend. So I got to know Struts quite well. However, with EVERY new project, I had to get up to speed on some differences, for instance: - directory locations and filenames for struts config files - conventions about path naming and class naming etc - conventions about how much responsibility to put in one Action 4. "We are a small company, we wanted a decision in a limited timescale, we wanted a decision in a limited timescale, and we took one." (this is surely just pasted twice by mistake). YES: pasted twice by mistake! hope this helps, cameron
  10. Cameron, Thanks very much for your explanations. Like I said, interesting article. Now if only they would add your screenshots ;) Cheers, Freddy
  11. Cameron,

    Thanks very much for your explanations.
    Like I said, interesting article. Now if only they would add your screenshots ;)

    We're working on it. They should be in soon.
  12. Joseph?
  13. Re: Any news on the screenshots?[ Go to top ]

    Hello? Anybody home?
  14. re: proofreading/typos[ Go to top ]

    Yeah Joseph, I honestly didn't expect there to be so many. I also only caught the ones I... caught ;-) Have done proofreading for other people, but I guess we are always blind to our own mistakes. We'll get it right next time.
  15. Some editing required?[ Go to top ]

    All in all this is a good, interesting article; there are just a few phrases that I didn't understand. Perhaps they are editing errors. Please explain these phrases to me or tell me what they should have been instead: 1. "the more LOC a programmer writes, the more errors a human they make." 2. "roughing out new Use Cases as evolutionary prototypes, having a customer viewing, then reworking them in time for the next or next but one viewing." 3. "You still end up writing a frontend UI layout which requires the developer to know, and agreed project-specific conventions for using:" 4. "We are a small company, we wanted a decision in a limited timescale, we wanted a decision in a limited timescale, and we took one." (this is surely just pasted twice by mistake). Thanks! Freddy
  16. Re: Some editing required?[ Go to top ]

    I think that LOC maybe means lines of code
  17. Re: Some editing required?[ Go to top ]

    Yes LOC means lines of code, that's not the part that I didn't understand. It's "the more errors a human they make." I guess 'the human' doesn't belong there.
  18. Regarding Echo2, Smith says:
    Echo2 ( is free and Open Source (Mozilla Public License). However it is extremely buggy and immature still,
    I am using Echo2 in a project, and have found quite the opposite: very few bugs, none of which cause exceptions or unexpected behaviors. Perhaps Smith used a very early release of the software; if so, that fact should be noted. My experiences are with version 2.1.0.rc2. I'll also point out that Echo2 rates fairly highly in cross-browser support (point "a" on Table 2 which compares features.) One survey (over one year old now) is at:
  19. It was nice to see that somebody actually tried to evaluate the rich client frameworks. With the number of them mushrooming it is very clear that only a few will survive and the trick now is how to pick the best one. This reminds me of the eary days of application servers... The article is a step in the right direction but what we really need is a more comprehensive matrix that would list features and rank frameworks based on them. Being a consultant I often have to evaluate technologies and the way we do it is usually in the Excel spreadsheet with rankings and importance of each criteria (that can vary project to project - to some, rapid development is more important then long-term maintenance, to others it may be the opposite). IMHO a few of the frameworks are missing. I would love to see Yahoo UI library included. For better or worse, having a company with big budget behind a framework increases it's chance for survival. On one of the projects we took a rich client written in Swing and turned it into a web-based app using WebCream - it exceeded our expectations quite a bit. I think the availability of an IDE where developers/designers can quickly create screens visually is extremely important for productivity and maintenance.
  20. There is a good discussion about which Ajax framework to use with OFbiz (an Apache project) at mailing list.
  21. The URL: dot 81718 dot qmail at web23106 dot mail dot ird dot yahoo dot com%3E
  22. Licence problem[ Go to top ]

    I feel ZK is very great framework indeed, as I evaluate it more, until I realize the licensing issue, it is not for poor company like the one I'm working for. I stop to evaluate it, and continue my work with DWR + Dojo.
  23. Google programing model[ Go to top ]

    Hellu, Interesting article. I like the programming model of GWT (Swin alike). I am currious how this is compared to ZK?
  24. Re: Google programing model[ Go to top ]

    Hi Ed, not sure exactly what you mean by "Google programming model". If you mean "using sequential lines of code in an imperative language, to build up a graph of objects, each of which represents some part or state of the UI" (cameron's definition!) then Google hardly invented it. As you say, Swing also uses it. As do Echo2 and several other frameworks. As I mentioned in the article, and Samia confirmed above, ZK fully supports this model. However, as much as possible, in my firm we try to build our UI's declaratively as it is quicker and easier. Note that the GNOME UI project for linux uses a similar idea, allowing you to define layouts etc. via an XML file. ZK certainly did not invent this model either, but it is, IMHO, the leading concrete implementation of it for web-based rich clients, and, at least for our company, that is important. But, if you wanted to use ZK and build up EVERYTHING as object graphs, either in beanshell or full-on java, you can easily do that. It is your choice!
  25. Re: Google programing model[ Go to top ]

    He Cameron, Point taken, loud and clear ;)... Thanks for your explanation.
  26. Fork of Echo2 tg address[ Go to top ]

    Karora has forked the Echo2 code to address both the issues of stability and bugs. This project is called "Cooee" and can be found at
  27. ZK is an awesome framework...[ Go to top ]

    I had not even heard of ZK before i read Cameron Smiths' article. First off, Thanks a ton Cameron...for writing about such a fantastic framework. Once i read the article...the comparison to various types of frameworks and ZK scoring more than GWT is what got me more interested. So i got more curious and tried out the examples in the article.....and when compared it with my experience of writing an extremely simple app in GWT.... i immediately saw what Cameron was writing about and i completely agree with his conclusions. We (as in my design consultancy and corporate training company) have adopted ZK for the new platform that we host all of our intranet and extranet based applications. Here is a why we chose to go with ZK: One of the applications that will be live by the end of this month, has about 30 screens and is a mid-complexity web appliation. When we did our estimation of how long it will take us to build it using regular J2EE stack (JSP / JSTL/ JS / POJO / Spring / DAO and MySQL DB) ...we came up with about 150 days of Level of effort. With ZK, we have designed / implemented the same site in about 35-40 days. That was a huge saving for us....and as Mr Smith writes, we write all our code in Java .... and XML for configurations. We use .zul as the front end...then each .zul file has a 'controller' java class (no..we don't use beanshell)...this controller then talks with a 'manager', into which we DI all the required DAO's and DAO's themselves use JdbcTemplates and we finally use Spring AOP for transactions, logging etc. Personally, i think GWT will have a huge adoption issues.......the feeling i get while using GWT is very familiar to what i felt when i first wrote a EJB 2.1 and earlier.....learning curve is too high...spending too much time to achieve something. In GWT, you almost always have to use anonymous inner many of us are really good at using these and know how to unit test these .... in a easy and a very simple way... Not to mention the amount of code that GWT generates...a simple hello world app generates about 1.2 MB of about 22 files....I know why he does that...but to me thats too much.... All in all...we have gone with ZK and absolutely no is a great framework and it has certainly made out lives a lot easier.... So folks at ZK....thank you for such a great product....and Cameron...thanks once again for your article.