Return-Path: X-Original-To: apmail-click-dev-archive@www.apache.org Delivered-To: apmail-click-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 92AF810130 for ; Thu, 12 Sep 2013 12:12:47 +0000 (UTC) Received: (qmail 93469 invoked by uid 500); 12 Sep 2013 12:12:47 -0000 Delivered-To: apmail-click-dev-archive@click.apache.org Received: (qmail 93447 invoked by uid 500); 12 Sep 2013 12:12:46 -0000 Mailing-List: contact dev-help@click.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@click.apache.org Delivered-To: mailing list dev@click.apache.org Received: (qmail 93440 invoked by uid 99); 12 Sep 2013 12:12:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Sep 2013 12:12:45 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sabob1@gmail.com designates 74.125.82.52 as permitted sender) Received: from [74.125.82.52] (HELO mail-wg0-f52.google.com) (74.125.82.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Sep 2013 12:12:41 +0000 Received: by mail-wg0-f52.google.com with SMTP id m15so465865wgh.7 for ; Thu, 12 Sep 2013 05:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IRIcNnJbYZjwzx549KlD7lHXLmAsA2Va5O/PXVGPuGk=; b=lrW+4Mllr3TazYj+CHvJU5dCWBwxbniSQ/39u8X2cmVyBfMMVS3wwdMxNjiLGBYUXe 0zOHGQT3Y06JRizQ63gdjhD1A8x6r0HJFC7T+7kZ9zaSjWlYW+XsIKJZufDXxeKNVO2N PHF9cWKXx1tTr2fgoWC7R7ZZSI4LITgcnxGNwUXahO2nr26tJPjcM0ELPAj7tNltmAEm 9XNuKLqB0/gHnXZxuZvzb1D1ijl64uf+9FFUTLNiwrj1XD0FI4n+M21mBuOnFzbDs0m3 Zo6nEijKE47BBKgWaL30QayG2V/zahIvGysa72/en71hM0CdrhK3yN77sCiMHXUhyQhn z3gQ== MIME-Version: 1.0 X-Received: by 10.180.81.71 with SMTP id y7mr17676693wix.63.1378987939678; Thu, 12 Sep 2013 05:12:19 -0700 (PDT) Received: by 10.216.90.200 with HTTP; Thu, 12 Sep 2013 05:12:19 -0700 (PDT) In-Reply-To: References: <52307FBA.2010604@gmail.com> Date: Thu, 12 Sep 2013 14:12:19 +0200 Message-ID: Subject: Re: Comparison with Apache Wicket From: Bob Schellink To: "Dev@click.apache.org" Content-Type: multipart/alternative; boundary=f46d04428cc24b50e904e62ea6e0 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04428cc24b50e904e62ea6e0 Content-Type: text/plain; charset=ISO-8859-1 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 >> >> >> > --f46d04428cc24b50e904e62ea6e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There isn't much doco except for the javadoc:
=
http://click.apache.org/docs/click-api/org/apache/click/Stateful= .html



It is= very basic and light-weight. A control can store and restore it's stat= e in the session. You could look at Table and ClickUtils on how it's do= ne.

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 <sabob1@gmail.com> wrote:
=20 =20 =20
Hi Daniel,

Couple of years ago I've answered this question on StackOverflow:=
http://stackoverflow.com/questions/2168249/apac= he-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. A= s 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.
<= br>
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.
=A0

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



--f46d04428cc24b50e904e62ea6e0--