My First Application
The Wicket application we are going to develop is the ubiquitous Hello, World! application. Simply put, we will create a web page using Wicket technology for printing the Hello, World! string on a web page.
In the second release, some interactivity will be added to show how to do simple form related component development.
The goal is to generate the following markup:
Even though the requested result is so simple, there are many ways to achieve it. In this example we will use a rendering component called
'Label' to create the text 'Hello, World!'. So basically we have two things to consider:
- the HTML page
- the label component
The markup for the HTML page is the same as earlier:
Using this HTML-code is cheating, since we don't generate the required string programatically, but have hard coded it in the HTML page.
In order to have Wicket render the text through a component, we need to tell Wicket which piece of the web page is a component. In this case we can replace the text with a label component definition.
We have used the
span element to markup the component and the
wicket:id attribute to identify the component.
What we have accomplished until now is not enough to show the message in a web page. We have only told Wicket where to render the label component in the web page. In the next section we will show how to tell Wicket to render the message.
The Java Code
In Wicket creating a web page consists of two tasks: creating the markup in which the components are defined and other information is shown, and creating Java classes to couple the web page to the required functionality. In the case of this example, we need to tell Wicket it needs to render the Label component. We also need to tell the label component to render the text 'Hello, World!'. In this section we will perform these steps one at a time.
First we need to create a web page. Wicket has a
WebPage class suited for this task. All webpages need to be subclasses of
WebPage. Another requirement is that the actual HTML file and the class name are equal:
HelloWorld. They also need to be in the same place on the classpath. The best way to develop is to put them in the same directory. This might seem strange in the beginning, especially when you are accustomed to separate html files and java files. However, since all pages are actually just components, it makes perfect sense in terms of reusability.
Note that the base package names changed or rather moved from Wicket version 1.3. This means that if you are using these versions you would need to change your imports (and other references to these for packages/classes) to reflect these new package locations. The basic idea is just to prefix all your wicket packages with "org.apache". For example, the imports:
would change to:
When you add components, you need to give them an identifier in the form of a string. In the above example, our component's identifier is 'message'. The id should be unique within it's own scope. In other words, no siblings are allowed with the same id.
When the markup is rendered, the id's of tags are matched against the component ids. Thus
will look for a component with the id 'message' in the current scope.
Besides having an id, components also have a model. A model contains and represents a state of component. Usually, a model wraps an arbitrary object and provides data from this object to the component, which displays them. In this case, the model wrapes the string "Hello World!" and this string is used for the replacement of the body of the
span tag. Generally, you have to create an instance of model and associate it with the component (models are classes that implement the
IModel interface). However, many components have convenience constructors that construct a proper model for you. With labels, you can just provide a string, which is then wrapped into a simple model for the label to use.
Generally, you use models for the 'flexible' part of components, while it is best practice to keep your components immutable.
One more thing we need to get our example running is an Application object. You only need one for an application, and it can serve as a place to do the configuration for the application.
Our application could look like this:
Sidenote: To see changes to template files immediately, include the following snippet in your web.xml or to use a system property
To load our application and have it available, we need to add the following lines to web.xml:
And you are now ready to run your first Wicket app!
NOTE: Remember to change the wicket pages names to reflect the
org.apache base package for Wicket version 1.3 and up. See the 'The Java Code' section above.
Deploying the application
One easy way of testing the application is by using Wicket QuickStart. Note that in some releases, some jar files from the jetty distribution were omitted: you need to add
ext/jasper-*.jar to your buildpath manually.
If you wish to build the package manually, you would need the following directory structure.
Then to build the application, make sure
wicket-1.3.0.jar is in your classpath, and build the .java files. To run you need to ensure all .jar files in the "lib" directory are in your classpath. For most web servers and servlet containers (Tomcat for one) will automatically load all these files in the lib directory into your classpath.
It is recommended that you use the correct tools/methods to build your applications. The above can be used as an indication as to what is needed to be able to build/run a Wicket application. This information can be used to setup your project in your favorite environment (Eclipse, Netbeans, etc.) and server (Tomcat, etc.).