By default, Wicket is running in development mode. In this post we will see how to change that to Deployment mode ( commonly called as production mode ).
There is two method to change wicket to run in deployment (production) mode :
The first st way is add a ‘configuration’ context-param in web.xml.
File : web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app ... >
The system property is checked first, allowing you to add a web.xml param for deployment, and a command-line override when you want to run in development mode during development.
2. Wicket getConfigurationType()
The 2nd way is override the Wicket application getConfigurationType() method.
File : Wicket Application class
public class WicketApplication extends WebApplication
public String getConfigurationType()
The Wicket application always has the highest priority. For example, if web.xml is âdevelopmentâ and Wicket application is ‘deployment’, Wicket will run in ‘deployment’ mode.
How do I know in what mode (DEVELOPMENT/DEPLOYMENT) my application runs?
As of Wicket 1.3.0, you can call Application.getConfigurationType(). Prior to that, there is no flag telling you in which mode you are. If you want a flag subclass Application.configure() store the “configurationType” parameter in a variable.
log.info("You are in DEVELOPMENT mode");
else if (DEPLOYMENT.equalsIgnoreCase(configurationType))
Development mode in wicket does everything to Developers easy and develop the application very fast . It aids and helps them a lot ,hence it is called as Development mode
1. Exceptions are shown in full:
we will get full descriptive exception on page and full details of exception on page when it occurs in development mode.
2.Wicket debugger is shown:
We can get many wicket debugger on page which helps in finding the flow of application request. Main debugger is Wicket Ajax Debugger. It helps the developer for debugging Ajax request . It will present in page and each request and response , java script implementation can be seen.
3.Check for serialization errors:
We can check all serialization errors in development mode .
4.Check for errors in the component hierarchy:
When the exception or error in application flow , we get full description and specification of the error and in which component the error occurs. We will get due to what problem we get that error in component for example ” wicket component :text message is not added to page” .
5.Disable minimization of html and show wicket tags and attributes:
One of important feature development mode is we get can disable minimization of html and wicket tags and attributes is showed . This means when we press F12 (developer mode ) in browser while application is running , we can see
wicket tags and attributes . This will be very useful for debugging mainly CSS and presentation flaws .
Note : All these things take CPU time and make requests slow(er).
In deployment mode , we do everything to make the life of the users better. This means disabling all the stuff that helps developers .
1. Disable component hierarchy checks
(only the things that prevent Wicket from rendering, i.e. fatal errors, are now reported)
2.Enable caching of resources,
3.Remove wicket tags and attributes
Note : Disabling these things save on CPU cycles and that makes the requests faster.
Each of these settings can be tweaked to your advantage, for example you can enable resource watching in DEPLOYMENT mode, to enable modifications to markup and resources on your production boxes.
Warning :NEVER EVER deploy your production application using DEVELOPMENT, not even if you tweaked the settings to your desire. Future wicket versions will enable more features for developer productivity that will affect your users. Always tweak the DEPLOYMENT settings to make it more development like.
Propertymodel and compoundPropertyModel does same job of binding the data from UI ( through components like text box ,dropdowns and radio choice) to object (variable in object ). Both can bind data in either ways . that is from object to UI and UI to object.
Difference is between them is the way it does that job . In Propertymodel , while creating itself we have to tell which variable in the object Propertymodel refers to . This syntax of PropertyModel
public PropertyModel(final Object modelObject, final String expression)
But in CompoundPropertyModel we just refer the whole object when we create CompoundPropertyModel . While binding to any UI compoent we will tell which variable it refers to through bind method .
This makes coding simple , reusable and reduce number of line of code . This also reduces memory size and share model with children.
File : Employee.java
private String name;
private String id;
void setName(String name)
this.name = name;
void setId(String id)
this.id = id;
With PropertyModel we will write code as below
PropertyModel employeeNameModel = new PropertyModel(Employee, "name");
PropertyModel employeeIdModel = new PropertyModel(Employee, "id");
TextField nameField = new RequiredTextField("nameWicketId", employeeNameModel);
TextField idField = new RequiredTextField("idWicketId", employeeIdModel);
With CompoundPropertyModel we will write code as below
CompoundPropertyModel employeeModel = new CompoundPropertyModel(Employee);
TextField nameField = new RequiredTextField("nameWicketId", employeeModel.bind("name"));
TextField idField = new RequiredTextField("idWicketId", employeeModel.bind("id"));