RE: Comparison with Apache Wicket

[Dennis M. J. Yerger]

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: daniel.clarke.f...@gmail.com
Date: Mon, 16 Sep 2013 14:40:03 +0300
Subject: Re: Comparison with Apache Wicket
To: dev@click.apache.org

@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  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  
wrote:



Hi Bob,


On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink  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

  



  







  

Re: Comparison with Apache Wicket

[Daniel Ford]

Yes.
I've spent enough time investigating Click. It is not for me.
Ricardo Lecheta said that it is simple/easy. No offense but I think the
real term that should be used is "basic".

Thank you all for your opinions!



On Mon, Sep 16, 2013 at 3:41 PM, Bob Schellink  wrote:

> Like I said, Click is a stateless framework with stateful capabilities.
> Sounds like your requirements is to be stateful with some stateless
> capabilities?
>
> Sounds like Wicket is a better bet for your application.
>
> Kind regards
>
> Bob
>
> On Mon, Sep 16, 2013 at 1:40 PM, Daniel Ford  > wrote:
>
>> @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.javaone
>>  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  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 <
>>> daniel.clarke.f...@gmail.com> wrote:
>>>
 Hi Bob,


 On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink 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
>
>
>

>>>
>>
>

Re: Comparison with Apache Wicket

[Bob Schellink]

Like I said, Click is a stateless framework with stateful capabilities.
Sounds like your requirements is to be stateful with some stateless
capabilities?

Sounds like Wicket is a better bet for your application.

Kind regards

Bob

On Mon, Sep 16, 2013 at 1:40 PM, Daniel Ford
wrote:

> @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.javaone
>  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  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 <
>> daniel.clarke.f...@gmail.com> wrote:
>>
>>> Hi Bob,
>>>
>>>
>>> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink  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



>>>
>>
>

Re: Comparison with Apache Wicket

[Daniel Ford]

@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.javaone
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  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  > wrote:
>
>> Hi Bob,
>>
>>
>> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink  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
>>>
>>>
>>>
>>
>

Re: Comparison with Apache Wicket

[Bob Schellink]

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

> Hi Bob,
>
>
> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink  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
>>
>>
>>
>

Re: Comparison with Apache Wicket

[Daniel Ford]

Hi Bob,


On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink  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
>
>
>

RE: Comparison with Apache Wicket

[Dennis M. J. Yerger]

Hi Daniel.  I would admit Velocity macros would require more typing, but I 
almost never use macros in my own templates.  I mostly use Velocity to access 
the page model, which contains the page's Click controls. Including a Click 
control is simple as including the control's name in the template whereas with 
a Wicket component you have to include a whole tag to get the same results. I'm 
sure the designers of Wicket had their reasons for having it that way, but for 
me the Click approach is simpler. 

From: daniel.clarke.f...@gmail.com
Date: Wed, 11 Sep 2013 14:59:31 +0300
Subject: Re: Comparison with Apache Wicket
To: dev@click.apache.org

Hi Dennis,

Thank you for your answer!


On Wed, Sep 11, 2013 at 1:06 AM, Dennis M. J. Yerger 
 wrote:





I have experience with both Click and Wicket, and while they are both 
component-based frameworks, they are very different in how they handle pages. 
Click uses Velocity by default for its page templates, while Wicket uses HTML 
with a custom namespace mixed in. I prefer the Velocity approach because you 
get the same results with less typing.



I'm not sure that I understand how plain HTML (Wicket) is more typing than 
plain HTML + Velocity macros (conditions, loops, etc.)
 


Click's page classes resemble Swing in how they are constructed: set 
properties, add listeners, and you're ready to go. Wicket classes are similar, 
but you have to override so many methods to get the desired result. 



This is to save memory at the server. A property would be saved (in http 
session, disk, ...). An overridden method has no state - just ask it to return 
the state/setting.


 
As far as I know, Wicket pages persist between requests while Click pages are 
constructed for each request. Wicket relies on a Java class rather than 


Wicket can work as Click - just use stateless components and the page will be 
re-created for each request.
As soon as you add the first stateful component or behavior the page will be 
stored for later requests.


 an XML document to make settings while Click uses click.xml by default. Wicket 
uses the concept of models for its components much like Swing. Click relies 
less on this concept, making it simpler to work with.



I have no much experience with Click and I cannot see how it makes this simpler.
But yes initially models in Wicket are not so easy to grasp.
 


So far, the XML-free configuration is the only advantage I like in Wicket. 
Otherwise, I would use Click.



From: daniel.clarke.f...@gmail.com
Date: Tue, 10 Sep 2013 23:40:55 +0300
Subject: Comparison with Apache Wicket
To: dev@click.apache.org



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

  


  

Re: Comparison with Apache Wicket

