click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis M. J. Yerger" <dennisyerge...@hotmail.com>
Subject RE: Comparison with Apache Wicket
Date Wed, 11 Sep 2013 20:26:23 GMT
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 <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

 		 	   		  


 		 	   		  
Mime
View raw message