Daniel, a Java-centric approach may not appeal to you if you prefer to construct most of your page in HTML. That's pretty much how Click works; construct the dynamic elements of the page as Java objects and insert them into the template. However, Wicket works much the same way, except when using it I feel as though I am constructing the elements twice, once in Java and again in HTML. I'd rather construct them once in Java, the language I am most comfortable with. Of course, I understand that this approach does not work for everyone, which is apparently why so many Java Web frameworks exist in the first place.
From: [email protected] Date: Mon, 16 Sep 2013 14:40:03 +0300 Subject: Re: Comparison with Apache Wicket To: [email protected] @Bob - Thanks for the links! I'm not sold on this approach. It is way too manual for my taste. @Dennis - I see what you meant with "less HTML to write". Looking at http://click.avoka.com/click-examples/source-viewer.htm?filename=WEB-INF/classes/org/apache/click/examples/page/table/SearchTablePage.java one can see code like: editLink.setImageSrc("/assets/images/table-edit.png"); editLink.setTitle("Edit customer details"); editLink.setParameter("referrer", "/table/search-table.htm"); so you write your HTML in the Java file ... Not sold again. On Thu, Sep 12, 2013 at 3:12 PM, Bob Schellink <[email protected]> wrote: There isn't much doco except for the javadoc: http://click.apache.org/docs/click-api/org/apache/click/Stateful.html Here is an example: http://click.avoka.com/click-examples/table/search-table.htm It is very basic and light-weight. A control can store and restore it's state in the session. You could look at Table and ClickUtils on how it's done. regards Bob On Thu, Sep 12, 2013 at 1:46 PM, Daniel Ford <[email protected]> wrote: Hi Bob, On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <[email protected]> wrote: Hi Daniel, Couple of years ago I've answered this question on StackOverflow: http://stackoverflow.com/questions/2168249/apache-wicket-vs-apache-click I think it the answer is still relevant today. One change is that stateful pages have been deprecated in Click. Instead the notion of stateful components was added. We've found that stateful pages wasn't a good fit in Click. As can be expected the conceptual model between a stateful and stateless page is vast, almost like coding in two different frameworks which is bad for maintenance. Stateful components seems a better fit as one has fine control over what and when to store state. Where I can read more about how stateful components work ? Since the page is not stored how a following http request finds the stateful component ? Where the component is stored ? Or maybe just its state is preserved at the client (cookie, request parameter, ...) ? I'll be thankful if you send me a link to a document or even to the code dealing with this logic. I believe Click would be easier to learn and get going. With Wicket one should be able to create more complicated UI's as all state is preserved. Looking at the click-examples should give a good idea of the type of applications one would normally write with Click. As you can see it very web like, instead of desktop like. Hope this helps. Kind regards Bob On 2013/09/10 22:40, Daniel Ford wrote: Hi, I noticed the mail about stopping development on Click. Can someone of you compare Click with Apache Wicket ? If you have experience with both frameworks I'll be glad to hear what you believe Click does better than Wicket and what is better in Wicket. Thank you in advance! Daniel
