Wicket: The First Steps

In this article, after a quick introduction to Wicket, you will learn to obtain and set up the requisite software for Wicket-based web development. Then you will learn to develop interactive web pages using Wicket. Along the way, you will be introduced to some key Wicket concepts.

What Is Wicket?

Wicket is a component-oriented Java web application framework. It’s very different from action-/request-based frameworks like Struts, WebWork, or Spring MVC where form submission ultimately translates to a single action. In Wicket, a user action typically triggers an event on one of the form components, which in turn responds to the event through strongly typed event listeners. Some of the other frameworks that fall in this category are Tapestry, JSF, and ASP.NET. Essentially, frameworks like Struts gave birth to a concept of web-MVC that comprises coarse-grained actions-in contrast to the fine-grained actions we developers are so used to when programming desktop applications. Component-oriented frameworks such as Wicket bring this more familiar programming experience to the Web.

Obtaining and Setting Up Wicket

Wicket relies on the Java servlet specification and accordingly requires a servlet container that implements the specification (servlet specification 2.3 and above) in order to run Wicket-based web applications. Jetty (http://jetty.mortbay.org) is a popular, open-source implementation of the servlet specification and is a good fit for developing Wicket applications.

The Wicket core classes have minimal dependencies on external libraries. But downloading the jar files and setting up a development environment on your own does require some time. In order to get you quickly started, Wicket provides for a “Quick Start” project. The details can be found here: http://wicket.sourceforge.net/wicket-quickstart/. Download the latest project files through the “Download” link provided on the page. Having obtained the project file, extract it to a folder on the file system. Rename the folder to which you extracted the distribution to your required project name. As you can see in Figure 1, I’ve renamed the directory on my system to Beginning Wicket.

Figure 1. Extract the contents of the Wicket Quick Start distribution to a file system folder.

Setting up Wicket Quick Start to work with an IDE like Eclipse is quite straightforward. It is assumed that you have Eclipse (3.0 and above) and Java (1.4 and above) installed on your machine.

Eclipse Development Environment Setup Using Quick Start

The steps for setting up Eclipse with Wicket Quick Start are as follows:

1. Copy the files eclipse-classpath.xml and .project over to the project folder that you
   just created. These files are available in the directory srcmainresources under your
   project folder.

2. Create an Eclipse Java project, specifying you want it created from an existing source
   with the directory pointing to the one that you created earlier (the Beginning Wicket
   folder in this example, as shown in Figure 2). Accept the default values for other
   options and click Finish. This is all you require to start working with Wicket.

Figure 2. An Eclipse Java project pointing to the folder previously created.

Running the Application

The Quick Start application ships with an embedded Jetty server. You can start the server by right-clicking the src/main/java directory in the project and selecting the menu commands Run as Java application. If Eclipse prompts you for a main class, browse to the class named Start. This is all that is needed to kick-start Wicket development.

You can access your first Wicket application by pointing the browser to http://localhost:8081/quickstart.

How to Alter the Jetty Configuration

The Jetty configuration file is located in the project directory src/main/resources/jetty-config.xml.

Notice from the file that Jetty, by default, is configured to start on port 8081. If you want to override the default Jetty settings, this is the file you need to be editing. Next, you will change the default web application context from quickstart to wicket, as demonstrated in Listing 1. You will also change the default port from 8081 to 8080.

Listing 1. The Modified jetty-config.xml

    <!--rest snipped for clarity -->

  <Call name="addListener">
    <Arg>
      <New class="org.mortbay.http.SocketListener">
          <Set name="Port"><SystemProperty name="jetty.port" default="8081"/></Set>
      <!--rest snipped for clarity -->
  <Call name="addWebApplication">
    <Arg>/wicket</Arg>
    <Arg>src/webapp</Arg>
  </Call>

After making the modifications in Listing 1, restart Jetty. Now the application should be accessible through the URL http://localhost:8080/wicket.

For more information on Jetty configuration files, refer to the document available at http://jetty.mortbay.org/jetty/tut/XmlConfiguration.html.

The web.xml for Wicket Web Development

You will find the src/webapp/WEB-INF folder already has a fully functioning web.xml entry. But that corresponds to the default Quick Start application. Since for the purposes of this walkthrough you will develop a Wicket application from scratch, replace the existing web.xml content with the one shown in Listing 2. This registers the Wicket servlet and maps it to the /helloworld URL pattern.

Listing 2. web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD
Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <display-name>Wicket Shop</display-name>
    <servlet>
      <servlet-name>HelloWorldApplication</servlet-name>
      <servlet-class>wicket.protocol.http.WicketServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>HelloWorldApplication</servlet-name>
        <url-pattern>/helloworld/*</url-pattern>
    </servlet-mapping>

</web-app>

The URL to access the application would be http://localhost:8080/wicket/helloworld.

Now that you are done with initial configuration, you’ll develop a simple application that emulates a basic login use case.

Developing a Simple Sign-in Application

The sign-in application requires a login page that allows you to enter your credentials and then log in. Listing 3 represents the template file for one such page.

Listing 3. Login.html

<html>
  <title>Hello World</title>
  <body>
    <form wicket_id="loginForm">
           User Name <input type="text" wicket_id="userId"/><br/>
           Password <input type="password" wicket_id="password"/><br/><hr>
           <input type="submit" value="Login"/>
    </form>
  </body>
</html>

Figure 3 shows how this looks in the browser.

Figure 3. Login page when previewed on the browser

Double-click the file, and it will open in your favorite browser. Depending upon where you come from (JSP-based frameworks/Tapestry), it could come as a surprise to be able to open your template in a browser and see it render just fine. It must have been a dream sometime back with JSP-based frameworks, but luckily, it’s a reality with Wicket. You would be forced to start a web server at minimum when using a JSP-based framework/JSF for that matter. Note that the template has a few instances of a Wicket-specific attribute named wicket:id interspersed here and there (ignored by the browser), but otherwise it is plain vanilla HTML.

Wicket mandates that every HTML template be backed by a corresponding Page class of the same name. This tells you that you need to have Login.java. This is often referred to as a

page-centric approach to web development. Tapestry falls under the same category as well.

The HTML template needs to be in the same package as the corresponding Page class. An internal Wicket component that is entrusted with the job of locating the HTML markup corresponding to a Page looks for the markup in the same place as the Page class. Wicket allows you to easily customize this default behavior though. All user pages typically extend Wicket’s WebPage-a subclass of Wicket’s Page class. There needs to be a one-to-one correspondence between the HTML elements with a wicket:id attribute and the Page components. The HTML template could in fact be termed as a view with the actual component hierarchy being described in the Page class. Wicket components need to be supplied with an id parameter and an IModel implementation during construction (some exceptions will be discussed in the section “How to Specify a CompoundPropertyModel for a Page.” The component’s id value must match the wicket:id attribute value of the template’s corresponding HTML element. Essentially, if the template contains an HTML text element with a wicket:id value of name, then the corresponding wicket’s TextField instance with an id of name needs to be added to the Page class. Wicket supplies components that correspond to basic HTML elements concerned with user interaction. Examples of such elements are HTML input fields of type text, HTML select, HTML link, etc. The corresponding Wicket components would be TextField, DropDownChoice, and Link, respectively.

Wicket Models

Components are closely tied to another important Wicket concept called models. In Wicket, a model (an object implementing the IModel interface) acts as the source of data for a component. It needs to be specified when constructing the component (doing a new); some exceptions will be discussed in the section “How to Specify a CompoundPropertyModel for a Page” later. Actually, IModel is a bit of a misnomer: it helps to think about Wicket’s IModel hierarchy as model locators. These classes exist to help the components locate your actual model object; i.e., they act as another level of indirection between Wicket components and the “actual” model object. This indirection is of great help when the actual object is not available at the time of component construction and instead needs to be retrieved from somewhere else at runtime. Wicket extracts the value from the model while rendering the corresponding component and sets its value when the containing HTML form is submitted. This is the essence of the Wicket way of doing things. You need to inform a Wicket component of the object it is to read and update.

Wicket could also be classified as an event-driven framework. Wicket HTML components register themselves as listeners (defined through several Wicket listener interfaces) for requests originating from the client browser. For example, Wicket’s Form component registers itself as an IFormSubmitListener, while a DropDownChoice implements the IonChangeListener interface. When a client activity results in some kind of request on a component, Wicket calls the corresponding listener method. For example, on an HTML page submit, a Form component’s onSubmit() method gets called, while a change in a drop-down selection results in a call to DropDownChoice.onSelectionChanged. (Actually, whether a change in a drop-down selection should result in a server-side event or not is configurable.)

If you want to do something meaningful during Form submit, then you need to override that onSubmit() method in your class. On the click of the Login button, the code in Listing 4 prints the user name and the password that was entered.

Listing 4. Login.java

package com.apress.wicketbook.forms;

import wicket.markup.html.WebPage;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.PasswordTextField;
import wicket.markup.html.form.TextField;

public class Login extends WebPage {

  /**
  * Login page constituents are the same as Login.html except that
  * it is made up of equivalent Wicket components
  */

  private TextField userIdField;
  private PasswordTextField passField;
  private Form form;

  public Login(){

    /**
    * The first parameter to all Wicket component constructors is
    * the same as the ID that is used in the template
    */

    userIdField = new TextField("userId", new Model(""));
    passField = new PasswordTextField("password",new Model(""));

    /* Make sure that password field shows up during page re-render **/

    passField.setResetPassword(false);

    form = new LoginForm("loginForm");
    form.add(userIdField);
    form.add(passField);
    add(form);
  }

// Define your LoginForm and override onSubmit
class LoginForm extends Form {
  public LoginForm(String id) {
    super(id);
  }
  @Override
  public void onSubmit() {
    String userId = Login.this.getUserId();
    String password = Login.this.getPassword();
    System.out.println("You entered User id "+ userId +
               " and Password " + password);
  }
}

/** Helper methods to retrieve the userId and the password **/

protected String getUserId() {
  return userIdField.getModelObjectAsString();
}

protected String getPassword() {
    return passField.getModelObjectAsString();
  }
}

