A Wicket Diary

The Wicket team is pleased to announce the Wicket 1.2.3 release!

Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a first-class component model backed by POJO data beans that can easily be persisted using your favorite technology.

More information on Wicket can be found here: http://wicketframework.org

Although Wicket has recently entered the ASF Incubator, this interim
release is provided outside of the ASF, solely as a service to existing
Wicket users to resolve existing bugs in the Wicket product. As such,
this release of the Wicket project is not endorsed or approved by
the Apache Software Foundation. The Apache Software Foundation is
in no way affiliated with this release.

Changes in this version include:

New Features:

• Added method protected void onDisabled(final ComponentTag tag) to FormComponent, which is called during rendering when the component is disabled. By default, an disabled=”disabled” attribute is added, but clients may override this method.
• Made synchronization timeout configurable on an application level. Later, we might add more fine grained control.
• Implemented optional interface for initializers: IDestroyer that may be implemented by initializers to clear up stuff when the application is shut down. Wicket’s JMX code uses this to clean up the JMX beans it registered on application shutdown.
• Wicket now has JMX support. For 1.2 as a separate project (wicket-jmx), for 2.0 as part of the core distribution.
• The application’s configuration type is now kept in a member which can be read using Application#getConfigurationType.
• Added AbortWithWebError abort exception.
• Bookmarkable page links set the target attribute to the proper page map when a page map is set and when the tag has a target attribute

Fixed Bugs:

• Make sure that bookmarkable urls for classes containing non-ascii characters is encoded properly. Issue: WICKET-16.
• There was no check on render authorization action done for seperate component renders, resulting in that authorization check not being executed with ajax requests. Thanks to Benjamin Podszun.
• Page was not checked for render authorization action.
• Package resources that are not found now log a warning and then throw an abort error instead of a regular exception and send a 404 to the browser if in a web request.
• Fixed deadlock possiblity on high load situations where resource managing filters (such as Spring’s/ Hibernate’s OpenSessionInViewFilter) run out of those resources before they are released. A test for this issue can be found in wicket-threadtest, wicket.threadtest.App2Test1. This bug is dangerous; everyone using Wicket 1.2.x is encouraged to update to this Wicket version asap. Thanks to Eelco Hillenius.
• ResourceReference and PackageResourceReference evolved in doing almost the same thing with ResourceReference falling back to package resources. The two classes were used mixed for the same purposes, so it obviously was confusing. PackageResourceReference is now deprecated (and removed in 2.0) and ResourceReference uses package resources as the explicit default now.
• FileUploadField’s fileUpload member is now transient, and nulled at the end of a request; fileUpload depends on non-serializable classes and should be used for the upload request only anyway.
• InputStreams returned from FileUpload is now closed at the end of the request Issue: 1543832.
• Fixed a bug in WicketTester.clickLink. When clicking an AjaxSubmitLink which submitted a form with a CheckGroup inside it, the test would fail. This was because I had only checked for RadioGroup when copying the data from the form to the request.
• Do not set window.name automatically to the page map as this gives problems with frames
• Buttons are now versioned by default
• It is now possible to override default TypeValidator error key via ConversionException.setResourceKey()
• Fixed bug where head contributions done through header contributors added to the page only worked on first page render
• SubmitLink now properly supports back button Thanks to Erik Brakkee.
• Fixed AjaxPreprocessingCallDecorator Thanks to Ingram Chen.
• AjaxFormValidatingBehavior now property updates feedback panels when form error occurs Thanks to Adam Smyczek.
• AjaxRequestTarget now doesn’t switch component use check off, as it is no longer needed. Thanks to Tomer Mevorach.

You can download this release from the sourceforge.net servers, and it will be pushed to the maven ibiblio repository momentarily.

Have fun!

- The Wicket team

As part of becoming an Apache project, we imported the contents of the Wicket Wiki to Apache’s confluence. To make this a one time switch and since we are adamant that we will go through the incubator swiftly and become a full fledged, top level Apache project, we have made our old Wiki read only.

You can find our new Wiki here: http://cwiki.apache.org/WICKET/, and details regarding the move are to be found here.

Now we have almost everything in place. Just the website and a finished JIRA import. Unfortunately we are all extremely occupied with our day jobs and our night jobs (writing a book for instance), so this might take a bit longer than previously expected.

Jesse Sightler asked the following question in the comment system regarding Wicket’s move to Apache:

Er, how many web frameworks can Apache host? Aren’t you guys afraid of being lost in the piles that are already there?

The answer is: we aren’t afraid of being lost over there. The question never arised when we moved to sourceforge, and the number of open source web frameworks is far greater at our current home than at Apache. I think that moving to Apache will open doors previously closed to Wicket. Many companies will not accept code that is not backed by a legal entity. For many organisations, the Apache brand is synonymous with quality, stability and a solid legal backing.

The reasons for us to join Apache is that we think it is one of the leading open source communities, whereas sourceforge is as much a community as your ISP is. It provides a great (however sometimes not so excellent) service to the open source community at large, but doesn’t foster a community.

We think that Wicket is a great addition to the Apache foundation: we have a very active and friendly community, we have a great framework and we see enough possibilities for us to cooperate with existing frameworks within the Apache foundation. Being close together might actually help drive our and the other communities ahead.

I don’t have any illusions for merging our framework with MyFaces, Tapestry or Struts but I think that some parts of our frameworks could benefit of being shared. There have been talks on creating a shared property resolver to replace the now stagnant OGNL library. Other possibilities for cooperation exist with Felix, Jackrabbit, Portals, and others.

I think that us moving to Apache will not only increase the visibility of the Wicket framework, but also strengthen both the Wicket and the Apache brand. Wicket because it now is part of an open source, highly visible and open community, Apache because it gains one of the best web frameworks out there and the Apache community will be expanded with enthousiastic and friendly Wicket developers from over the whole world.

So, is joining Apache considered harmful? I don’t think so and a many of our community share that answer with me.

From the mailinglist:

New version of the Wicket Assistant plugin for Intellij Idea. Download
it from the plugin manager within Idea. Works in version 5.X and 6.X.

Features implemented:

• On-the-fly Inspection checking that the wicket ids exists in the corresponding java/html file
• Switch between the java and html file (default key: shift+alt+W

Todolist:

• Maybe use a compiled version of the ie webpage to check the hierarichy
• create missing html file intention
• create missing ids in the html file. How and where ?
• create live template for easy creation of ie labels etc
• create file templates for html files, java webpages, java panels etc.
• rename/move rafactoring on the java/html/property file renames/moves the others
• rename refactoring of the wicket id in both the html and java file
• Code completion on a wicket id in both java and html file
• Possibility to open the “other” file when ie the java file is opened

Changes from 0.1.2

Added action to toggle between the html and the java file. The deault keymapping is: shift+alt+W

Known bugs;

All checks on the wicket ids are not yet 100% correct. Working on it.

Now if I only could use IDEA (somehow we didn’t get our license renewed). Problem with IDE’s is that you need to work with them full time, otherwise they get in the way. I’d love to give IDEA a go, but I can’t use an open source license for work. I’m happy with Eclipse, but I would like to confirm the productivity improvements people claim to have when they made the switch.

In a bold maneuver we transfered our Wicket subversion repository to the Apache Incubator SVN repository. Now we are officially undergoing incubation.

For our users we don’t expect any changes in the near future, unless you are working off of SVN trunk or head of our 1.x branch.

Don’t be a stranger, but join us at Apache for our development and subscribe to the wicket-development list by sending a subscribe message to ‘wicket-dev-subscribe at incubator dot apache dot org’ and follow the instructions.