After three milestone releases Click 1.4 final, a component and page-oriented web frameworkis available for download. Major features include stateful page support, component event methods and a performance filter that helps you apply Yahoo Performance Rules. Important links:

• Download Click 1.4
• Click Home
• Live examples – Java source and markup is available with every example
• Core-API
• Extras-API
• ClickIDE

Click is a page and component oriented Java web framework. There are no unnecessary abstractions or complex concepts to learn and understand. Commercial developers should be up and running within a day. Pages and components are developed in Java while layouts are specified in Velocity or JSP. Components know how to render themselves so developers don't have to maintain redundant markup. Highlights for 1.4 includes:

• Stateful page support which makes developing complex pages and page flows much easier.
• New Control event methods - onInit(), onRender() and onDestroy().
• New PerformanceFilter enables your applications Yahoo style performance with very little effort.
• New AutoCompleteTextField control gives you Ajax auto-complete functionality.
• New Ant task to quickly build application templates.
• Added support for Cayenne ORM versions 2.x and 3.x.
• ThreadLocal Context support which provides you access to the Context in page constructors.
• Lots more code examples and design patterns on click-examples.
• Performance improvements.

Highlights for ClickIDE, the Eclipse plugin:

• Support for Spring and Cayenne.
• Added Cayenne Modeler launcher.
• Improved Velocity code completion.

Enjoy Click.

I hope people take some time to check Click out. This framework has been focused on simplicity and productivity for a long time. Long before it was fashionable. Also take a look at some of the blogs: http://click-framework.blogspot.com/ http://www.glenstampoultzis.net/blog/?p=48 regards Malcolm Edgar Click Developer

I see from the examples that the approach taken is very similar to Wicket, with some minor differences in the way code is bound to the templates.. What are the major differences from Wicket (for better and for worse)? I've come to love Wicket, and I'm happy to see that similar frameworks are coming out, it proves that this is the way forward going beyond the abominations that are Struts and JSF..

Hi Willie,

I see from the examples that the approach taken is very similar to Wicket, with some minor differences in the way code is bound to the templates..
What are the major differences from Wicket (for better and for worse)?

* Click took a more traditional approach by not introducing too many abstractions. For example the Servlet API is still fully exposed. In fact the only real abstraction is the Control interface. * Wicket is stateful by design, Click stateless. * I believe Click would be easier to learn and understand. (For me it is important to have a thorough understanding of surrounding technologies in order to be productive and have fun) * In Click every control knows how to "draw" itself. For example:

new TextField().toString()

will produce

No need to maintain this in the markup as well. Templates are mostly used for creating your border page.

I've come to love Wicket, and I'm happy to see that similar frameworks are coming out, it proves that this is the way forward going beyond the abominations that are Struts and JSF..

Yessir I find JSF to be bad for my health ;-) Btw Click has been around for awhile now. kind regards bob

Click and Wicket are about the same age, and undoubtedly have had some influence from Tapestry. Probably the biggest differences between Click and Wicket are: * Click is a Page oriented framework compared to Wicket which is more component oriented. There is a bit of grey area in this comment, as Click has controls which are very much like components. This difference has advantages and disadvantages, as with all things. Click is faster/easier for doing simpler things, while Wicket is probably better for handling more complex problems. * Click uses a stateless design (principally) while Wicket uses a stateful design. The advantage for a stateless design is that it can be more performant/scalable, but is more difficult to develop with when handling more complex UI problems. Benchmarks we have show Click is more performant than Wicket, but in the big picture I don't think this is that important. The big change in this release for Click is the support for stateful pages, which makes tackling those more complex UI scenarios and page flows much easier. regards Malcolm Edgar http://click.sourceforge.net