All Wicket pages extend the WebPage class. There is a one-to-one correspondence between the HTML widgets with a wicket:id attribute and the Page components. The HTML template could in fact be termed a view with the actual component hierarchy being described in the Page class. Wicket components need to be supplied with an id parameter and an Imodel implementation during construction (some exceptions will be discussed in the section “How to Specify a CompoundPropertyModel for a Page”). The model object acts as the source of data for the component. The component’s id value must match the wicket:id attribute of the template’s corresponding HTML component. Essentially, if the wicket:id of an HTML text element is name, the corresponding Wicket’s TextField class with an ID of name needs to be added to the Page class. When a page is requested, Wicket knows the HTML template it maps to (it looks for a template whose name is the same as the Page class with an .html extension in a folder location that mimics the Page class package). During the page render phase, Wicket does the following:

1. It kicks off the page rendering process by calling the Page.render() method.
2. The Page locates the corresponding markup template and begins iterating over the
   HTML tags, converting them into an internal Java representation in the process.

3. If a tag without wicket:id is found, it is rendered as is.
4. If a tag with wicket:id is found, the corresponding Wicket component in the Page is located, and the rendering is delegated to the component.
5. The Page instance is then stored in an internal store called PageMap. Wicket maintains one PageMap per user session.

The following illustrates this HTML widgets-Page components correspondence:

