Page History

...

WICKET-2213: At the very beginning of Wicket we introduced FormComponent.setPersistence() with the idea to make creating Login panels very easy. Basically Wicket would deal with the Cookie handling for the login details. Now some years later it is evident that this feature is not very useful:

• It basically is used for login panels only
• Even in our examples Password.setPersistence is false which means that "rememberMe" doesn't really work. Only the user name is stored in a Cookie
• Forcing formComponent.getPageRelativePath() as the Cookie name is too restrictive
• You can not combine username and password into a single Cookie and e.g. decrypt it for safety reasons

So we removed that feature and introduced IAuthenticationStrategy. A default implementation has been provided and the examples have been updated. As usual it gets registered with ISecuritySettings.

...

public StringResourceModel(final String resourceKey, final Component component,
	final IModel<?> model, final Object... parameters)

Wiki MarkupWhere the Object\[\] array is matched to the first parameter of the ellipsis and the defaultValue as the second parameter.

StringResourceModel#setLocalizer() was removed, if needed you can override #getLocalizer() instead.

...

We changed that to getStyle() now returning style only which as a consequence required us to change all resource related APIs to add variation. To migrate your code you might either provide component.getVariation() or null where not relevant.

Removed magic from Border Component

We had several issues with Border such as WICKET-2494 and WICKET-3702 the fact that all over core you could find code such as "if (comp instanceof Border) {}" . That is now all fixed, though at a (low) price. Because the magic is now gone, we think it is even clearer than it was before. The difference is you have to tell Border where to add the child component. Whether it will be added to <wicket:border>..</wicket:border> which is called the "border", or <span wicket:id="myBorder">..</span> which called the "border body". And because the body can be wrapped by a container such as a Form, you need to add (move) the body to the wrapper component via wrapper.add(getBodyContainer()) if needed. By doing so you create a clean component hierarchy with no more magic and ambiguities and transparent resolvers.

Component.getMarkupId() implementation changed

If an "id" attribute is specified in a component's markup, it is now used verbatim instead of being replaced with a unique, generated value. During your migration, verify that your setOutputMarkupId(true) components don't have "id" attributes. Otherwise multiple component instances will share the same markup ID, breaking AJAX updates.

Removed magic from Border Component

We had several issues with Border such as WICKET-2494 and WICKET-3702 the fact that all over core you could find code such as "if (comp instanceof Border) {}" . That is now all fixed, though at a (low) price. Because the magic is now gone, we think it is even clearer than it was before. The difference is you have to tell Border where to add the child component. Whether it will be added to <wicket:border>..</wicket:border> which is called the "border", or <span wicket:id="myBorder">..</span> which called the "border body". And because the body can be wrapped by a container such as a Form, you need to add (move) the body to the wrapper component via wrapper.add(getBodyContainer()) if needed. By doing so you create a clean component hierarchy with no more magic and ambiguities and transparent resolvers.

border.addToBorder() will add to the border, while border.add() is a convenient border.addToBorder() will add to the border, while border.add() is a convenient and explicit alias for border.getBodyContainer().add()

...

AbstractSingleSelectChoice now uses an empty String instead of NO_SELECTION_VALUE ("-1"), allowing negative values for choices. See WICKET-933.

AbstractChoice.setType() now throws an UnsupportedOperationException as type-conversion is performed by the assigned IChoiceRenderer. See WICKET-3745.

Component rendering

We used to have different entry points to render a Page, a Component for a web request and a Component for an AJAX request. That is history. Whenever you want to render a component, simply call component.render().

...

• ITab.getPanel() now returns WebMarkupContainerWithAssociatedMarkup instead of Panel so it is now possible to create tabs using Fragments or Panels rather then just Panels.
• TabbedPanel.setSelectedTab() is now chainable
• TabbedPanel now takes a List<? extends ITab> rather then List<ITab>

MarkupContainer.isTransparentResolver() removed

Wizard

• Wizard no longer invokes IWizardStep#init(IWizardModel), this is now the responsibility of the IWizardModel itself. WizardModel and DynamicWizardModel do it already, but you have to take care of this for yourself if you have a custom IWizardModel implementation.

MarkupContainer.isTransparentResolver() removed

We removed MarkupContainer.isTransparentResolver() in We removed MarkupContainer.isTransparentResolver() in favor of the more general IComponentResolver. To mitigate the transition, we provide a TransparentWebMarkupContainer. But please note it does not solve all use cases isTransparentResolver() did.

...

formComponent.visitChildren(Radio.class, new IVisitor<Component, Void>()
{
	public void /*[1]*/ component(final Component component, final IVisit<Void> visit /*[2]*/)
	{
		if (value.equals(component.getDefaultModelObject()))
		{
			addFormComponentValue(formComponent,((Radio<?>)component).getValue());
			visit.stop(); /*[3]*/
		}
		else
		{
			visit.dontGoDeeper(); /*[4]*/
		}
	}
});

...

\[1\] The new style visitor no longer returns a value, instead the value can be returned using visit.stop(value) \
[2\] The new visit object is introduced to control the visitor traversal \
[3\] Instead of relying on magic return values the traversal is stopped by using the new visit object \
[4\] Same as \ [3\] but a different method on IVisit is used

Component Initialization - Component#onInitialize

...

   StringValue parameterValue = RequestCycle.get().getRequest().getRequestParameters().getParameterValue(parameterName);

