Click Framework 1.2 Released

Discussions

News: Click Framework 1.2 Released

  1. Click Framework 1.2 Released (36 messages)

    Click Framework 1.2 has been released. Click Framework is an easy to learn and use J2EE web application framework. Click is designed for web app development by commercial Java teams. Click's design is such that developers should be able get up and running within a day. Highlights
    • Very easy to learn
    • Component and Page Oriented design
    • Event base programming model
    • Automatic form rendering and client/server side validation
    • Page templating
    • Velocity and JSP page rendering
    • High performance
    Online Examples http://www.avoka.com:8080/click-examples http://www.avoka.com:8080/click-quickstart Roadmap and Changes http://click.sourceforge.net/docs/roadmap-changes.html Click IDE Click also has an Eclipse IDE plugin available.

    Threaded Messages (36)

  2. When last time I had a look at Click it seemed to use velocity templates for rendering pages. As of now Wicket seems to be a better choice. It has got a very good developer community. How does click fare in comparison to Wicket or Tapestry,for that matter? Finally, Is there a way of connverging all ideas into a single framework?
  3. Why Click? * Java web app development is insanely painful * Tapestry has some great ideas, but it’s like “Eating an Elephant” * Your average Java developer has a short attention span and shouldn’t be given scissors * Had to be a better way Comparison To Wicket Click is much simpler and easier to learn than Wicket. The Click API has some 83 odd classes (including the Click Extras), while Wicket API in comparison has 666 classes. This is a good thing. The Click documentation is also outstanding, leaves Wicket for dead in this area. Other benefits include the automatic HTML generation provided by Click components, this is a big productivity benefit. You can do quite sophisticated form and table layouts in Click Java code with out having to write reams of HTML. For example you can have a Click form with a multiple column layout, multiple fieldsets and simply have in your HTML page: $form. Of course if you want you can manually layout forms for doing very fine grained UI design. Other Click benefits, include many more out of the box components and the ClickIDE. Where Wicket has advantages over Click is in its support for persistent page state and AJAX. I know of a couple of people who have used both Click and Wicked so maybe they could provide you with some additional in sites. regards Malcolm Edgar http://click.sourceforge.net
  4. ..while Wicket API in comparison has 666 classes.
    Now that right there is enough to convince me that Wicket is the Devils work! ;)
  5. ..while Wicket API in comparison has 666 classes.


    Now that right there is enough to convince me that Wicket is the Devils work! ;)
    i will quickly make one class more....
  6. :) thats is pretty funny
  7. * Tapestry has some great ideas, but it’s like “Eating an Elephant”
    Malcom, I agree with you only 99.999% on this one. I would have agreed 100% with you if you had said Tapestry is like "Eating a Dinosaur". Bacause its becoming even more bloated and overkill in Tapestry 5 as it's coming with it's own in-built IoC container. Consider building an application with a Spring layer as well. You'll end up with 2 IoC containers in your runtime. And even more insane is when you're integrating these layers with an EJB3 layer- you'll end up with 3 IoC runtimes. I know, web development is complex. But does a webframework need its own IoC container? Ok, maybe it needs some sort of DI, but then my next question would be why can't the DI be delegated to other frameworks. Especially in times when there exist already matured IoC frameworks like Spring? Howard's fingers itch so much he always wants to re-invent the wheel. Take a look at the history of Tapestry releases. Every major release was a re-write of the previous with little consideration to backward compatibility. For me this is sufficient reason to shy away from Tapestry. BTW, during googling sometime back, I learnt theserverside was implemented with Tapestry. But I also heard recently that they've replaced a big proportion of the Tapestry part with Webwork. What does this say about Tapestry? Jan
  8. +1 on the Tapestry rewrite. I was seriously looking at Tapestry as an upgrade option from Struts. The v4 release broke v3, but I believe I read that this was done to create a new foundation moving forward. I don't quite buy into the Hivemind philosophy, but there you go. I figured, let v4 simmer and we'll take a look... However, when v5 came out, broke v4, put up another IOC container saying how it was also better than Spring(the same claim being made by the Hivemind integration) I just couldn't take it seriously. I mean, why wasn't Hivemind good enough? And if it wasn't, why gamble on the current claims of the new IOC container or even Tapestry? Sorry. I wouldn't risk my job on it.
  9. BTW, during googling sometime back, I learnt theserverside was implemented with Tapestry. But I also heard recently that they've replaced a big proportion of the Tapestry part with Webwork. What does this say about Tapestry?

    Jan
    Obviously, I'm not privy to the thinking inside TechTarget, as I haven't been involved with them since Jan 2005. When I last worked with them, they were quite appreciative of what Tapestry was offering them, but they only had two developers working on the site. It is likely that they wanted additional functionality in the discussion forums; they may have faced a buy-vs-build decision. Further, it is likely that they were offered the software for free (much of the TheServerSide infrastructure back in 2004 was donated by companies for the exposure). So in that likely situation, you can see how they might swap out portions of the site in favor of Jive. As to the rest of your post; well Jan you can tied up about technology decisions that are irrelevant, such as the number of IoC containers (you miscounted, the servlet container acts like an IoC container in a limited fashion, so no we're up to four. And most application servers are built around something IoC-like that's not visible to the user, so now it's up to five and counting). But that technology is not interesting compared to what T5 buys you, which is a lot. Further, I've been able to simplify many things between T4 and T5 so that Spring will integrate as a first-class citizen. I've begun showing off T5 to users at my No Fluff Just Stuff speaking engagements and it floors everyone who sees it ... and I haven't even started on adding the Ajax support to it. T5 is the first *rewrite* of Tapestry since January 2000. There have been a few refactorings and reworkings since then, but the core code I wrote back then has served quite well; Jesse has been doing amazing things with Tapestry 4.1, seamlessly integrating client-side events into server-side method invocations. However, my inexperience at the time in creating the API, and the lack of modern tools such as annotations and Javassist, meant that adding new features almost always involved a break in backwards compatibility. The new code base is designed for productivity and efficiency and a minimal API. Much is available via naming conventions and annotations rather than rigid interfaces. I doubt there will even need to be a Tapestry 6, but compatibility in later Tapestry 5 releases will be a first class citizen.
  10. Howard, I am a real fan of Tapestry and have used it successfully on a lot of projects. Some of the things about Tapestry that could do with some improvement are 1. Lack of good books or tutorial support. There are hundreds of such books and tutorials on Struts for example. Without such a support its hard to really get up an running with Tapestry. 2. The only real book out there is your book but its still on Tapestry 3. The book by Tong Ka Iok is about Tapestry 4 and its a great but its really the only one out there. Given that Tapestry requires you to know a lot before you can start implementing websites using it, that acts as a serious hinderance. At the very least can we have good documentation on Tapestry 5 with a. Examples on how to implement key features b. How do you integrate with Spring, JSP and STRUTS for example. On my previous project I had a real hard time integrating Tapestry 4 with Spring, hence that would be real benefit. c. From the outset a "File download" component like an "File upload" one. This one is so frequently needed and while I built my own I wish I had it. Your book library application is great but its only useful when you know the nuts and bolts, hence it is very important for good and through tutorials depicting all features (like the book you have) to really get people on it. I am going to starting a new project in October and it would be great if Tapestry 5 is available by then as given all the stuff I am reading it makes less sense to go with Tapestry 4. Thanks, Sameer
  11. I've begun showing off T5 to users at my No Fluff Just Stuff speaking engagements and it floors everyone who sees it ... and I haven't even started on adding the Ajax support to it.
    Well Howard, of course you'll blow already Tapestry users to the floor when you boast about T5 to them. Developers get quickly fed up with particular way of doing things that becomes a routine and get always excited when a new way is introduced. So I can imagine the enthousiastic reactions from them. T5 can be innovative and productive but the real challenge would be selling it to new users. I've read your opinions in the past times and what I gather is that you place more emphasis on productivity and simplicity and less on making the learning curve of Tapestry less steep. A simple analogy is sometimes a piece of code of 10 lines being more comprehensible than a compact 3 lines equivalent that is labeled simple. With Tapestry 5, you're introducing another beast and bloat that would even be harder for newcomers to grasp. And also hard to explain in a book to beginners. And in the end no publisher would bet on a book contract with you. Like Tapestry in Action failed miserably. Because of your track record of breaking things, another challenge you'll face would be luring new users and keeping them. Tapestry has proved itself to be so fragile that a serious organization would be reluctant to consider it. Unless, of course there's a gun pointed to their head.
    I doubt there will even need to be a Tapestry 6, but compatibility in later Tapestry 5 releases will be a first class citizen.
    Ok, Howard, I believe you on this one. Because, left alone you, Tapestry 5 would now have been called Tapestry 4.5 or so. I've been a Tapestry user and followed the discussions on the Tapestry list about which version name to give to the the then next (currently Tapestry 5) release of Tapestry. You insisted on sticking with a 4.x until the mass protested and you changed your mind to go with a version 5. Some even thought the changes planned were so drastic and radical that it didn't even deserve the Tapestry title. So with this comment I've gotten even more scared of you because you might in the future bundle some radical changes in a 5.x series. Readers and Tapestry users, beware! Jan
  12. Golly gee whiz guys....[ Go to top ]

    You have me blushing here. Once again you've managed to take a thread about a completely different framework and spend the majority of the time discussing your insecurities about the framework you fear most - Tapestry. I can't blame you I guess ....but sometimes I'm not sure you realize how it looks after a while...It's always the same people posing the same arguments. We keep chugging along anyways. Always the first to innovate and always the first in line for your public deranged ranting. Me thinks though doth protest too much no? ;)
  13. Re: Golly gee whiz guys....[ Go to top ]

    Jesse, Why do think I'm scared of Tapestry? Why would I be scared of Tapestry when I don't have any competing product. Like I've mentioned on a thread here before, I've been a Tapestry user but got disappointed and frustrated by the craziness and all the hassles that came with any new release. I'm now a GWT user, and I didn't develop GWT. I'm also not on their developers list. I just want to open up things so that any current and future Tapestry user would make an informed decision based on what the future holds for them if they decide to go with it. As usual, I'm sorry you couldn't pick on some of the points I've mentioned in my previous posts but make those childish and baseless generalizations about my them. I didn't expect that from a Tapestry commiter. I expected a wiser response. Jan
  14. Re: Golly gee whiz guys....[ Go to top ]

    Oh I know Jan. You are just an innocent asking reasonable questions and being a good citizen right? The only problem with that logic is that it's always the same reasonable answer to the same reasonable "points" that you post in every Tapestry related thread. I've responded to those duplicate sets of points a number of times already - one has only to click on your name to see that. So I believe you, I ~really~ do. Wink wink, nudge nudge. ;)
    ...I just want to open up things so that any current and future Tapestry user would make an informed decision based on what the future holds for them if they decide to go with it...
  15. Comparison To Wicket
    Click is much simpler and easier to learn than Wicket. The Click API has some 83 odd classes (including the Click Extras), while Wicket API in comparison has 666 classes. This is a good thing.
    Wicket might have a lot of classes, but how many of those classes are users expected to interact with? And how many of them are just some utility classes, or internal? Besides, why would I learn Click? Maverick/Struts have like twenty classes! So it must be better. Servlets have what, like ten? Even better!
    The Click documentation is also outstanding, leaves Wicket for dead in this area.
    I didnt know Click has a book out, and another one on the way.
    Other benefits include the automatic HTML generation provided by Click components, this is a big productivity benefit.
    Also possible with Wicket, but not out of the box. This is great for prototyping fast, but why rewrite that stuff when its time to go to production? Whenever I have used a framework that provided auto-html generation in the past, we always had to tweak it so much that it become a huge pain. It was much easier to simply write the entire html for the page and be done with it. Besides, input type="text" wicket:id="tf". Did you clock that? How long did that take to type you think?
    You can do quite sophisticated form and table layouts in Click Java code with out having to write reams of HTML. For example you can have a Click form with a multiple column layout, multiple fieldsets and simply have in your HTML page: $form. Of course if you want you can manually layout forms for doing very fine grained UI design.
    It has always been our philosophy that html+css is a much better language for doing web layout then java. Feel free to disagree of course.
    Other Click benefits, include many more out of the box components
    You are kidding right?
    and the ClickIDE.
    Have you seen wicket-bench?
    Where Wicket has advantages over Click is in its support for persistent page state and AJAX.
    Other advantages include: Wicket is object oriented - since click doesnt handle state for the user it cannot be called object oriented. Wicket is component-oriented, not page-oriented. That means components can easily embed other components, and you are not limited to page-driven design. Eg a wicket application can consist of a single page, with all the other parts being swapped in and out across the lifetime of that page instance, like a desktop app. Wicket has 666/667? classes, that means you can find something that will fit your needs almost exactly, rather then having to roll your own.
  16. In my opinion, Click is quite nice, certainly compared to a lot of other alternatives (I would pick it over any model 2 framework at any time). If it is simplicity you are after AND you are developing relatively simple user interfaces, it may be a better pick than Wicket, which - I agree - probably has a higher learning curve. However, I do think that if you get into more complex tasks, you'll be able to maintain a clean programming model with Wicket, whereas with Click you'll have to start stacking workarounds.
    The good (imho of course): * small code base, thus easy to dig through * well documented API * pragmatic, while still providing what seems to be a decent programming model (at least as long as Click suffices for what you want to do). * like Wicket, it has header contribution support. * Uses Velocity, which imo is a much better alternative to JSP.
    The bad: * It's quasy OO at best (no automatic state handling, no real fine grained control over how components are created, etc) * like Tapestry, it is page oriented rather than component oriented. This severely limits the level of reusability that can be achieved. * The other side of having a framework that is 'simple and lightweight' is that it only supports relatively simple cases. This doesn't have to be a problem if it is easy toextend it's capabilities, but from the couple of hours I played around with it, I thought it really was a bit too basic for my taste.
    See also http://www.nabble.com/Creating-Entire-Forms-in-Java-Code-Only--tf3545176.html#a9946324
  17. * Uses Velocity, which imo is a much better alternative to JSP.
    One more note about that is that I'd prefer a real clean separation of presentation and logic, and using Velocity violates this. But I understand that some people prefer a more scripting based approach, in which case I would prefer Velocity over JSP. So I guess it is a relative + :)
  18. Where Wicket has advantages over Click is in its support for persistent page state and AJAX.
    Great advantages to use Wicket... :) Thanks for the info! :P
  19. Re: Click Framework 1.2 Released[ Go to top ]

    Congratulations i tried click back at ver 0.7 and it was amazingly simple yet powerfull soln. to the view layer its really nice and really simplifing the component architecture one of its stenghts is documentation,well documented with UML graphs everywhere makes it extremly fast to recognise the lifecycle hence immediate start using it BUT as its templating was velocity based ,composing page(from each other) was not that simple and not not html designer friendly as tapestry and wicket a second point is:the defining of the handler method and passing its name as string decrease the value of java development as there is no refactoring support
  20. Ajax integration[ Go to top ]

    Perhaps I missed it but I didn't seen any mention of Ajax integration in the documentation I quickly perused. Does it exist? If not, is it going to be added? It would be nice if the components provided Ajax functionality without the pain of the developer having to somehow integrate it manually.
  21. Re: Ajax integration[ Go to top ]

    Perhaps I missed it but I didn't seen any mention of Ajax integration in the documentation I quickly perused. Does it exist? If not, is it going to be added? It would be nice if the components provided Ajax functionality without the pain of the developer having to somehow integrate it manually.
    There you go - future bloat requests are already dooming Click. People will be saying in a year or so that Click version 5 has become too bloated with its own IoC container, AJAX components, service layer, etc. Time to move to the "Quick'n'Lean" framework version 1.01 because development on that bloated Click framework has become too difficult. It provides only the basic features you need to get up and running. Sorry, I don't mean to be bashing Click, per se. Just noting a pattern in framework design/software engineering in general. Another example: EJB because Corba is too hard and bloated. SOAP services, because EJB is too hard and bloated with all those transactionality, security, and guaranteed delivery services. No wait, REST services, because SOAP services are too hard and bloated with those WS* technologies - transactionality, security, guaranteed delivery, etc. No wait, AJAX/JSON services because XML is too heavy. No wait, ...
  22. Re: Ajax integration[ Go to top ]

    First off, I didn't request anything. I asked a couple of questions. Secondly, even if I did ask them to add Ajax support to Click it doesn't mean that it will suddenly (or ever) become bloated and unwieldy. Thirdly, Click (according to their website) is designed for use in enterprise development. Nowadays crap like Ajax is simply expected. Sticking your head in the sand and ignoring that fact is akin to telling your market you don't give a crap about their needs. What's the point of being lightweight if nobody uses your framework? I grant you that many frameworks are bloated but I've found that most of them pretty much started off that way. You can usually see it in the design of the framework early on. Click, on the other hand, doesn't give me that feel at all.
  23. Re: Ajax integration[ Go to top ]

    Click does not support AJAX out of the box, however its pretty easy to integrate simple AJAX stuff. For example: http://www.avoka.com:8080/click-examples/ajax/ajax.htm With most of the web applications I do, they have a little bit of AJAX here and there make the app feel more responsive. This is usually done on Select controls where you want to dynamically populate a list based on some other selection. I use the the Rico library in Click, as it has some cool feature and is very easy to use. If you have really crazy AJAX UI requirements, I think you would be better using Flex rather than some Java web application framework. regards Malcolm Edgar
  24. Re: Ajax integration[ Go to top ]

    yet one another quick start framework? Take a look at appfuse www.appfuse.org Sudhir Nimavat http://www.jyog.com
  25. Re: Click Framework 1.2 Released[ Go to top ]

    Yet Another Web Framework ? Why didn't you contribute to Wicket ?
  26. Re: Click Framework 1.2 Released[ Go to top ]

    Yet Another Web Framework ? Why didn't you contribute to Wicket ?
    Click has the same vintage as Wicket and they were both developed around the same time. People write http://click.sourceforge.net/docs/roadmap-changes.html Wicket however has had a lot more publicity. regards Malcolm Edgar
  27. I want to move away JSPs to a component framework. I have some experience with JSF and I was thinking this could be an option. We are currently using Spring MVC. Initially I want to do replace JSP as the view technology, but keep Spring MVC for the other parts. Later on, I might replace the whole presentation framework. What are the advantages of Click over JSF? Can I use click with Spring MVC? Any help would be greatly appreciated. Thanks.
  28. Is Click better than Wicket ?
  29. Can I use click with Spring MVC?
    Spring MVC is a action framework, so you have to use Click or Spring MVC, not both. But you can use Click with Spring, as the IoC container.
    What are the advantages of Click over JSF?
    I have evaluated both of them, and I found click easier. If you are going to use JSF, you probably use Facelets, Tomahawk, etc. Click also has goog view components (tables, panels, dateCalendar,etc). This kind of questions is difficult to answer.. sometimes it starts a new framework flame war. I guest you should evaluate both and take your conclusions... The first time I take a look at Click, I was using WW2. After read the click documentation I was very impressed with all the features and with the click 'simple' design. So that was my last ww2 project :-)... There's 6 months I'm using Click and I'm very satisfied with the results, since I can finish my application quickly and click has also an excellent performance. With Click, Wicket you can use OO, so it's possible to reuse more code. That's a good point. For example you can do a crud page like that: public class PersonCrudPage extends CrudPage{ protected Object getModel(){ return Person.class; } } And the abstract CrudPage does all the stuff. In the view layer I just have to write $form, that's done. Sometimes all the screens in the applications looks equal, so in my point of view doesn't make any since repeating my self, and write HTML + actions all the time. With Click I can reuse my pages. This is why I moved from WW2 to Click. WW2 does it job very well, it is an amazing framework, but I realized that for me, the Click 'Component and Page Oriented design' works very well. Sometimes there is some desired features that Click doesn't have, like AJAX, as said before. But is easier to customize the framework. You just need to override the toString() method of some Component and render some AJAX stuff, using some library like prototype. But of course, nowadays you need do it by yourself. regards,
  30. Thanks Ricardo for that. I will take a better look at Click. I am thinking that it might be possible to use JSF & Spring MVC. If I tell Spring MVC to render *.jsf views, I guess JSF will take control and render the page. Of course, I would not be able to uses events and things like that. All buttons & links will point to a Spring MVC action. In other words, I will use JSF to render my components and Spring MVC to control the flow, exceptions, ect. I don't know if this is possible. I will try & see. Cheers, Mauricio.
  31. I want to move away JSPs to a component framework. I have some experience with JSF and I was thinking this could be an option.

    We are currently using Spring MVC. Initially I want to do replace JSP as the view technology, but keep Spring MVC for the other parts. Later on, I might replace the whole presentation framework.

    What are the advantages of Click over JSF? Can I use click with Spring MVC?

    Any help would be greatly appreciated.

    Thanks.
    I haven't worked with JSF so I can really compare them. If you are using JSF I would imagine you would want to use one of the GUI tools to be productive. Otherwise you would probably need to be pretty hard core, if you to do it by hand. One of the things I don't like with the JSF approach is that you have lots of bits and pieces to manage, including Objects, JSPs, Tags and XML configurations. With Click its pretty well configuration free, you have a Page class where you do most of your work. The Page HTML template tend to be very simple, usually with a $form and $table reference. Most Click applications have a border HTML template which wraps your page HTML template. This is where you invest your time on the applications look and feel. The nice thing about this approach is that you only need to do it once. If you are using SpringMVC, I would recommend keeping the Spring IoC container with all your business stuff, and replace the MVC part with Click. Click has good support for Spring IoC, using the ClickSpringServlet. The online click-example application uses Spring for the IoC container and Cayenne for the ORM framework. regards Malcolm Edgar
  32. Hiya Malcolm, congrats on the release, looks good. I have to admit I have never understood all of the angst against JSF. I would imagine it is from people whom have used it without facelets. It isn't light-weight however - there is quite a learning curve for new users (less so for those with asp.net experience). I've used JSF on several projects, and in my experience it (coupled with myfaces/tomahawk/facelets/spring/hibernate) makes for a superbly productive combination. ATM, I'm been looking at tibco general interface with spring/xfire/hibernate. So far it seems amazing quick to build a responsive AJAX gui talking to the back-end with SOAP requests. Have you had a serious look at TIBCO GI and it's (limited) competitors? (As an aside: could it finally be a decently technology for portlets?) Best Regards, Hugh ps: I know GI has been around for a while but these days it works in more then one browser :)
  33. Hiya Malcolm, congrats on the release, looks good.

    I have to admit I have never understood all of the angst against JSF. I would imagine it is from people whom have used it without facelets.

    It isn't light-weight however - there is quite a learning curve for new users (less so for those with asp.net experience).

    I've used JSF on several projects, and in my experience it (coupled with myfaces/tomahawk/facelets/spring/hibernate) makes for a superbly productive combination.

    ATM, I'm been looking at tibco general interface with spring/xfire/hibernate.

    So far it seems amazing quick to build a responsive AJAX gui talking to the back-end with SOAP requests.

    Have you had a serious look at TIBCO GI and it's (limited) competitors?

    (As an aside: could it finally be a decently technology for portlets?)

    Best Regards,
    Hugh

    ps: I know GI has been around for a while but these days it works in more then one browser :)
    Hi Hugh, Nice to hear from you, I hope New Zealand is treating you well. Regarding JSF and Java web frameworks, I think if you are productive in with your current stack you would be mad to drop if for another stack. It simply takes along time to become proficient at them. On one job we swapped out Struts for SpringMVC (once Action pattern framework for another) and any productivity benefit was pretty well lost in the downtime getting staff up to speed on the new web framework. Never heard of TIBCO GI, I thought they made expensive messaging buses. I will take a look. regards Malcolm
  34. Heya, as mentioned - it's the Sydney hugh not the NZ one - although when we worked together Walcott and I had this problem all the time :) Someone elses comment about moving to component based versus page based is pertinent, imho we need to leakily abstract into a component model to chase asp.net (aka JSF on the server side or TIB GI on the client side). cheers
  35. Form generation?[ Go to top ]

    I'm looking for a UI component composition oriented framework that includes html form generation functionality. I.e. the option to have crud screens generated for a particular bean, including server side validation, rather than having to hand code, or even compose them myself. Is that what was meant by 'Automatic form rendering and client/server side validation'?
  36. Re: Form generation?[ Go to top ]

    Is that what was meant by 'Automatic form rendering and client/server side validation'?
    No. Automatic form rendering is because if you create a Form object and add some controls (TextField, Checkbox) it will generate the html source code automatically. Of course, you can do it manually too. And client/server validation because the Form will validate the fields on the server side (required fields, number, dates, regex, etc)... And if you set form.setJavaScriptValidation(true) it will generate the javascript validation in the client side.
  37. I have been using Click Framework for over four to five projects this past year and here's my impressions on the framework. But before I go on, I would like to say that before I worked with Click, I have used Struts 1.1, Web Work (currently Struts2), Spring MVC and Wicket. And so far out of all the frameworks, I find Click very simplistic in nature. WebWork (Struts2) would be my second choice. I think one of the drawbacks of Java compared with Ruby is that we end up writing 20 lines of code for a Hello World and scripted languages like ruby and python can do that with one or two line(s). My point here is not to say one language is superior to another. Each has it's place. But I feel that Click takes on the simplistic natural path for development. Traditionally, what most of us have gotten used to is the MVC model where the model is in a Form-Bean and the view is usually in a JSP page and the controller has the guts of how to drive between the two. Click and Wicket take a different approach (they are component based framework - like Tapestry)- where you lay down the html-form as a brick and mortar approach... you lay down one brick at a time as form-components and you let the "velocity" engine do the rendering. And of course, if you are not happy with the default layout, you can override it down to the nitty-gritty areas... And in the same way, you build event methods and attach them to buttons, anchor tags etc... so upon press it invokes the appropriate method to process which neatly lends itself to the Comet-Ajax approach we are getting to nowadays. But by comparison with Wicket, I find Click far easier to work with. Intuitive and elegant. And the base widgets available within Click are very clean and sharp. So far I have not had a need to add any new widgets for any the projects I have dealt with. The only gotcha or issue I came across is the in the Extras provided called the 'menu' widget. The Security model is tied closely with the application containers (Tomcat/WebLogic/Web Sphere) JEE declarative security model. And at this present time the Menu component is tied closely with the containers security so I ended up implementing my own menu component. I wish there was a way to override the "isUserInRoles()" method of Menu to implement against my own form-based authentication for the web site. And time-wise, I have noticed that I'm spending less time writing code and more time enjoying the simplicity of coding (which I call the zen-effect) as experienced when you code in Ruby or Python. I have to say congrats to the developers behind Click for coming up with a simple, elegant framework that makes the development a joy... And if you haven't given Click a try you should... http://click.sourceforge.net/