It’s always good to have the application pages extend from a base page class. One of the reasons to do so is that functionality common to all actions can be placed in the base class. Let’s define an AppBasePage that all pages will extend, as shown in Listing 5. It currently does nothing. Set AppBasePage as Login page’s superclass.

Listing 5. AppBasePage.java

public class AppBasePage extends WebPage {
  public AppBasePage(){
    super();
  }
}

You can liken Wicket development to Swing development. A Swing application will typically have a main class that kicks off the application. Wicket also has one. A class that extends WebApplication informs Wicket of the home page that users first see when they access the application. The Application class may specify other Wicket page classes that have special meaning to an application (e.g., error display pages). The Application class in Listing 6 identifies the home page.

Listing 6. HelloWorldApplication.java

package com.apress.wicketbook.forms;

import wicket.protocol.http.WebApplication;

public class HelloWorldApplication extends WebApplication {

    public HelloWorldApplication(){}

    public Class getHomePage(){
      return Login.class;
    }
}

Now that you are done registering the web application main class, start Tomcat and see whether the application starts up:

The Eclipse console seems to suggest otherwise and for a good reason. The stack trace seems to reveal that a Wicket class named ContextParamWebApplicationFactory failed to create the WebApplication class in the first place! Note that the factory class implements the IWebApplicationFactory interface.