...

Page mounting

In 1.4 a custom IRequestCycleProcessor is needed.x the parameters of mounted pages where encoded in the path of the URL by default:

public class MyApplication extends WebApplication
{
 	@Override
 	protected IRequestCycleProcessor newRequestCycleProcessor()
  	{
  		return new HttpsRequestCycleProcessor(new HttpsConfig());
  	}
}
 http://server/mount/path/parameter1/value1/parameter2/value2

But now pages are mounted with MountedMapper instead, which leads to the following URLs:

   http://server/mount/path?parameter1=value1&parameter2=value2

To get the previous 1.4.x URLs you have to configure the mapper with a UrlPathPageParametersEncoder:

   mount(new MountedMapper("/mount/path", MyPage.class,
			new UrlPathPageParametersEncoder()));

See Request mapping#MountedMapper for further mount options.

Switching to/from secured communication over https

In 1.4 a custom IRequestCycleProcessor is needed:

public class MyApplication extends WebApplication
{
 	@Override
 	protected IRequestCycleProcessor newRequestCycleProcessor()
  	{
  		return new HttpsRequestCycleProcessor(new HttpsConfig());
  	}
}

In 1.5 this In 1.5 this is re-implemented with the new HttpsMapper:

...

In Wicket 1.4 it was needed to extend org.apache.wicket.RequestCycle.onRuntimeException(Page, RuntimeException).
Wicket 1.5 gives even better control, by overriding :

• add your own org.apache.wicket.request.

...

• cycle.

...

• IRequestCycleListener (

...

• AbstractRequestCycleListener) with org.apache.wicket.Application.getRequestCycleListeners().add() and implement its #onException(RequestCycle, Exception)
• or override org.apache.wicket.Application.getExceptionMapperProvider() - the IExceptionMapper is used if none of the configured IRequestCycleListeners doesn't know how to handle the exception.
  For information on how the request cycle handles exceptions see RequestCycle in Wicket 1.5 for more information

ImageMap removed

ImageMap was deprecated in 1.4.11 and in 1.5 it was replaced with ClientSideImageMap component

...

Basically the caching strategy will decorate the package resource with a version-dependendant invariantfingerprint.

The default caching strategy in development and production mode is

...

• resource caching strategy that adds a version for the
• requested resource to the filename.
•  
• Wiki Markupversioned_filename := \ [basename\]\[version-prefix\]\[version\](.extension)
•  

Wiki MarkupIn development mode the&nbsp;\mode the [version\] string is be last modified timestamp of the resource in UNIX milliseconds. If the resource resides in a jar the timestamp of the jar file will be taken instead.

Wiki MarkupIn production mode the MD5 hash of the file content will be calculated and taken as \ [version\]. The calculation will be done once and then be cached for the lifetime of the application. We decided against choosing the last modified timestamp in deployment mode since it seems to be inconsistent in some cluster setups.

Example:

...

/**
 * Objects that can send events
 *
 * @author Igor Vaynberg (ivaynberg)
 */
public interface IEventSource
{
	/**
	 * Sends an event
	 *
	 * @param <T>
	 *            tyeptype of payload
	 *
	 * @param sink
	 *            object that will receive the event
	 * @param broadcast
	 *            if the object that receives the event needs to broadcast it to others, this is the
	 *            type of broadcast that should be used
	 * @param payload
	 *            event payload
	 */
	<T> void send(IEventSink sink, Broadcast broadcast, T payload);
}

...

In 1.5, you use

     <dependency>
      	<groupId>org.wicketstuff</groupId>
      <artifactId>jslibraries</artifactId>
      	<artifactId>wicketstuff-jslibraries</artifactId>
	<version>1.5-RC5.1<8</version>
     </dependency>

And do something like this:

...

In case the markup file contains an xml decl such as <?xml version="1.0" encoding="utf-8" ?>, it'll only be used for properly reading the markup. It'll never be used for the response and it's presence or absence will no longer determine whether an xml decl gets added to the response or not.

The response encoding is determined via Application.getRequestSettings().getResponseRequestEncoding() and applies for all your pages.

WebPage.renderXmlDecl(response) and WebApplication.renderXmlDecl(response) have been introduced to control the xml decl contribution. The behavior can be changed per Page or for your whole application. It can generally be enabled, disabled or determined via a rule. The rule currently is simple: if the page mime-type is application/xhtml+xml and the HTTP_ACCEPT header allows for the same, then insert the xml decl.same, then insert the xml decl.

Redirect to non wicket or external page.

Now when you need to redirect to a non Wicket managed URL or external link you can use RedirectRequestHandler instead of

Old code

  getRequestCycle().setRequestTarget(new RedirectRequestTarget("/usage.html"));

  // or
  page.getRequestCycle().setRequestTarget(new RedirectRequestTarget("http://www.facebook.com/"));

And post 1.5 version:

  getRequestCycle().scheduleRequestHandlerAfterCurrent(new RedirectRequestHandler("/usage.html"));

  // or
  page.getRequestCycle().scheduleRequestHandlerAfterCurrent(new RedirectRequestHandler("http://www.facebook.com/"));

(RC5) Pluggable serialization

...

Following the renames in subclasses is easier if the @Override annotations are present. IDE-s, like Eclipse, can be used to add missing @Override annotations before moving to wicket 1.5.