| Wicket is not the only component oriented framework available in the Java ecosystem. Among its competitors we can find GWT (from Google), JSF (from Oracle), Vaadin (from Vaadin Ltd.), etc... Even if Wicket and all those other frameworks have their pros and cons, there are good reasons to prefer Wicket over them: |
| |
| * *Wicket is 100% open source*: Wicket is a top Apache project and it doesn't depend on any private company. You don't have to worry about future licensing changes, Wicket will always be released under Apache license 2.0 and freely available. |
| |
| * *Wicket is a community driven project*: The Wicket team supports and promotes the dialogue with the framework's users through two mailing lists "(one for users and another one for framework developers)":http://wicket.apache.org/help/email.html and an "Apache JIRA":https://issues.apache.org/jira/browse/WICKET (the issue tracking system). Moreover, as any other Apache project, Wicket is developed paying great attention to user feedbacks and to suggested features. |
| |
| * *Wicket is just about Java and good old HTML*: almost all web frameworks force users to adopt special tags or to use server side code inside HTML markup. This is clearly in contrast with the concept of separation between presentation and business logic and it leads to a more confusing code in our pages. In Wicket we don't have to take care of generating HTML inside the page itself, and we won't need to use any tag other than standard HTML tags. All we have to do is to attach our components (Java instances) to the HTML tags using a simple tag attribute called @wicket:id@ (we will shortly see how to use it). |
| |
| * *With Wicket we can easily use JavaBeans and "POJO":http://en.wikipedia.org/wiki/Plain_Old_Java_Object in our web tier*: one of the most annoying and error-prone task in web development is collecting user input through a form and keeping form fields updated with previously inserted values. This usually requires a huge amount of code to extract input from request parameters (which are strings), parse them to Java types and store them into some kind of variable. And this is just half of the work we have to do as we must implement the inverse path (load data from Java to the web form).Moreover, most of the times our forms will use a JavaBean or a POJO as backing object, meaning that we must manually map form fields with the corresponding object fields and vice versa. Wicket comes with an intuitive and flexible mechanism that does this mapping for us without any configuration overhead (using a convention over configuration approach) and in a transparent way. [Chapter 10|guide:modelsforms] will introduce the concept of Wicket model and we will learn how to harness this entity with forms. |
| |
| * *No complex XML needed*: Wicket was designed to minimize the amount of configuration files needed to run our applications. No XML file is required except for the standard deployment descriptor web.xml (unless you are using Servlet 3 or a later version. See [Chapter 4|guide:whyLearn_2] for more details). |