I have a very positive experience with Click Framework. It’s very easy to create something without to fight with some abstraction level. Most things I ever have used in Click are very fluent and reasonable. For those who prefer tight ORM integration the Apache Cayenne is being supported and integrated very well. With a new ClickIDE version the new application setup, that combines Click + Cayenne + Spring, is quite easy. I can honestly encourage anyone to try it as it is very nice to develop with. I have to mention also that Click is very fast in production. And final note, what I really like about Click, are the logging levels. As a developer one can easily setup Click logging level. Using this, on server console, you get helpful info, not just some secret java messages. Here is an example of what you can see in lowest logging level when Click is processing the request. It’s a mix of Click and Apache Cayenne logging info. Its many lines but you can see what Click is doing in details. ###################################################################x [Click] [debug] GET http://localhost:8080/extjs_user_management/auth/register.htm [Click] [trace] invoked: Register.<> [Click] [trace] invoked: Register.onSecurityCheck() : true INFO - --- will run 1 query. INFO - Opening connection: jdbc:postgresql://localhost:5432/extjs_auth Login: postgres Password: ******* INFO - +++ Connecting: SUCCESS. INFO - --- transaction started. INFO - Detected and installed adapter: org.apache.cayenne.dba.postgres.PostgresAdapter INFO - SELECT t0.description, t0.name, t0.id FROM Role t0 ORDER BY t0.name - prepared in 110 ms. INFO - === returned 4 rows. - took 688 ms. INFO - +++ transaction committed. [Click] [trace] invoked: Register.onInit() [Click] [trace] invoked: 'form' Form.onInit() [Click] [trace] invoked: 'form' Form.onProcess() : true [Click] [trace] invoked: Register.onGet() [Click] [trace] invoked: Register.onRender() [Click] [trace] invoked: 'form' Form.onRender() [Click] [info ] renderTemplate: /auth/register.htm,layouts/layout_logged.htm - 125 ms [Click] [trace] invoked: 'form' Form.onDestroy() [Click] [trace] invoked: Register.onDestroy() [Click] [info ] handleRequest: /auth/register.htm - 1344 ms [Click] [debug] POST http://localhost:8080/extjs_user_management/auth/register.htm [Click] [trace] request param: email=df at df dot cz [Click] [trace] request param: firstname=David [Click] [trace] request param: form_name=form [Click] [trace] request param: lastname=Marko [Click] [trace] request param: login=password [Click] [trace] request param: ok= Zaregistrovat [Click] [trace] request param: password=password [Click] [trace] invoked: Register.<> [Click] [trace] invoked: Register.onSecurityCheck() : true INFO - --- will run 1 query. INFO - --- transaction started. INFO - SELECT t0.description, t0.name, t0.id FROM Role t0 ORDER BY t0.name INFO - === returned 4 rows. - took 0 ms. INFO - +++ transaction committed. [Click] [trace] invoked: Register.onInit() [Click] [trace] invoked: 'form' Form.onInit() [Click] [debug] Form -> Contact.firstname : David [Click] [debug] Form -> Contact.lastname : Marko [Click] [debug] Form -> Contact.email : df at df dot cz [Click] [debug] Form -> Contact.login : password [Click] [debug] Form -> Contact.password : password INFO - --- transaction started. INFO - INSERT INTO Contact (email, enabled, firstname, id, lastname, login, password, phone) VALUES (?, ?, ?, ?, ?, ?, ?, ?) INFO - [batch bind: 1->email:'df at df dot cz', 2->enabled:NULL, 3->firstname:'David', 4->id:260, 5->lastname:'Marko', 6->login:'password', 7->password:'password', 8->phone:NULL] INFO - === updated 1 row. [Click] [trace] invoked: 'form' Form.onProcess() : true [Click] [trace] invoked: Register.onPost() [Click] [trace] invoked: Register.onRender() [Click] [trace] invoked: 'form' Form.onRender() [Click] [info ] renderTemplate: /auth/register.htm,layouts/layout_logged.htm - 15 ms [Click] [trace] invoked: 'form' Form.onDestroy() [Click] [trace] invoked: Register.onDestroy() [Click] [info ] handleRequest: /auth/register.htm - 875 ms###################################################################

Big thumbs up for a project that understands the importance of decent documentation. Good luck! Kit

I've been using Click for sometime now... I love it... I'm amazed at the simplicity of it... Great work guys... Venkatt

great work !!! I've been using Click almost two years, and it's really impressive how new developers can learn the framework in a very few time, of course with all the Click docs, no excuses ;-). regards,

Are there any examples on performing validation of form fields? Rgds, Chandru

Try for example this: http://www.avoka.com:8080/click-examples/form/form-properties.htm But the entire example site uses form validation on many pages. David

There are some good examples online with: http://www.avoka.com:8080/click-examples/form/form-properties.htm http://www.avoka.com:8080/click-examples/form/standard-controls-form.htm http://www.avoka.com:8080/click-examples/form/extra-controls-form.htm A significant difference with Click and other Java web frameworks, it that in Click the validation logic is contained in the Controls and you don't have to wire up Validator objects to Field object, and then set JavaScript key filters. Instead Click as controls for most types of input: EmailField, NumberField, RegexField, TelephoneField etc. regards Malcolm Edgar http://click.sourceforge.net

I wonder if working with ajax in click is as easy as in wicket..

Hi Maris, From what I can see Wicket created their own Ajax library to provide "built-in" support. Is this what you are referring to? Having a quick look around the web this is what a Wicket URL looks like by default:

I guess Wicket provide its own Ajax library to make integration easier? In Click this is what a URL looks like:

So its pretty simple to enable Ajax callbacks. Click Controls can also deploy their own javascript dependencies. As a side note, I wonder why the "Ajax out of the box" is such a hit in server-side frameworks? I mean the javascript guru's already provide excellent libraries like Prototype, Scriptaculous, JQuery, Mootools, Mockikit etc. Can one really replace the Javascript language with a few Java API calls? kind regards bob

