Wicket in Action

Autocomplete Ajax with Wicket And jQuery UI

Jeff Schwarz, The Wicket Evangelist blogs about
Marrying Wicket And jQuery UI Autocomplete Ajax:

I learned that no one seemed to have posted a pure Wicket solution but rather relied upon wiQuery’s implementation. [As] I prefer to not use wiQuery and to roll my own reusable “pure” Wicket based solutions

What’s new in fiftyfive-wicket 3.1

San Francisco startup 55 minutes has created a Maven quickstart archetype that bundles quite some functionality in one powerful package:

• Compass and Sass stylesheets
• Shortcut methods for frequently used idioms
• Handy components such as pluralized labels for numeric data, and a label for truncating long text with an ellipsis
• Testing tools for validating HTML 5 and XHTML markup
• Apache Shiro (a security framework) out of the box
• JavaScript capabilities for dependencies and merging

Very interesting project. Read more about their 3.1 release of fiftyfive-wicket here: What’s new in fiftyfive-wicket 3.1 – 55 Minutes Blog.

JavaZone 2011 video online

My presentation Introducing Apache Wicket I gave at JavaZone 2011 is available! Kudos to the JavaZone team for being so quick in publishing the presentations online!

Introducing Apache Wicket from JavaZone on Vimeo.

Wicket 1.5 – Mounting resources

In the previous article I described how to mount pages at nice looking urls. Today I’ll show you how to mount resource.

Recently there were several people asking in the mailing lists how to serve images loaded from a database so this will be the functionality of the demo application for this article.

To mount a resource you should do:
MyApp.java

public void init() {
  super.init();
  mountResource("/mount/path", new SomeResourceReference());
  // #mountResource() is a shortcut for:
  // mount(new ResourceMapper("/mount/path", new com.example.SomeResourceReference()));
}

With this setup requests to http://host/mount/path will be handled by com.example.SomeResourceReference. The extraction of the request parameters is the same as with pages. A request to http://host/mount/path/indexed?queryNamed=queryValue will have one indexed and one named parameters. They can be read with Attributes.getParameters().get(0) and .get(“queryNamed”) respectfully. Named indexed parameters also work the same way as with pages.

Now since we know how to mount resources let’s see how to create links to them.

MyApp.java

public void init() {
  super.init();
  mountResource("/images/${name}", new ImageResourceReference());
  mountPage("imagesPage", ImageResourcesPage.class);
}

Here we mounted the resource reference that will find the images and a page which will make use of them.

The important thing when creating the resource reference is to give it unique ResourceReference.Key and provide implementation of #getResource() method:
ImageResourceReference.java

public ImageResourceReference() {
    // this creates a Key with scope 'ImageResourceReference.class' 
    // and a name 'imagesDemo'
    super(ImageResourceReference.class, "imagesDemo");
}
 
@Override
public IResource getResource() {
    return new ImageResource();
}

The key is needed by ResourceMapper to be able to recognize the resource reference when asked to create urls to it.
ImageResource is an implementation of IResource which will serve the images.

ImageResource.java:

 private static class ImageResource extends DynamicImageResource {
 
     @Override
     protected byte[] getImageData(Attributes attributes) {
 
         PageParameters parameters = attributes.getParameters();
         StringValue name = parameters.get("name");
 
         byte[] imageBytes = null;
 
         if (name.isEmpty() == false) {
             imageBytes = getImageAsBytes(name.toString());
         }
         return imageBytes;
     }
 
     private byte[] getImageAsBytes(String label) {...}
 
     @Override
     public boolean equals(Object that) {
         return that instanceof ImageResource;
     }
}

Since we need to serve images we take advantage of Wicket’s DynamicImageResource which cares about HTTP headers and stuff and leave us only to load the image’s bytes. The parameter Attributes gives us access to the current request, response and the extracted request parameters. The override of #equals() is the second requirement needed by ResourceMapper to fully recognize the mapped resource. For our need any ImageResource instance will do the job.

To create urls to images you should use the following code:
ImageResourcesPage.java

 ResourceReference imagesResourceReference = new ImageResourceReference();
 PageParameters imageParameters = new PageParameters();
 
 String imageName = "anyName.jpg";
 imageParameters.set("name", imageName);
 CharSequence urlForImage = getRequestCycle().urlFor(imagesResourceReference, imageParameters);
 ExternalLink link = new ExternalLink("link", urlForImage.toString());

The link will produce urls like /images/anyName.jpg.

With this the task is done.

The full source of the demo application can be found in my Github account.

