wicket-user-guide/src/docs/guide/helloWorld/helloWorld_2.gdoc

In this chapter we will see a classic Hello World! example implemented using a Wicket page with a built-in component called @Label@ (the code is from project the HelloWorldExample). Since this is the first example of the guide, before looking at Java code we will go through the common artifacts needed to build a Wicket application from scratch.

{note}
All the example projects presented in this document have been generated using Maven and the utility page at "http://wicket.apache.org/start/quickstart.html":http://wicket.apache.org/start/quickstart.html . *Appendix A* contains the instructions needed to use these projects and build a quickstart application using Apache Maven. All the artifacts used in the next example (files web.xml, HomePage.class and HomePage.html) are automatically generated by Maven.
{note}

h3. Wicket application structure

A Wicket application is a standard Java EE web application, hence it is deployed through a web.xml file placed inside folder WEB-INF:

!webinf.png!

_Illustration : The standard directory structure of a Wicket application_

The content of web.xml declares a servlet filter (class @org.apache.wicket.Protocol.http.WicketFilter@) which dispatches web requests to our Wicket application:

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
    <display-name>Wicket Test</display-name>
    <filter>
        <filter-name>TestApplication</filter-name>
        <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
        <init-param>
          <param-name>applicationClassName</param-name>
          <param-value>org.wicketTutorial.WicketApplication</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>TestApplication</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>
{code}

Since this is a standard servlet filter we must map it to a specific set of URLs through the @<filter-mapping>@ tag). In the xml above we have mapped every URL to our Wicket filter.

If we are using Servlet 3 or a later version, we can of course use a class in place of web.xml to configure our application. The following example uses annotation @WebFilter.

{code}
@WebFilter(value = "/*", initParams = { @WebInitParam(name = "applicationClassName", value = "com.mycompany.WicketApplication"), 
				@WebInitParam(name="filterMappingUrlPattern", value="/*") })
public class ProjectFilter extends WicketFilter {
	
}
{code}



{note}
Wicket can be started in two modes named respectively DEVELOPMENT and DEPLOYMENT. The first mode activates some extra features which help application development, like resources monitoring and reloading, full stack trace rendering of exceptions, an AJAX debugger window, etc... The DEPLOYMENT mode turns off all these features optimizing performances and resource consumption. In our example projects we will use the default mode which is DEVELOPMENT. [Chapter 24.1|guide:maven_1] contains the chapter “Switching Wicket to DEPLOYMENT mode“ where we can find further details about these two modes as well as the possible ways we have to set the desired one. In any case, DO NOT deploy your applications in a production environment without switching to DEPLOYMENT mode!
{note}

h3. The application class

If we look back at web.xml we can see that we have provided the Wicket filter with a parameter called  @applicationClassName@. This value must be the fully qualified class name of a subclass of @org.apache.wicket.Application@. This subclass represents our web application built upon Wicket and it's responsible for configuring it when the server is starting up. Most of the times our custom application class won't inherit directly from class @Application@, but rather from class @org.apache.wicket.protocol.http.WebApplication@ which provides a closer integration with servlet infrastructure. 
Class @Application@ comes with a set of configuration methods that we can override to customize our application's settings. One of these methods is @getHomePage()@ that must be overridden as it is declared abstract:

{code}
public abstract Class<? extends Page> getHomePage()
{code}

As you may guess from its name, this method specifies which page to use as homepage for our application. 
Another important method is @init()@:

{code}
protected void init()
{code}

This method is called when our application is loaded by the web server (Tomcat, Jetty, etc...) and is the ideal place to put our configuration code. The @Application@ class exposes its settings grouping them into interfaces (you can find them in package @org.apache.wicket.settings@). We can access these interfaces through getter methods that will be gradually introduced in the next chapters when we will cover the related settings.

The current application's instance can be retrieved at any time calling static method @Application.get()@ in our code. We will give more details about this method in [chapter 9.3|guide:requestProcessing_3]. The content of the application class from project HelloWorldExample is the following:

{code}
public class WicketApplication extends WebApplication
{    	
	@Override
	public Class<? extends WebPage> getHomePage()
	{
		return HomePage.class;
	}

	@Override
	public void init()
	{
		super.init();
		// add your configuration here
	}
}
{code}

Since this is a very basic example of a Wicket application, we don't need to specify anything inside the @init@ method. The home page of the application is the @HomePage@ class. In the next paragraph we will see how this page is implemented and which conventions we have to follow to create a page in Wicket.

{note}
Declaring a @WicketFilter@ inside web.xml descriptor is not the only way we have to kickstart our application.
If we prefer to use a servlet instead of a filter, we can use class @org.apache.wicket.protocol.http.WicketServlet@. See the JavaDoc for further details.
{note}