" 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."

"i tried click back at ver 0.7 and it was amazingly simple yet powerfull soln. to the view layer"

"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"

"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 "

"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."

"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."

"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."

"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."

"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?"

" +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?"

" 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. "

"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."

"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."

"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."

"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. "

" Click does not support AJAX out of the box, however its pretty easy to integrate simple AJAX stuff. For example:"

"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."

" 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. "

"Spring MVC is a action framework, so you have to use Click or Spring MVC, not both."

"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..."

"After read the click documentation I was very impressed with all the features and with the click 'simple' design. "

"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: "

"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."

"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
... read the whole article