I dont want to hijack this thread and start yet another theserverside our framework is better then yours flamewar, just want to clarify some things since you guys are talking about wicket...

From what I can see Wicket created their own Ajax library to provide "built-in" support.

Yes we have. The reason for that was not to make callbacks easy, but rather to support transparent partial-page renders. What our javascript framework allows us to do is to render any number of components into an xml envelope, send that to client side, and have the html put into the right place in the dom tree. So if you have a page that consists of ten panels, and you want to repaint just two of them via ajax instead of refreshing the entire page, it is as easy as ajaxRequestTarget.add(panel1, panel2); The only existing javascript framework that provided support for this at the time was rico, but it had some issues, so we rolled our own. All our javascript stuff is namespaced, so it wont interfere with any other js lib you may want to use for other stuff.

Having a quick look around the web this is what a Wicket URL looks like by default:

I guess Wicket provide its own Ajax library to make integration easier?

This is what a url on a stateful page looks like. I assume your click url pointed to a stateless page? :) We have a wide variety of urlFor() methods that create urls to pages/components - so having that url is no problem. But we also provide a wide variety of basic ajax building blocks that encapsulate ajax event invocation from clientside so you never actually have to write urls yourself.

As a side note, I wonder why the "Ajax out of the box" is such a hit in server-side frameworks? I mean the javascript guru's already provide excellent libraries like Prototype, Scriptaculous, JQuery, Mootools, Mockikit etc. Can one really replace the Javascript language with a few Java API calls?

I believe the reason for it is that java developers do not want to learn javascript or any of these frameworks, at least this is what our users tell us. They know java and that is what they want to use. You have to admit that doing

add(new AjaxLink("repaint-stats") { protected void onClick(AjaxRequestTarget target) { updateStats(); target.add(statsPanel); });

has a certain allure about it...I didnt have to write javascript to call the serverside, I did not have to marshal my stats bean into json or what have you on server side, I did not have to unmarshal it on the client, I did not have to write dom manipulation to update whatever markup the stats bars use. Granted, of course, that sending over a json representation is cheaper on network load then the rendered markup of the panel; but you can still choose to do that if you want to deal with all that... cheers, -Igor

So if you have a page that consists of ten panels, and you want to repaint just two of them via ajax instead of refreshing the entire page, it is as easy as ajaxRequestTarget.add(panel1, panel2);

Ah, I understand. Thanks for clarifying. To answer the original question then: No Click does not provide its own integrated Ajax support. Click's support for Ajax is more loosely coupled like you would get with PHP. Meaning you can use Velocity to script up the xml / JSON payload and Click to manage the callback. An example of this is ajax select.

I assume your click url pointed to a stateless page? :)

Click is stateless by design so all URL's look like that. Even stateful pages.

I believe the reason for it is that java developers do not want to learn javascript or any of these frameworks, at least this is what our users tell us. They know java and that is what they want to use. You have to admit that doing

add(new AjaxLink("repaint-stats") { protected void onClick(AjaxRequestTarget target) { updateStats(); target.add(statsPanel); });

has a certain allure about it...

It does look good as long as the abstraction does not leak. Because if that happens the developer being protected from evil javascript will have to face it anyway. Personally from production experience I prefer being exposed to the underlying technologies. I can sleep more peacefully, if you know what I mean ;-) My question is really not to dis Wicket or any other framework adopting this strategy (especially if users demand it). I just find it a bit strange that front-end developers want to be shielded from Javascript. With the current plethora of Ajax libs I think knowing at least one of them is a very good tool to add to your skill set. kind regards bob

It does look good as long as the abstraction does not leak. Because if that happens the developer being protected from evil javascript will have to face it anyway.

Seems to hold the water in pretty well so far...

Personally from production experience I prefer being exposed to the underlying technologies. I can sleep more peacefully, if you know what I mean ;-)

I guess this is where our outlooks diverge. I believe it is enough to understand the underlying technologies, being directly exposed to them when there is a better abstraction is more of a hindrance in my eyes. I understand how javac transforms my code into bytecode, that doesnt mean I can't sleep soundly at night unless I spend my day writing bytecode by hand :)

I believe it is enough to understand the underlying technologies, being directly exposed to them when there is a better abstraction is more of a hindrance in my eyes.

Yep when there is a better abstraction I agree. ;-)

It does look good as long as the abstraction does not leak. Because if that happens the developer being protected from evil javascript will have to face it anyway.

Seems to hold the water in pretty well so far...

I think its important to note that in Wicket, there is nothing stopping you from creating your own reusable Javascript- and Ajax-enabled components, in fact its dead simple. The only thing is, you only need to know about it and be exposed to the underlying technologies if you really want to do some custom work and available components are not what you are looking for.

