The Apache Wicket project is proud to announce the first maintenance release: Apache Wicket 1.4.1. The most notable change in this release is the transparent support for multipart form submissions via Ajax. Wicket is now smart enough to submit a form using a hidden iframe rather then the standard XMLHttpRequest if the form contains file upload fields.
You can download the release here:
Or use this in your Maven pom”s to upgrade to the new version:
We thank you for your patience and support.
The Wicket Team
Geertjan is a Netbeans guy, and he has been writing about Netbeans and Wicket for as long as I’ve known him. Today he published a new blog entry showing how to create an Ajax auto-complete text field with Netbeans’ Wicket support and Wicket in 5 easy steps. Can it get any better?
One question is recurring on our user list: how can I prevent a user from clicking an Ajax link multiple times? There are several solutions to this problem, but today I thought up possibly the simplest solution yet for Wicket applications using the infrastructure that is already in place for displaying custom Ajax indicators.
Ajax in Wicket is great, for the most part its usage is transparent and things work as you would expect. Where Ajax does not work perfectly, yet, is when it comes to partially updating repeaters. The problem is that repeater components do not have a markup tag of their own and so Wicket cannot transparently figure out where the updates should go.
Consider a simple case of a repeater rendering a list of contacts. Wicket markup looks like this:
And the rendered markup looks like this:
As you can see, if we add a new item to the
ListView and try to repaint it via Ajax there is no root markup tag for the Wicket Ajax to replace. This is why it is necessary to add the repeater to a container and then repaint the container instead. In this case we would add a
WebMarkupContainer to the
table tag and repaint it via Ajax instead. This, however, will result in all table rows being rendered and sent over from server to client, which for a lot of cases is undesirable.
It is not too hard to support the usecase of “I added something new to the repeater and want to have just that row added via Ajax”. The trick is to give Wicket a tag to repaint via Ajax which can be accomplished by doing the following:
- create the markup tag to represent the new item
- add it to the right place in the markup
- have Wicket repaint it via Ajax
Accomplishing this is pretty easy. Suppose we create the new item by submitting a form via an
protected void onSubmit(AjaxRequestTarget target, Form< ? > f)
// retrieve the newly added contact bean
Contact contact = form.getModelObject();
// add it to the collection on serverside
// create the new repeater item and add it to the repeater
Component item = buildItem(contact);
"tr", item.getMarkupId(), container.getMarkupId()));
// notice how we set the newly created item tag's id to that of the newly created
// Wicket component, this is what will link this markup tag to Wicket component
// during Ajax repaint
// all thats left is to repaint the new item via Ajax
When the form is submitted using the above
AjaxButton only the newly added item is repainted via Ajax instead of the entire table. A functional project is attached below.
This concept can be taken to the next level where a repeater can be “synced” with the markup on the client side. This would involve:
- Building a list of item ids currently in the repeater
- Invoking #onBeforeRender on the repeater to make it generate new items
- Building a list of new item ids in the repeater
- Syncing the client markup from old items to new items by deleting removed items and adding new items via the same technique as above
Maybe next time :)
Sample project: partialajax.zip