Let's specify this important piece of information in the web.xml file as an initial parameter to WicketServlet. Listing 7 presents the modified web.xml.

Listing 7. web.xml Modified to Specify the Application Class Name

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
  //DTD Web Application 2.3//EN"
  "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <display-name>Wicket Shop</display-name>
    <servlet>
       <servlet-name>HelloWorldApplication</servlet-name>
       <servlet-class>wicket.protocol.http.WicketServlet</servlet-class>

       <!-- HelloWorldApplication is the WebApplication class -->
       <init-param>
         <param-name>applicationClassName</param-name>
           <param-value>com.apress.wicketbook.forms.HelloWorldApplication
         </param-value>
       </init-param>

       <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>HelloWorldApplication</servlet-name>
        <url-pattern>/helloworld/*</url-pattern>
    </servlet-mapping>

</web-app>

Now start Tomcat and verify that things are OK:

Congratulations! Your first Wicket web application is up and running!

Enter the URL http://localhost:8080/wicket/helloworld in your browser and the login
page should show up. Since you have already informed Wicket that the login page is your
home page, it will render it by default.

Just to make sure that you aren't celebrating too soon, enter wicket-user as both user name and password on the login page and click Login. You should see the login and the password you typed in getting printed to the console.

But how did Wicket manage to get to the correct Page class instance to the Form component and then invoke the onSubmit() listener method? You will find out next.

What Happened on Form Submit?

Right-click the login page and select View Source. The actual HTML rendered on the browser looks like this:

<html>
  <title>Hello World</title>

  <head>
    <script type="text/javascript"
src="/wicket/helloworld/resources/wicket.markup.html.
WebPage/cookies.js;
jsessionid=15o9ti4t9rn59"></script>
   <script type="text/javascript">
        var pagemapcookie = getWicketCookie('pm-null/wicketHelloWorldApplication');
        if(!pagemapcookie && pagemapcookie != '1')
{setWicketCookie('pm-null/wicketHelloWorldApplication',1);}
        else {document.location.href = '/wicket/helloworld;
jsessionid=15o9ti4t9rn59?wicket:bookmarkablePage=wicket-
0:com.apress.wicketbook.forms.Login';}
    </script>
   </head>

  <body onUnLoad="deleteWicketCookie('pm-null/wicketHelloWorldApplication');">

    <form action="/wicket/helloworld;jsessionid=15o9ti4t9rn59?wicket:interface=:0:
loginForm::IFormSubmitListener" wicket_id="loginForm" method="post"
id="loginForm">
      <input type="hidden" name="loginForm:hf:0" id="loginForm:hf:0"/>
      User Name <input value="" type="text" wicket_id="userId"      name="userId"/><br/>
      Password <input value="" type="password" wicket_id="password"
        name="password"/><br/><hr>
      <input type="submit" value="Login"/>
    </form>
  </body>
</html>

The Form's action value is of interest:

• /wicket/helloworld: This ensures the request makes it to the WicketServlet. (Ignore the jsessionid for now.) Then Wicket takes over.
• wicket:interface: See the last entry in this list.
• :0: In the PageMap, this looks for a page instance with ID 0. This is the Login page
  instance that got instantiated on first access to the Page.

• :loginForm: In the Page in question, find the component with ID loginForm.
• ::IFormSubmitListener: Invoke the callback method specified in the
  IFormSubmitListener interface (specified by wicket:interface) on that component.

loginForm is a Form instance that indeed implements the IFormSubmitListener interface. Hence this results in a call to the Form.onFormSubmitted() method. onFormSubmitted, in addition to other things, does the following:

1. It converts the request parameters to the appropriate type as indicated by the backing
   model.

2. It validates the Form components that in turn validate its child components.
3. When the child components are found to be valid, it pushes the data from request into
   the component model.

4. Finally, it calls onSubmit().

Thus, by the time your onSubmit() is called, Wicket makes sure that the model object corresponding to all the nested form components are appropriately updated, and that is when you print out the updated model values. For now, ignore the component validation step.

This is often referred to as a postback mechanism, in which the page that renders a form or view also handles user interactions with the rendered screen.

Depending upon your preference, you might not like the fact that Wicket's components are being held as instance variables in the Login class. (In fact, keeping references to components just to get to their request values is considered an antipattern in Wicket. It was used only to demonstrate one of the several ways of handling input data in Wicket.) Wouldn't it be good if you could just have the user name and password strings as instance variables and somehow get Wicket to update those variables on form submit? Let's quickly see how that can be achieved through Wicket's PropertyModel, as Listing 8 demonstrates.

Listing 8. Login.java

import wicket.markup.html.WebPage;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.PasswordTextField;
import wicket.markup.html.form.TextField;
import wicket.model.PropertyModel;

public class Login extends AppBasePage {

  private String userId;
  private String password;

  public Login(){

    TextField userIdField = new TextField("userId",
                  new PropertyModel(this,"userId"));

    PasswordTextField passField = new PasswordTextField("password",
          new PropertyModel(this, "password"));

    Form form = new LoginForm("loginForm");
    form.add(userIdField);
    form.add(passField);
    add(form);
  }

  class LoginForm extends Form {
    public LoginForm(String id) {
       super(id);
    }

    @Override
    public void onSubmit() {
       String userId = getUserId();
       String password = getPassword();
       System.out.println("You entered User id "+ userId +
                  " and Password " + password);
    }
  }

  public String getUserId() {
    return userId;
  }
  public String getPassword() {
    return password
  }

  public void setUserId(String userId) {
    this.userId = userId;
  }

  public void setPassword(String password) {
    this.password= password;
  }
}

Make the preceding change to Login.java, access the login page, enter values for the User Name and Password fields, and click Login. You should see the same effect as earlier. Some radical changes have been made to the code though that require some explanation.

This time around, note that you don't retain Wicket components as the properties of the page. You have string variables to capture the form inputs instead. But there is something else that demands attention; take a look at Listing 9.

Listing 9. Login Constructor

TextField userIdField = new TextField("userId", new PropertyModel(this,"userId"));

You still specify the ID of the component as userId (first argument to the TextField component) as earlier. But instead of a model object, you supply another implementation of Wicket's IModel interface-PropertyModel.

How Does PropertyModelWork?

When you include new PropertyModel(this,"userId"), you inform the TextField component that it needs to use the Login instance (this) as its model (source of data) and that it should access the property userId of the Login instance for rendering and setting purposes. Wicket employs a mechanism that is very similar to the OGNL expression language (http://www.ognl.org). OGNL expects the presence of getProperty and setProperty methods for expression evaluation, and so does Wicket's implementation. For example, you can access subproperties via reflection using a dotted path notation, which means the property expression loginForm.userId is equivalent to calling getLoginForm().getUserId() on the given model object (loginForm). Also, loginForm.userId= translates to getLoginForm().setUserId(something). (loginForm is an instance of the Login class). In fact, prior to the 1.2 release, Wicket used to employ the services of OGNL, until it was discovered that the latter resulted in limiting Wicket's performance to a considerable extent and was subsequently replaced with an internal implementation.

I like this page-centric approach, but then I like cricket (http://www.cricinfo.com), too. I guess it's a good idea to let you know of some of the "modeling" options that I'm aware of, as I believe that the user is the best judge in such circumstances. Wicket allows you to model your model object as a plain Java object, also known as POJO. (POJO actually stands for Plain Old Java Object.) You can specify a POJO as the backing model for the entire page. Such a model is referred to as a CompoundPropertyModel in Wicket. A Wicket Page class is derived from the Component class and models are applicable to all components. Let's develop another page that allows one to specify personal user details to demonstrate that.

How to Specify a CompoundPropertyModel for a Page

Figure 4 shows another not-so-good-looking page that allows the user to enter his or her profile. Remember, the majority of us are Java developers who don't understand HTML! We will leave the job of beautifying the template to the people who do it best-HTML designers. Therein lies the beauty of Wicket. Its design encourages a clean separation of roles of the designer and the back-end developer with a very minimal overlap. Figure 4 shows a simple page that captures user-related information.

Figure 4. UserProfilePage for capturing user-related information

See Listing 10 for the corresponding HTML template code.

Listing 10. UserProfilePage.html

<html>
  <title>User Profile</title>
  <body>
    <form wicket_id="userProfile">
         User Name <input type="text" wicket_id="name"/><br/>
         Address<input type="text" wicket_id="address"/><br/>
         City <input type="text" wicket_id="city"/><br/>
         Country <select wicket_id="country">
         <!--The markup here is for preview purposes only. Wicket
         replaces this with actual data when rendering the page -->
         <option>India</option>
          <option>USA</option>
          <option>UK</option>
         </select><br/>
         Pin <input type="text" wicket_id="pin"/><br/>
      <hr/>
      <input type="submit" value="Save"/>
    </form>
  </body>
</html>

In this case, the POJO UserProfile class (see Listing 11) has been designed to hold onto the information supplied in the HTML template.

Listing 11. UserProfile.java

package com.apress.wicketbook.common;
import java.io.Serializable;

public class UserProfile implements Serializable {

  private String name;
  private String address;
  private String city;
  private String country;
  private int pin;

  public String getAddress() {
    return address;
  }
  
  public void setAddress(String address) {
    this.address = address;
  }

  public String getCity() {
    return city;
  }

  public void setCity(String city) {
    this.city = city;
  }

  public String getCountry() {
    return country;
  }

  public void setCountry(String country) {
    this.country = country;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }
  /*
  * You can return an int!
  */

  public int getPin() {
    return pin;
  }

  public void setPin(int pin) {
    this.pin = pin;
  }

  /* Returns a friendly representation of the UserProfile object */
  public String toString(){
    String result = " Mr " + getName();
    result+= "n resides at " + getAddress();
    result+= "n in the city " + getCity();
    result+= "n having Pin Code " + getPin();
    result+= "n in the country " + getCountry();
    return result;
  }

  private static final long serialVersionUID = 1L;
}

