[CONF] Apache Wicket Migrating to Wicket 1.4
Anonyme a ajout un fichier page Migrating to Wicket 1.4 abc.png - 21 kB Fichier PNG IMAGE GLIFFY Afficher les pices jointes Ne plus surveiller l'espace Grer les notifications Ce message a t envoy par le logiciel de collaboration d'quipe d'Atlassian Confluence 5.0.3
[CONF] Apache Wicket Migrating to Wicket 1.4
Martin Grigorov removed a file from the page Migrating to Wicket 1.4 abc.png - 21 kB PNG File IMAGE GLIFFY Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache Wicket Migrating to Wicket 1.4
Martin Grigorov added a file to the page Migrating to Wicket 1.4 abc.png - 21 kB PNG File GLIFFY IMAGE View Attachments Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Arnout Engelen
mention WICKET-2605
mention WICKET-2605
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Generics for most Objects
Enclosures
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Arnout Engelen
mention WICKET-2605
mention WICKET-2605
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Generics for most Objects
Enclosures
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Generics for most Objects
Enclosures
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Generics for most Objects
Enclosures
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Bernhard Grünewaldt
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Generics for most Objects
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been deprecated and
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4 Page edited by Jeremy Thomerson This page has moved to: http://cwiki.apache.org/WICKET/migrate-14.html Change Notification Preferences View Online | View Change | Add Comment
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
1.4 is the current development release.
Migrating to Wicket 1.4
Bookmarkable URLGetting and building ithttp://wicket.apache.org/building-from-svn.html describes how to get and build Wicket 1.4.x.
Snapshots can be found in this maven repository and has version 1.4-SNAPSHOT:
http://wicketstuff.org/maven/repository
Table of contents
JDK 1.5
getModel name change
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
JDK 1.5
Minimum Java version is now 1.5.
getModel name change
The biggest API break is to the getModel() method. In 1.3, Component had a method getModel() that returned the model object of the default model of the component. This was renamed to getDefaultModel(), as well as it's supporting methods (i.e. getDefaultModelObject() and getDefaultModelObjectAsString()). This method returns IModel?. This change was made as part of the 1.4-M3 release. In the M1 and M2 releases, getModel() returned IModelT because Component had the generic type T. In M3 and subsequent releases, only certain components (including FormComponent and all subclasses, as well as Link and several other core components) were genericized. This included defining them as ComponentNameT and including a getModel() method that returned IModelT.
If you are migrating from 1.3 to 1.4, simply replace getModel() calls with getDefaultModel() wherever your compiler indicates an error for this change.
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been deprecated and broken into three more generic validators: RangeValidator, MinimumValidator, MaximumValidator. Likewise, the corresponding resource keys have also been changed (eg NumberValidator.maximum resource key has become MaximumValidator). NumberValidator.POSITIVE and NEGATIVE have been deprecated without a replacement, they were too confusing to the users with regard to whether or not they included zero - the same result can be easily reproduced by either Minimum or MaximumValidator.
Change Notification Preferences
View Online
|
View Change
|
Add Comment
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
Migrating to Wicket 1.4
Getting and building ithttp://wicket.apache.org/building-from-svn.html describes how to get and build Wicket 1.4.x.
Snapshots can be found in this maven repository and has version 1.4-SNAPSHOT:
http://wicketstuff.org/maven/repository
Table of contents
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
The biggest API break is to the getModel() method. In 1.3, Component had a method getModel() that returned the model object of the default model of the component. This was renamed to getDefaultModel(), as well as it's supporting methods (i.e. getDefaultModelObject() and getDefaultModelObjectAsString()). This method returns IModel?. This change was made as part of the 1.4-M3 release. In the M1 and M2 releases, getModel() returned IModelT because Component had the generic type T. In M3 and subsequent releases, only certain components (including FormComponent and all subclasses, as well as Link and several other core components) were genericized. This included defining them as ComponentNameT and including a getModel() method that returned IModelT.
If you are migrating from 1.3 to 1.4, simply replace getModel() calls with getDefaultModel() wherever your compiler indicates an error for this change.
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been deprecated and broken into three more generic validators: RangeValidator, MinimumValidator, MaximumValidator. Likewise, the corresponding resource keys have also been changed (eg NumberValidator.maximum resource key has become MaximumValidator). NumberValidator.POSITIVE and NEGATIVE have been deprecated without a replacement, they were too confusing to the users with regard to whether or not they included zero - the same result can be easily reproduced by either Minimum or MaximumValidator.
Configuration type variable name change
Wicket 1.4 uses wicket.configuration instead of configuration context variable in web.xml to declare configuration type. This is done to avoid collissions with other frameworks. configuration variable is still supported, but may be removed in a future release.
Change Notification Preferences
View Online
|
View Change
|
Add Comment
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
Migrating to Wicket 1.4
Getting and building ithttp://wicket.apache.org/building-from-svn.html describes how to get and build Wicket 1.4.x.
Snapshots can be found in this maven repository and has version 1.4-SNAPSHOT:
http://wicketstuff.org/maven/repository
Table of contents
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
[CONF] Apache Wicket Migrating to Wicket 1.4
Migrating to Wicket 1.4
Page edited by Igor Vaynberg
Migrating to Wicket 1.4
Environment
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
FileUploadField - now requires model
Registering a custom string resource loader
Spring Support
Spring Modules
SpringWebApplication
Validators
Configuration type variable name change
Environment
Wicket 1.4 requires at least Java 5
Model changes
Component.getModel() and friends renamed to getDefaultModel() and friends
In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:
ListView peopleListView = new ListView("people", people) {
protected void populateItem(ListItem item) {
item.add(new Link("editPerson", item.getModel()){
public void onClick() {
Person p = (Person)getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:
ListViewPerson peopleListView = new ListViewPerson("people", people) {
protected void populateItem(ListItemPerson item) {
item.add(new LinkPerson("editPerson", item.getModel()){
public void onClick() {
Person p = getModelObject();
setResponsePage(new EditPersonPage(p));
}
});
}
};
In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.
The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.
In order to make development of components easy Component provides setDefaultModel(IModel? model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:
class FormComponentT extends Component {
public final void setModel(IModelT model)
{
setDefaultModel(model);
}
@SuppressWarnings("unchecked")
public final IModelT getModel()
{
return (IModelT)getDefaultModel();
}
}
FileUploadField - now requires model
The FileUploadField now REQUIRES a model. This means that if you previously used the ID-only constructor (i.e. new FileUploadField("myFileField")), you will need to change it to include a model (i.e. new FileUploadField("myFileField", new ModelFileUpload())). Of course, if you don't do this, FileUploadField will look for a CompoundPropertyModel up the tree as other components do.
Registering a custom string resource loader
The API to register a custom string resource loader (getResourceSettings()#addStringResourceLoader(IStringResourceLoader)) no longer removes the default string resource loaders upon the first add. To make sure that your custom string resource loader is the first to be called use the method getResourceSettings()#addStringResourceLoader(int,IStringResourceLoader).
Spring Support
Spring Modules
wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring.
If you are using the SpringBean annotation, you need to add wicket-ioc, starting from version 1.4-m2.
SpringWebApplication
SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection.
Validators
NumberValidator has been deprecated and broken into three more