Wicket 1.5 – Mounting pages

In the previous article I described how IRequestMappers work. In this installment I’ll show you how to mount pages at nice looking urls.

In Wicket 1.4 there were several implementations of IRequestTargetUrlCodingStrategy with which the developer was able to mount a page at a given path and the request parameters were encoded/decoded depending on the chosen coding strategy. E.g. with QueryStringUrlCodingStrategy the parameters were read/written in the request’s query string – /mount/path?param1=value1¶m2=value2, with IndexedParamUrlCodingStrategy the parameters are represented as part of the request path – /mount/path/param1/param2, with MixedParamUrlCodingStrategy it was possible to use both query string based and indexed based ones.

In Wicket 1.5 all these are combined in MountedMapper. It can encode/decode the parameters in the query string, as indexed and as named indexed.

To mount a page with MountedMapper you should do something like:
MyApp.java

public void init() {
  super.init();
  mountPage("/mount/path", MyPage.class);
  // #mountPage() is a shortcut for:
  // mount(new MountedMapper("/mount/path", MyPage.class));
}

Now a request to http://host/mount/path will be handled by MyPage and it wont have any parameters. A request to http://host/mount/path/indexed?queryNamed=queryValue will have one indexed and one named parameters. They can be read with PageParameters#get(0) and #get(“queryNamed”) respectfully.

The new functionality in 1.5 is that now you can have indexed parameters which have names.
If you use mountPage(“/mount/path/${named1}/${named2}”, MyPage.class); then the request url may look like http://host/mount/path/value1/value2 and the parameters’ values can be read with PageParameters#get(“named1″) and #get(“named2″). MyPage will handle this request only if both parameters are provided. If ‘named2′ is not provided then the request mapper wont match and will let another mapper to handle the request.
One more cool thing is that you can have optional indexed named parameters. The difference with mandatory ones is that they use hash sign instead of dollar sign – #{optional}. A mapping like mountPage(“/mount/path/${named1}/#{named2}”, MyPage.class); will match for both requests http://host/mount/path/value1 and http://host/mount/path/value1/value2.

To mount all pages in a package now you should use:
MyApp.java

1
2
3
4

public void init() {
  super.init();
  mountPackage("package", com.example.pages.SomePage.class);
}

With this a request to http://host/package/AnotherPage will be handled by AnotherPage only if it is in the same package as SomePage, i.e. com.example.pages.

The last mapper which we will discuss today is BookmarkableMapper. This is the mapper which is used when there is no explicit mapping for a page. For example using setResponsePage(com.example.pages.NotMappedPage.class) will produce an url like http://host/wicket/bookmarkable/com.example.pages.NotMappedPage. This functionality is the same as ?wicket:bookmarkable=com.example.pages.NotMappedPage in Wicket 1.4. To change the namespace – wicket/bookmarkable – you’ll have to setup custom IMapperContext by overriding Application.newMapperContext().

For more information about other mappers provided by Wicket read Request Mappers wiki page.
Some code exploring this topic can be found at: Mappers examples.

In the next article I’ll show you how to mount resources.

Wicket 1.5 – Request Mapper

Hi, in series of short articles I’ll try to explain the new stuff in Wicket 1.5. It may be a completely new feature or a change since 1.4, hopefully for good.

In this first article I’ll talk about the new request mappers. They are semi- new feature, semi-change because they completely replace the functionality that IRequestTargetUrlCodingStrategy provided in 1.4.

Simply said, the Application class has a set of IRequestMapper‘s and for each request the RequestCycle asks these mappers whether any of them knows how to handle the current request’s url.
Wicket pre-configures several mappers [1] which are used for the basic application functionality like a mapper for the home page, a mapper for Wicket resources, for bookmarkable pages, etc.  The user application can add additional mappers with the various WebApplication#mountXYZ() methods.

The mapper has two main tasks:

1. To create IRequestHandler [2] that will produce the response.
   When a request comes Wicket uses IRequestMapper#getCompatibilityScore(Request) to decide which mapper should be asked first to process the request. If two mappers have the same score then the one added later is asked first. This way user’s mappers have precedence than the system ones. If a mapper knows how to handle the request’s url then it should return non-null IRequestHandler.
2. The second task is to produce Url for an IRequestHandler.
   This is needed at markup rendering time to create the urls for links, forms’ action attribute, etc.

In the next article I will show how to use most of the default mapper implementations.

1. See the source of SystemMapper for more details.
2. IRequestHandler is what IRequestTarget is in Wicket 1.4.