Portlet
The wicketstuff-portlet project provides implementations of the technology needed to expose a Wicket application as a portlet within a Portlet 2.0 enviroment.
The wicketstuff-portlet is functional with the following versions of Apache Wicket framework
- 6.22.0 or later
- 7.3.0 or later
In your pom.xml add the following dependency
<dependency>
<groupId>org.wicketstuff</groupId>
<artifactId>wicketstuff-portlet</artifactId>
<version>7.6.0</version>
</dependency>In order to be able to download SNAPSHOT releases dependencies add the following in your pom.xml
<repositories>
<!-- for wicket snapshots -->
<repository>
<id>wicket-snapshots</id>
<name>Apache Wicket Snapshots</name>
<url>https://repository.apache.org/content/repositories/snapshots</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>
<!-- for wicket bootstrap snapshots -->
<repository>
<id>sonatype-nexus-snapshots</id>
<name>Sonatype Nexus Snapshots</name>
<url>http://oss.sonatype.org/content/repositories/snapshots</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>By downloading the wicketstuff core project you can find portlet examples for websphere and liferay portal in core/portlet-parent/wicketstuff-portlet-examples folder
Apache Wicket 7 examples as portlets
Apache Wicket 6 examples as portlets
The wicket portlet bridge is a component that sits between the portlet environment and an apache wicket application. It’s responsible for bridging the differences between the portlet environment and the environment in which the wicket application is designed to execute.
In the portlet world, a request has distinct lifecycle phases for processing user actions and rendering a response, whereas in the web application world, action processing and response generation are part of a single request lifecycle phase. Also, in the web application world, the response to a request is a complete web page, whereas in the portlet world, the response is a markup fragment that’s handed over to the portal server, which renders the portal page.
The bridge between the Portlet world requests and the internal Wicket engine is the WicketPortlet class.
The following diagram shows how the wicket portlet bridge handles a portlet request.
(1) The wicket portlet bridge process every portlet request inside its "processRequest" method.
(1.1) getWicketURL method call At the beginning of the request processing the bridge calls the "getWicketURL" method and retrieves the Wicket URL from the request object, or if none exists it retrieves the default URL. The following diagram shows how the bridge retrieves the wicket url.
In the case of an action request, the bridge retrieves the wicket url from the request parameter named "_wu".
In the case of a resource request the wicket url is the resource id of the resource request.
If the request is the subsequent render request which follows an action request, then the wicket url is the redirect url which was stored into the request during the execution of the action phase.
Note: The render strategy of the wicket portlet is the REDIRECT_TO_RENDER strategy. By using this strategy the response phase first sets a redirect url. After the client side redirect (a second http request for web applications and the subsequent render request for portlets) the response page will be served.
If the render request does not occur due to a previous action request, then the wicket url is the default url, which is of the form of "/[wicket filter path name]/".
After the bridge retrieves the wicket url it creates a new ResponseState object (1.2), which is responsible to hold the current state of the Wicket response when invoked from WicketPortlet: buffer, headers, state and the redirect location to be processed afterwards within WicketPortlet. This ResponseState object is stored into the current portlet request object as a request attribute (1.3), so it can be looked up from a different context. The different context is the web application context of the wicket application.
If the request is an action one, then the bridge delegates the request processing to the wicket core (1.4, 1.4.1, 1.5, 1.5.1). After the wicket filter processes the response and stores the redirect url into the response state, the bridge calls its "processActionResponseState" method (1.6). During this method the bridge retrieves the redirect url from the responseState object of the request and stores this url into the render parameter named "_wuview" (1.6.1, 1.6.2, 1.6.3) in order to be available at the subsequent render phase (look at 1.1 getWicketURL method call) .
If the request is a render or resource one, then the bridge calls its "processMimeResponseRequest" (1.7)
At the beginning of the execution of this method, the bridge delegates the request processing to the wicket core (1.7.1, 1.7.1.1, 1.7.2, 1.7.2.1) and after the wicket core writes to the response the result, the bridge adds headers and writes additional on the response body depending on whether the request is RENDER or RESOURCE.