Wicket

wicketstuff-merged-resources: 2.1 and 3.0 released!

I’m happy to announce the releases of wicketstuff-merged-resources 2.1 and 3.0.

Read the rest of this entry »


Wicket: Annotation-based Mounting of Resources

Today, I’m happy to announce the availability of annotation-based mounting and merging of resources in wicketstuff-merged-resources (version 3.0-SNAPSHOT for Wicket 1.4, version 2.1-SNAPSHOT for Wicket 1.3). In order to mount resources, all that’s needed is adding annotations to component classes:

@JsContribution
@CssContribution(media = "print")
@ResourceContribution(value = "accept.png", path = "/img/accept.png")
public class PanelOne extends Panel {
 
    public PanelOne(String id) {
        super(id);
        // ...
    }
}

Read the rest of this entry »


wicketstuff-merged-resources: New (much simpler) Version

It’s been a while since I’ve last posted here. Nevertheless, I’ve been busy working on some (yet to be released) Open Source projects. Others are already released but not documented/promoted yet. One of these unpromoted releases is the new version of wicketstuff-merged-resources.  wicketstuff-merged-resources was the result of my “Wicket Interface Speed-up” series where I investigate how to reduce time spent rendering Wicket pages on the client side. wicketstuff-merged-resources has two main purposes: reducing the number of HTTP requests by merging resources (i.e. JS and CSS files) and enabling aggressive caching (up to a year) by adding a version number to mounted resources (e.g. /css/all-42.css instead of /css/all.css). While wicket has the option to add a timestamp to references (something like /css/all.css?t=20090924), adding the version to the name is preferred over adding a query string. This said, let’s see how to use wicketstuff-merged-resources’ new version. Read the rest of this entry »


Detaching and Attaching Persistent Objects on Serialization

Today I’ve received a mail by someone interested in a serialization mechanism I described some days ago. This mechanism was implemented to avoid dealing with detached Hibernate objects in different HTTP (i.e. Wicket) requests (it’s not restricted to Hibernate though). The idea is quite simple: detach objects if they are persistent, serialize them if they are transient, deserialize and attach for the next request – all transparently. So far, this isn’t very special and doesn’t justify such a complicated approach. However, it’s the only way of attaching and detaching object graphs that consist of transient and persistent objects I know.
Read the rest of this entry »


Talk On Tech now Molindo Techblog

Talk On Tech (talk-on-tech.blogspot.com – the tech blog you truly love, don’t you?) was our nice, green home since August 2007. Now, after 1.5 years it was time to move on … Well, okay, we just want to consolidate all our blogs on a single self-hosted platform. In the course of doing that, we also changed the name from Talk on Tech (Let’s create a blog! How do we name it? What about “Talk on Tech”? Yeah, that name is free!) to Molindo Techblog (where Molindo is the name of our very own startup).

If it comes to new posts, We have a lot of ideas but not enough time to elaborate them all. Some ideas are:
Read the rest of this entry »


Wicket: A Neat Url Encoding Strategy and some basic SEO

After a year of working extensively with Apache Wicket I want to share some stuff I’ve been using over and over again and might be useful for you as well. In this first post it’s a custom URL Encoding Strategy and some related basic SEO.

Pages often depend on entities – e.g. a Customer or a product and as those pages should be bookmarkable as well, there has to be a unique way to tell the page which entity to use. As entities either don’t have unique names or one wants to avoid having an (database) index over the name column, the index-ID is for most applications the way to go. As it’s usually undesireable to expose the database ID of an entity in the URL, it has to be encoded and decoded somehow to get from myshop.com/customer/12 to myshop.com/customer/ea34cff … or something like that.
Read the rest of this entry »


Wicket: Loose Coupling of Componens for Ajax Updates

While developing Wicket applications, one often has to write a simple input form (e.g. a search box) that updates the content of another panel (e.g. a search result panel). And of course, we all use Wicket’s AJAX support to search as it is so damn cool and easy to use.

Normally, you do this by either putting everything on one panel or by passing a reference of the list panel to the form panel.

public SearchBoxPanel(String id, SearchResultPanel results) {
_results = results;
// snip
}
 
public void onSubmit(AjaxRequestTarget target) {
_results.setQuery(getQuery()); // or use the same model ;)
target.add(_results);
}

Read the rest of this entry »


Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests

This entry is part of my “Wicket Interface Speed-Up” series.

Now that I spent some time on configuring client-side caching and resource versioning for aggressive caching, I am going to finalize this series with an article on merging of resources and some code that you can easily use right away to speed-up your own applications in minutes.
Read the rest of this entry »


Wicket Interface Speed-Up: Caching Resources Forever

This entry is part of my “Wicket Interface Speed-Up” series.

In my last post, I explained how to change (i.e. increase) the time a client should cache resources like JavaScript and CSS files served by a Wicket application. In this post, I’ll show you how to cache resources for a year. Caching for a year is close enough to forever and a recommendation by W3C:

“To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.”

Read the rest of this entry »


Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers

This entry is part of my “Wicket Interface Speed-Up” series.

Let’s start with a short introduction before we talk about setting Expires and Cache-Control HTTP-Headers:

By default, all WebResources are cacheable for one hour, which is defined by WebResource.getCacheDuration():
Read the rest of this entry »