There is a one-to-one mapping between the HTML page wicket:id attributes and the properties of the UserProfile Java bean. The Wicket components corresponding to the HTML elements identified by wicket:id need not map to the same model class. It's been designed that way in this example in order to demonstrate the workings of one of the Wicket's model classes. You also aren't required to create a new POJO for every Wicket page. You can reuse one if it already exists. For example, information like a user profile is stored in the back-end repository store and is typically modeled in Java through Data Transfer Objects (DTOs). If you already have a DTO that maps to the information captured in the UserProfilePage template, you could use that as the backing model class for the page, for instance. (Please refer to http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm if you need more information on DTOs.) Wicket, being a component-oriented framework, encourages very high levels of reuse.

You just specified the UserProfile model class, but you need the corresponding Page
class, too (see Listing 12).

Listing 12. UserProfilePage.java

import java.util.Arrays;

import wicket.markup.html.WebPage;
import wicket.markup.html.form.DropDownChoice;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;
import wicket.model.CompoundPropertyModel;
import com.wicketdev.app.model.UserProfile;

public class UserProfilePage extends AppBasePage{

  public UserProfilePage() {

    UserProfile userProfile = new UserProfile();
    CompoundPropertyModel userProfileModel = new CompoundPropertyModel(userProfile);
    Form form = new UserProfileForm("userProfile",userProfileModel);

    add(form);

    TextField userNameComp = new TextField("name");
    TextField addressComp = new TextField("address");
    TextField cityComp = new TextField("city");

    /*
    * Corresponding to HTML Select, we have a DropDownChoice component in Wicket.
    * The constructor passes in the component ID "country" (that maps to wicket:id
    * in the HTML template) as usual and along with it a list for the
    * DropDownChoice component to render
    */

    DropDownChoice countriesComp = new DropDownChoice("country",
       Arrays.asList(new String[] {"India", "US", "UK" }));

    TextField pinComp = new TextField("pin");

    form.add(userNameComp);
    form.add(addressComp);
    form.add(cityComp);
    form.add(countriesComp);
    form.add(pinComp);
  
  }

