The Wicket team has announced Wicket 1.3.1, the first maintenance release of the Wicket 1.3. There have been a number of changes to the Wicket framework from 1.2 to 1.3. From the original 1.3 release announcement:
Wicket 1.3.1 is available a little over a month from the initial release of 1.3, and while predominately a maintenance release, it also provides a number of enhancements and features:
For Wicket 1.2 users who wish to move to 1.3.1, there is a migration document available which details the various API and functionality changes. Along with the move to the new 'apache' package structure, there are a number of core changes that 1.2-based applications may need to make. Here are just a few examples:
Note that while the 1.3 branch of Wicket is still JDK-1.4-compatible, many of the features that ship with 1.3 are only available in Java 5 simply due to their nature. This includes the Google Guice support and Spring Annotations support (which both rely on Java 5 annotations), as well as the Wicket JMX beans (which require the Java 5 JMX management facilities).
- Last JDK-1.4-compatible Wicket release (next release will be Java 5 based)
- First Apache release: renamed packages to org.apache.wicket
- Simplified several core APIs
- Now works with zero-config behind a proxy server using relative URLs
- Added Google Guice support
- Use your Wicket pages directly in a portal without changing a line of code (JSR-168/JSR-286 support)
- Switched logging API from commons-logging to slf4j
- Integrate velocity templates as panels in your pages
- YUI-calendar and Joda time based date picker (wicket-datetime)
- Adds new javascript dependencies to the page header using an Ajax request - for example, if a component is replaced on the client via Ajax, and the replacement requires script.aculo.us, script.aculo.us and any other required dependencies will be downloaded at need.
- Improved, more robust header contributions
- Scale to extremely large numbers of users with stateless pages and components
- Improved AjaxTree/AjaxTreeTable
- Hybrid URL encoding to make search engines and your users happy
- Create form panels and use them anywhere without worrying about the nesting of form tags
- Minimized session use by storing component hierarchy in file system (DiskPageStore)
Wicket 1.3.1 is available a little over a month from the initial release of 1.3, and while predominately a maintenance release, it also provides a number of enhancements and features:
A lot of bugs have been squashed and several improvements implemented. The most notable improvement is the addition of out-of-the-box, transparent clustering support (WICKET-1272).The transparent clustering support added in 1.3.1 leverages the DiskPageStore feature added in 1.3, and the initial implementation was described in detail by Matej Knopp on the Wicket-User mailing list. Here is an exerpt:
When a page instance is being replicated from NodeA to NodeB, it is immediately stored to DiskPageStore on nodeB, rather than kept in session. This means that the instance is later accessible on NodeB even after another page from the same pagemap has been replicated to NodeB, because it's already stored in DiskPageStore. Also it doesn't have to be kept in memory, significantly reducing the session state.A complete list of all other issues fixed and improvements implemented in 1.3.1 is available here.
For Wicket 1.2 users who wish to move to 1.3.1, there is a migration document available which details the various API and functionality changes. Along with the move to the new 'apache' package structure, there are a number of core changes that 1.2-based applications may need to make. Here are just a few examples:
- The contract of the IModel 'getObject' and 'setObject' methods no longer accept a 'Component' as a parameter.
- The DatePicker implementation provided in the Wicket 1.2 extensions project is no longer available due to license conflicts. The Wicket team has provided a replacement based on the YUI (Yahoo UI) calendar control.
- The Validation APIs are now decoupled from the form APIs allowing them to be used independently.
- The Wicket team recommends the move to a ServletFilter for initialization as opposed to using the WicketServlet from 1.2.