SeamFramework.orgCommunity Documentation
Weld provides integration between the Apache Wicket web framework and CDI. This functionality is provided by
the weld-wicket extension module, which naturally must be on the classpath of the Wicket
application.
This section describes some of the utilities provided by the Wicket extension module to support the CDI integration.
Each wicket application must have a WebApplication subclass; Weld provides, for your
utility, a subclass of this which sets up the Wicket CDI integration. You should subclass
org.jboss.weld.wicket.WeldApplication.
If you would prefer not to subclass WeldApplication, you can manually add a (small!)
number of overrides and listeners to your own WebApplication subclass. The JavaDocs of
WeldApplicationdetail this.
For example:
public class SampleApplication extends WeldApplication {
@Override
public Class getHomePage() {
return HomePage.class;
}
}Wicket can also take advantage of the conversation scope from CDI, provided by the Wicket extension module. This module takes care of:
Setting up the conversation context at the beginning of a Wicket request, and tearing it down afterwards
Storing the id of any long-running conversation in Wicket's metadata when the page response is complete
Activating the correct long-running conversation based upon which page is being accessed
Propagating the conversation context for any long-running conversation to new pages
As in JSF applications, a conversation always exists for any request to Wicket, but its
lifetime is only that of the current request unless it is marked as long-running.
The boundaries of a long-running conversation are controlled in the same way as in JSF applications,
by injecting the Conversation instance and invoking either the
begin()
or end() methods:
private @Inject Conversation conversation;
...
// begin a conversation
conversation.begin();
...
// end a conversation
conversation.end();
When a conversation is marked as long-running, the id of that conversation will be stored in Wicket's
metadata for the current page. If a new page is created and set as the response target through
setResponsePage(), this new page will also participate in this conversation. This
occurs for both directly instantiated pages (setResponsePage(new OtherPage())), as
well as for bookmarkable pages created with setResponsePage(OtherPage.class) where
OtherPage.class is mounted as bookmarkable from your WebApplication
subclass (or through annotations). In the latter case, because the new page instance is not created until
after a redirect, the conversation id will be propagated through a request parameter, and then stored in
page metadata after the redirect.