  class UserProfileForm extends Form {

    // PropertyModel is an IModel implementation
    public UserProfileForm (String id,IModel model) {
       super(id,model);
    }

    @Override
    public void onSubmit() {
      /* Print the contents of its own model object */
      System.out.println(getModelObject());
    }
  }
}

Note that none of the Wicket components are associated with a model! The question "Where would it source its data from while rendering or update the data back on submit?" still remains unaddressed. The answer lies in the UserProfilePage constructor:

public class UserProfilePage....{

   /** Content omitted for clarity **/
  public UserProfilePage(){

    /* Create an instance of the UserProfile class */
    UserProfile userProfile = new UserProfile();

    /*
    * Configure that as the model in a CompoundPropertyModel object.
    * You will see next that it allows you
    * to share the same model object between parent and its child components.
    */

    CompoundPropertyModel userProfileModel = new CompoundPropertyModel(userProfile);

    /*
    * Register the CompoundPropertyModel instance with the parent component,
    * Form in this case, for the children to inherit from. So all the
    * remaining components will then use the UserProfile instance
    * as its model, using OGNL like 'setters' and 'getters'
    */

    Form form = new UserProfileForm("userProfile",userProfileModel);
      //...

      /*
      * The following code ensures that rest of the components are Form's
      * children, enabling them to share Form's model.
      */

      form.add(userNameComp);
      form.add(addressComp);
      form.add(cityComp);
      form.add(countriesComp);
      form.add(pinComp);
      //...
}

Wicket's CompoundPropertyModel allows you to use each component's ID as a property-path expression to the parent component's model. Notice that the form's text field components do not have a model associated with them. When a component does not have a model, it will try to search up its hierarchy to find any parent's model that implements the IcompoundModel interface, and it will use the first one it finds, along with its own component ID to identify its model. Actually, the CompoundPropertyModel can be set up in such a way that it uses the component ID as a property expression to identify its model.

You do not have to worry about this now. So in essence every child component added to the form will use part of the form's CompoundPropertyModel as its own because the containing Form object is the first component in the upwards hierarchy whose model implements ICompoundModel.

Fill in the form values and click Save. You should see something similar to the following on the Eclipse console:

Struts users can probably relate to this way of using models as they are somewhat similar to Struts ActionForms. For JSF users, it should suffice to say that it's not too different from a JSF-managed bean. Using distinct POJOs as model objects probably makes it easier to move things around while refactoring. The good thing is that Wicket doesn't dictate anything and will work like a charm irrespective of which "modeling" option you choose.

Development vs. Deployment Mode

Modify the label User Name to User Name1 in Login.html and refresh the page; you will notice the template now displays User Name1. Essentially, any change to the template is reflected in the subsequent page access. Wicket checks for any changes to a template file and loads the new one if it indeed has been modified. This is of great help during the development phase. But you probably wouldn't be looking for this default "feature" when deploying in production, as it may lead to the application performing slowly. Wicket easily allows you to change this behavior through the wicket.Application.configure("deployment") method (see Listing 13). Note that the default value is development.

Listing 13. HelloWorldApplication.java

import wicket.protocol.http.WebApplication;
import wicket..Application;

public class HelloWorldApplication extends WebApplication {
    public HelloWorldApplication() {
        configure(Application.DEVELOPMENT);
    }