Hi Igore thanks for the info on Wickets AJAX support. regards Malcolm Edgar

I can't really compare it to Wicket's AJAX support as I haven't used Wicket commercially. Working with AJAX is pretty good in Click. I wouldn't say it is as easy as the rest of the framework. The first out of the box Click AJAX component is the AutoCompleteField which provide Google suggest style functionality. Please see the example below: http://www.avoka.com:8080/click-examples/ajax/auto-complete.htm Click uses the 'prototype' and 'script.aculo.us' JavaScript libraries. There are quite a few AJAX examples online at Click Examples, under the General menu. Click also has good in built support for JavaScript to do client side validation, and provide sophisticated controls. For example please see the PickList control below: http://www.avoka.com:8080/click-examples/control/pick-list-demo.htm regards Malcolm Edgar

I just tried the demo of the AutoCompleteField, and it's broken in both Firefox and IE7. It loads as expected, and does indeed offer suggestions, but if you use the arrow keys to navigate to a selection, and hit enter, the value is filled in to the box, and then immediately overwritten with the partial value.

I just tried the demo of the AutoCompleteField, and it's broken in both Firefox and IE7. It loads as expected, and does indeed offer suggestions, but if you use the arrow keys to navigate to a selection, and hit enter, the value is filled in to the box, and then immediately overwritten with the partial value.

Hi Andy, Thanks for your feedback. You are right, it seems this version of scriptaculous submits the form when enter is pressed. Will upgrade to scriptaculous 1.8.1 for the next point release (1.4.1) around the end of March / beginning of April. Thanks again.

Congratulations to all you guys for Click 1.4. My experience with click has been great. It is simple to understand and use and has good documentation. Comes with a whole lot of built in controls and does not take any time to get up and started. Keep up the good work :) Deepak

Hi All, I'm about to embark on the development of an Enterprise Java Application (JEE), however, I came across this post about the Click Framework for which I did some reading up on it, and I must say that I'm blown away about how simple and elegant this framework appears to be (Much more than Struts and JSF). Can someone advise me on their experience in using this framework in any Enterprise Java Application (Particularly in a clustered application server environment), as I'm willing to give this framework a shot in terms of using it for my project. Thanks All.

Hi Douglas,

Hi All,

I'm about to embark on the development of an Enterprise Java Application (JEE), however, I came across this post about the Click Framework for which I did some reading up on it, and I must say that I'm blown away about how simple and elegant this framework appears to be (Much more than Struts and JSF). Can someone advise me on their experience in using this framework in any Enterprise Java Application (Particularly in a clustered application server environment)

This question is a bit difficult to answer since clustering is really the domain of the J2EE container. And each one is different. But in short since Click is stateless, it should be relatively easy to achieve high availability and scalability. Note I said "relatively" ;-). It really depends on your J2EE container. By default Click does not store any state in the session. If you make use of stateful pages however you need to be very careful, because the Page is stored in the session and will be synchronized to other nodes in the cluster. Personally I like storing state in the database, leaving the web-tier stateless, simple and easy. I suggest you take Click for a small pilot. You can even try and cluster the Click examples.war and see if you run into any problems :) kind regards bob

Thanks for the advise Bob. Do you have any info on who's using Click and for what? Thanks again, good job.

Thanks for the advise Bob. Do you have any info on who's using Click and for what?

Good question. We don't have a "portfolio" of who uses Click for what. Perhaps we should start one ;-) As far as public facing websites I can tell you is that this site: https://www.formcentral.net.au/myformcentral/home.htm was developed by Avoka. I also assume that people on the mailing list use it: http://www.nabble.com/click-user-f3305.html kind regards bob

It would be nice to start that portfolio. I think this framework is going to make it big as it seems to achieve the ease of web development that Java developers have been seeking for years now in the web development space. This framework further proves that open source development and developers are the linchpin of the software development technology space as large commercial tech companies with all their billions in R&D have failed to just get it done right. Java web development may have just been saved. Thanks Team. Regards, DA.

Java web development may have just been saved.

:) Thanks for the nice comments. Its much appreciated.

Telstra use Click Framework for one of their Online Ordering Tools (Telstra is the largest Telco in Australia). I can't provide you with this URL as its principly for resellers and internal staff. But if you send me an email off this forum, I can probably provide you with more details. If you raise this question in the Click Framework newsgroup you should also get some more examples. regards Malcolm Edgar medgar@avoka.com

Doug, One other thing to note with Click is that it is extremely performant. This latest release has just raised the bar ever higher with the PerformanceFilter, to get a feel for this look at: http://www.avoka.com/click-examples/home.htm Use YSlow Mozilla plugin to see what is happening under the covers. regards Malcolm Edgar