[Bob Schellink]

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.


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

Re: Comparison with Apache Wicket

[Gilberto]

Hi, Daniel! Welcome to Click Framework community.

Don't take my words as offense, I've done this same task (compare without
trying) as well.

It seems that anything we say about click(productivity and ease) will not
convince you. :)
The answer? There is no answer! You know Wicket better!
You have not experienced or tried anything concrete with Click. Do
something with it and tell us if the Click Framework fits you needs in some
project.

Regards,

Gilberto

2013/9/11 Daniel Ford 

> Hi Dennis,
>
> I have no much experience with Click and I cannot see how it makes this
> simpler.
> But yes initially models in Wicket are not so easy to grasp.
>
>
>> 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
>>
>
>

Re: Comparison with Apache Wicket

[Daniel Ford]

Hi Dennis,

Thank you for your answer!


On Wed, Sep 11, 2013 at 1:06 AM, Dennis M. J. Yerger <
dennisyerge...@hotmail.com> wrote:

> I have experience with both Click and Wicket, and while they are both
> component-based frameworks, they are very different in how they handle
> pages. Click uses Velocity by default for its page templates, while Wicket
> uses HTML with a custom namespace mixed in. I prefer the Velocity approach
> because you get the same results with less typing.
>

I'm not sure that I understand how plain HTML (Wicket) is more typing than
plain HTML + Velocity macros (conditions, loops, etc.)


>
> Click's page classes resemble Swing in how they are constructed: set
> properties, add listeners, and you're ready to go. Wicket classes are
> similar, but you have to override so many methods to get the desired
> result.
>

This is to save memory at the server. A property would be saved (in http
session, disk, ...). An overridden method has no state - just ask it to
return the state/setting.


>
> As far as I know, Wicket pages persist between requests while Click pages
> are constructed for each request. Wicket relies on a Java class rather than
>

Wicket can work as Click - just use stateless components and the page will
be re-created for each request.
As soon as you add the first stateful component or behavior the page will
be stored for later requests.


> an XML document to make settings while Click uses click.xml by default.
> Wicket uses the concept of models for its components much like Swing. Click
> relies less on this concept, making it simpler to work with.
>

I have no much experience with Click and I cannot see how it makes this
simpler.
But yes initially models in Wicket are not so easy to grasp.


>
> So far, the XML-free configuration is the only advantage I like in Wicket.
> Otherwise, I would use Click.
>
> --
> From: daniel.clarke.f...@gmail.com
> Date: Tue, 10 Sep 2013 23:40:55 +0300
> Subject: Comparison with Apache Wicket
> To: dev@click.apache.org
>
>
> 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
>

Re: Comparison with Apache Wicket

[Ricardo Lecheta]

click is easy ,wicket is not so easy
click is small, few things to learn... wicket is bigger
click is simple, wicket is not so simple

wicket may have more funcionallities, since the goal of click framework is
make it simple to learn and use.


On Tue, Sep 10, 2013 at 5:40 PM, 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
>



-- 
Ricardo Lecheta

RE: Comparison with Apache Wicket

[Dennis M. J. Yerger]

I have experience with both Click and Wicket, and while they are both 
component-based frameworks, they are very different in how they handle pages. 
Click uses Velocity by default for its page templates, while Wicket uses HTML 
with a custom namespace mixed in. I prefer the Velocity approach because you 
get the same results with less typing.  

Click's page classes resemble Swing in how they are constructed: set 
properties, add listeners, and you're ready to go. Wicket classes are similar, 
but you have to override so many methods to get the desired result. 

As far as I know, Wicket pages persist between requests while Click pages are 
constructed for each request. Wicket relies on a Java class rather than an XML 
document to make settings while Click uses click.xml by default. Wicket uses 
the concept of models for its components much like Swing. Click relies less on 
this concept, making it simpler to work with.

So far, the XML-free configuration is the only advantage I like in Wicket. 
Otherwise, I would use Click.

From: daniel.clarke.f...@gmail.com
Date: Tue, 10 Sep 2013 23:40:55 +0300
Subject: Comparison with Apache Wicket
To: dev@click.apache.org

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

  

Re: Comparison with Apache Wicket

[Daniel Ford]

Ricardo,

These are very general statements.

click is dead/dying, wicket is alive..

I'd like to hear some technical facts.

Thank you!

On Tue, Sep 10, 2013 at 11:44 PM, Ricardo Lecheta wrote:

> click is easy ,wicket is not so easy
> click is small, few things to learn... wicket is bigger
> click is simple, wicket is not so simple
>
> wicket may have more funcionallities, since the goal of click framework is
> make it simple to learn and use.
>
>
> On Tue, Sep 10, 2013 at 5:40 PM, 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
>>
>
>
>
> --
> Ricardo Lecheta
>