    public Class getHomePage() {
       return Login.class;
    }
}

This looks more like a configuration parameter, and hence you should specify it as one in web.xml. The WebApplication class that you configured in web.xml allows access to wicket.protocol.http.WicketServlet (see Listing 14).

Listing 14. web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc
.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 <display-name>Wicket Shop</display-name>
  <servlet>
   <servlet-name>HelloWorldApplication</servlet-name>
   <servlet-class>wicket.protocol.http.WicketServlet</servlet-class>
   <init-param>
     <param-name>applicationClassName</param-name>
     <param-value>com.wicketdev.app.HelloWorldApplication</param-value>
   </init-param>
   <init-param>
    <param-name>configuration</param-name>
    <param-value>development</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>HelloWorldApplication</servlet-name>
    <url-pattern>/helloworld/*</url-pattern>
  </servlet-mapping>

</web-app>

Now that you are done specifying the init-param, the only thing you are left with is
accessing the same and setting it on Wicket's ApplicationSettings object. Change the
HelloWorldApplication class like this:

public class HelloWorldApplication extends WebApplication {

    public HelloWorldApplication(){
       String deploymentMode = getWicketServlet().getInitParameter("configuration");
       configure(deploymentMode);
    }

    public Class getHomePage() {
       return Login.class;
    }

}

public class HelloWorldApplication extends WebApplication {

   public void init(){
      String deploymentMode =
         getWicketServlet().getInitParameter(
                         Application.CONFIGURATION);

      configure(deploymentMode);
   }
   public HelloWorldApplication(){}

   public Class getHomePage() {
      return Login.class;
   }
}

<html>
  <title>Welcome to Wicket Application</title>
  <body>
       Welcome To Wicket Mr <span wicket_id="message">Message goes here</span>
  </body>
</html>

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class Welcome extends WebPage {

   private String userId;

   public Welcome(){
    add(new Label("message",new PropertyModel(this,"userId")));
   }

   public String getUserId() {
     return userId;
   }

   public void setUserId(String userId) {
     this.userId = userId;
   }
}

public class Login extends WebPage {
  //..
 public Login(){
    form = new LoginForm("loginForm");
    //..
  }

  class LoginForm extends Form {
    public LoginForm(String id) {
      super(id);
    }

    @Override
    public void onSubmit() {
        String userId = Login.this.getUserId();
        String password = Login.this.getPassword();

        /* Instantiate the result page and set it as the response page */
        Welcome welcomePage = new Welcome();
        welcomePage.setUserId(userId);
        setResponsePage(welcomePage);
    }
  }

}

