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 41E6F10DE9 for ; Wed, 11 Sep 2013 12:00:38 +0000 (UTC) Received: (qmail 68041 invoked by uid 500); 11 Sep 2013 12:00:38 -0000 Delivered-To: apmail-click-dev-archive@click.apache.org Received: (qmail 67954 invoked by uid 500); 11 Sep 2013 12:00:32 -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 67947 invoked by uid 99); 11 Sep 2013 12:00:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Sep 2013 12:00:30 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_FRT_CLICK X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of daniel.clarke.ford@gmail.com designates 209.85.219.45 as permitted sender) Received: from [209.85.219.45] (HELO mail-oa0-f45.google.com) (209.85.219.45) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Sep 2013 12:00:23 +0000 Received: by mail-oa0-f45.google.com with SMTP id m6so9119593oag.18 for ; Wed, 11 Sep 2013 05:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=fJvMeb68MelDzYYWcAhWieN3Igr6d2xgsq4g275hJhA=; b=dqTiFoIFO5SMBFZZ75MALolyOtdEfEX0zYmtyriU/jFBWS1iRDFy5q4emseDHxS80n wXKyHhCNidsDkP14riyeALhxMrdmqzfOPKJmFLCaRSvIiLlo+9bgsH2xxSCiUTz6lO8i xASPyEIXa/T6cxCrvixILcCxPdray0g3KaSodsxQkLldxjJVJClqi1MTd9F9okxrNyHr 4crwW8xe107ma0idYcYF22qarcHkCZRg5yEru4N3CAeFfpp893okuPVakaijD5ggU+iW bGyaH2QRNYE6D/simZoKjFYzrN8pcxrN+RJANrXISia6A+zSqLXcVJlbHiXYcmgsWjDr llPw== X-Received: by 10.60.133.133 with SMTP id pc5mr988341oeb.63.1378900802135; Wed, 11 Sep 2013 05:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.129.13 with HTTP; Wed, 11 Sep 2013 04:59:31 -0700 (PDT) In-Reply-To: References: From: Daniel Ford Date: Wed, 11 Sep 2013 14:59:31 +0300 Message-ID: Subject: Re: Comparison with Apache Wicket To: dev@click.apache.org Content-Type: multipart/alternative; boundary=047d7b47249c7deefc04e61a5cee X-Virus-Checked: Checked by ClamAV on apache.org --047d7b47249c7deefc04e61a5cee Content-Type: text/plain; charset=ISO-8859-1 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? > 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 > --047d7b47249c7deefc04e61a5cee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dennis,

Thank you for your answer!


On= Wed, Sep 11, 2013 at 1:06 AM, Dennis M. J. Yerger <dennisyerger8= 4@hotmail.com> wrote:
I have experience with both Click and Wicket, and whi= le 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 Veloc= ity approach because you get the same results with less typing.

I'm not sure that I unders= tand how plain HTML (Wicket) is more typing than plain HTML + Velocity macr= os (conditions, loops, etc.)
=A0

Click's page classes resemble Swing in how th= ey 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 overridd= en method has no state - just ask it to return the state/setting.
=A0

As f= ar as I know, Wicket pages persist between requests while Click pages are c= onstructed 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.
<= /div>
As soon as you add the first stateful component or behavior the p= age will be stored for later requests.
=A0
an= XML document to make settings while Click uses click.xml by default. Wicke= t uses the concept of models for its components much like Swing. Click reli= es 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 in= itially models in Wicket are not so easy to grasp.
=A0

So far, the XML-fr= ee 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 +0= 300
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

--047d7b47249c7deefc04e61a5cee--