You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Daniel Ford <da...@gmail.com> on 2013/09/10 22:40:55 UTC
Comparison with Apache Wicket
Hi,
I noticed the mail about stopping development on Click.
Can someone of you compare Click with Apache Wicket<http://wicket.apache.org/>?
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
Posted by "Dennis M. J. Yerger" <de...@hotmail.com>.
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.ford@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 <de...@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.ford@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
Posted by Gilberto <gi...@gmail.com>.
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 <da...@gmail.com>
> 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<http://wicket.apache.org/>?
>> 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
Posted by Daniel Ford <da...@gmail.com>.
Hi Dennis,
Thank you for your answer!
On Wed, Sep 11, 2013 at 1:06 AM, Dennis M. J. Yerger <
dennisyerger84@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.ford@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<http://wicket.apache.org/>?
> 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
Posted by "Dennis M. J. Yerger" <de...@hotmail.com>.
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.ford@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
Posted by "Dennis M. J. Yerger" <de...@hotmail.com>.
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.ford@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 <sa...@gmail.com> 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 <da...@gmail.com> wrote:
Hi Bob,
On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com> 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
Posted by Daniel Ford <da...@gmail.com>.
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 <sa...@gmail.com> 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 <daniel.clarke.ford@gmail.com
> > 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 <sa...@gmail.com> 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.ford@gmail.com> wrote:
>>>
>>>> Hi Bob,
>>>>
>>>>
>>>> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com>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<http://wicket.apache.org/>?
>>>>> 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
Posted by Bob Schellink <sa...@gmail.com>.
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
<da...@gmail.com>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 <sa...@gmail.com> 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.ford@gmail.com> wrote:
>>
>>> Hi Bob,
>>>
>>>
>>> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com> 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<http://wicket.apache.org/>?
>>>> 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
Posted by Daniel Ford <da...@gmail.com>.
@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 <sa...@gmail.com> 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.ford@gmail.com
> > wrote:
>
>> Hi Bob,
>>
>>
>> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com> 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<http://wicket.apache.org/>?
>>> 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
Posted by Bob Schellink <sa...@gmail.com>.
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
<da...@gmail.com>wrote:
> Hi Bob,
>
>
> On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com> 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<http://wicket.apache.org/>?
>> 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
Posted by Daniel Ford <da...@gmail.com>.
Hi Bob,
On Wed, Sep 11, 2013 at 5:35 PM, Bob Schellink <sa...@gmail.com> 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<http://wicket.apache.org/>?
> 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
Posted by Bob Schellink <sa...@gmail.com>.
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 <http://wicket.apache.org/> ?
> 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
Posted by Daniel Ford <da...@gmail.com>.
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 <rl...@gmail.com>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 <daniel.clarke.ford@gmail.com
> > wrote:
>
>> Hi,
>>
>> I noticed the mail about stopping development on Click.
>>
>> Can someone of you compare Click with Apache Wicket<http://wicket.apache.org/>?
>> 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
Posted by Ricardo Lecheta <rl...@gmail.com>.
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
<da...@gmail.com>wrote:
> Hi,
>
> I noticed the mail about stopping development on Click.
>
> Can someone of you compare Click with Apache Wicket<http://wicket.apache.org/>?
> 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