import wicket.PageParameters;
public class Welcome extends WebPage {
    //..
   public Welcome(){
    //..
   }

   public Welcome(PageParameters params){
     this();

     /*
     * PageParameters class has methods to get to the parameter value
     * when supplied with the key.
     */

     setUserid(params.getString("userId"));
    }
    //..
}

<html>
  <title>Welcome to Wicket Application</title>
  <body>
    Welcome To Wicket Mr <span wicket_id="message">Message goes here</span>
    <a href="#" wicket_id='linkToUserProfile'>User Profile</a><br/>
    <a href="#" wicket_id='linkToLogin'>Login</a><br/></body>
</html>

import wicket.markup.html.link.Link;

  class Welcome ..

    public Welcome(){
      //..
      //..
      Link linkToUserProfile = new Link("linkToUserProfile"){
         public void onClick(){
          // Set the response page
          setResponsePage(UserProfilePage.class);
        }
      };

      Link linkToLogin = new Link("linkToLogin"){
         public void onClick(){
           setResponsePage(Login.class);
         }
      };

      // Don't forget to add them to the Form
      form.add(linkToUserProfile);
      form.add(linkToLogin);
   }
}

<a href="/wicket/helloworld?wicket:interface=:0:form:linkToLogin::
ILinkListener" wicket_id="linkToLogin">Login</a><br/>

public class Welcome extends WebPage {
    String userId;
    Page prevPage;

    public Welcome(String userId, Page prevPage){
      this.userId;
      this.prevPage = prevPage;
      //..
    }

    Link linkToLogin = new Link("linkToLogin"){
       public void onClick(){
         setResponsePage(prevPage==null?new Login():prevPage);
       }
    };
}

public class Login extends WebPage {
  //..
  class LoginForm extends Form {
    public LoginForm(String id) {
      super(id);
    }

    @Override
    public void onSubmit() {
      String userId = getUserId();
      String password = getPassword();
      /* Instantiate the result page and set it as the response page */
      Welcome welcomePage = new Welcome(userId,Login.this);
      setResponsePage(welcomePage);
    }
  }

}

public class Login extends WebPage
   //..
  public Login() {

    Form form = new LoginForm("loginForm");
     //...
  }

  class LoginForm extends Form {
    public LoginForm(String id) {
      super(id);
  }

  @Override
  public void onSubmit() {
      String password = getPassword();
      String userId = getUserId();
      if (authenticate(userId,password)){
         Welcome welcomePage = new Welcome();
         welcomePage.setUserId(userId);
         setResponsePage(welcomePage);
      }else{
         System.out.println("The user id/ password
              combination is incorrect!n");
      }
    }
  }
  public final boolean authenticate(final String username,
           final String password){
       if ("wicket".equalsIgnoreCase(username) &&
          "wicket".equalsIgnoreCase(password))
         return true;
        else
         return false;
   }
}