There’s bound to be a better term than optional, enforced parameters. My definition is that these are URL parameters that you don’t really care about except for SEO (search engine optimization) but if you have to have them, then they may as well be correct. They help make friendlier URLs.
If I want to get to a details page of an object, the ideal URL parameter is a single integer mapping to an id. It’s simple, clean, and fast. It’s the default URL mapping in Wordpress. However, a single id tells a search engine nothing about the page. It’s a wasted opportunity and it’s important to take advantage of it.
Let’s get concrete. A good URL for a game details page may be http://www.atomicgamer.com/games/34/Diablo-III. It contains the game id (34) for quick lookups, but also contains the game name for SEO. I don’t care about the Diablo III portion when fetching the data, but I do want it to remain consistent for links.
I took a look into doing this with both Tapestry 5 and Wicket. I’m fair from an expert in either of them, so there could be a better way to do this. This is simply the way I determined to do it.
First, I need to put a link to my details page somewhere.
<t:grid source="games" row="game">
<t:parameter name="nameCell">
<a t:type="pagelink" t:page="games" context="list:game.id,game.name">${game.name}</a>
</t:parameter>
</t:grid>
Pretty straightforward. That’ll create a link formatted as /games/{id}/{name}. Tapestry does all that for me, and in fact, if I didn’t care about enforcing the game name to be correct, I’d be done. (I’m using the list binding prefix for a quick shorthand here.)
All the rest of the work is done in the game details page’s onActivate method. This method will be called whenever a person goes to the page. I’ll need to fetch the game from the id, and then compare the name parameter to the game’s actual name.
Object onActivate(Long id, String name)
{
game = gameDAO.findById(id);
if (game == null)
{
return pagelinkSource.createPageRenderLink(Index.class);
}
if (!game.getName().equals(name))
{
return pagelinkSource.createPageRenderLinkWithContext(this.getClass(), id, game.getName());
}
return null;
}
The interesting part is the second if statement. If the names don’t match, I’m actually going to redirect the user to the page with the correct name. This costs a bit in terms of performance, but it will force it to stay consistent. If you’re ambitious, you could include a flash message here and tell the user to update their bookmarks.
That’s about it for Tapestry.
The Wicket code is eerily similar in concept. First, I build up my bookmarkable link with the two parameters.
BookmarkablePageLink link = new BookmarkablePageLink("detailsLink", DetailsPage.class);
link.setParameter("id", game.getId());
link.setParameter("name", game.getName());
link.add(new Label("name", game.getName()));
item.add(link);
And somewhere down the line, I use that link.
<a wicket:id="detailsLink"><span wicket:id="name">Game Name</span></a>
Now, Wicket supports clean URLs out of the box, but you have to configure it first or you’re going to get some really ugly URLs. To make my life easier in the long run, I installed the wicketstuff-annotation library. With this, I can just add a couple annotations to the top of my details page to get clean URLs.
@MountPath(path = "games")
@MountMixedParam(parameterNames = {"id", "name"})
public class DetailsPage extends WebPage
{
...
}
With a nice clean URL in hand (/games/{id}/{name}), we’re just a redirect away from being finished. Like Tapestry, I’ll fetch the game and redirect.
public DetailsPage(PageParameters parameters)
{
super(parameters);
Game game = getGame(parameters.getAsLong("id"));
if (!game.getName().equals(parameters.getString("name")))
{
parameters.put("name", game.getName());
setResponsePage(this.getClass(), parameters);
setRedirect(true);
return;
}
...
}
And that’s it. I’ll disclaim again that I’m neither a Tapestry or Wicket guru, and I would love someone to point out a better way to do this.
For now though, it’s minor performance cost, but grants me lovely clean, friendly URLs with parameters I don’t have to worry about. If I change the name of Diablo III to Diablo 3, users with the old URL will be redirect to the new URL. I don’t have to think about it and that’s perfect for me.
When I’m in development mode, I dislike using frameworks that will be out-of-date by the time I release. I will install beta (or alpha or simply development) builds of the software I’m choosing to use for my project. The downside (besides framework bugs) is that I’m usually on my own when trying to figure out how to integrate the projects together as most web tutorials aren’t up-to-date.
I’ve spent some time getting Wicket (just 1.4.2), Guice 2, and Warp-persist 2.0 running together. Everything seems to be running happily but I haven’t tried anything complicated. I can inject my Hibernate session and start a transaction though. Just remember that Warp-persist 2.0 is in active development and wicket-guice doesn’t mention Guice 2.0 at all. Use it this all together at your own peril.
It’s really not that much of a stretch from the current 1.0 releases of Guice and Warp-persist. And really, most of what I did I got from blog 1 and blog 2. The current Warp-persist 2.0 docs are a work-in-progress.
First, let’s setup the Maven 2 dependencies under the assumption you got Wicket and Hibernate already configured appropriately.
We’ll need wicket-guice which is dependent on Guice 1.0. We’ll remove that dependency.
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-guice</artifactId>
<version>${wicket.version}</version>
<exclusions>
<exclusion>
<groupId>com.google.code.guice</groupId>
<artifactId>guice</artifactId>
</exclusion>
</exclusions>
</dependency>
Then, we’ll add a dependency for Guice 2.0.
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>2.0</version>
</dependency>
Lastly, we’ll add our dependency for Warp-persist 2.0. Unfortunately, there aren’t any public Maven repositories that have a recent build of Warp-persist 2.0 stored. We’ll need to download the most recent public build (you can get the source and build your own snapshot, but I leave that as an exercise to the ambitious) and manually install it our local Maven repository.
Head to the public dist and download warp-persist-2.0-20090214.zip. The snapshot is out-of-date (as of 2009/10/12)! Extract the warp-persist-2.0-20090214\warp-persist-2.0-20090214.jar located in the zip file to some local directory. Then run the following Maven command to install this jar into your local repository.
mvn install:install-file -Dfile=warp-persist-2.0-20090214.jar -DgroupId=com.wideplay.warp -DartifactId=warp-persist -Dversion=2.0-20090214 -Dpackaging=jar -DgeneratePom=true
With any luck, you’ll be able to add the last Maven dependency.
<dependency>
<groupId>com.wideplay.warp</groupId>
<artifactId>warp-persist</artifactId>
<version>2.0-20090214</version>
</dependency>
Maven is exciting.
The SessionPerRequestFilter from Warp-persist 1.0 has been deprecated. In our web.xml, we’ll have to use the new PersistenceFilter instead. It’s pretty straightforward. Just make sure you define the PersistenceFilter mapping first. This’ll get us towards our open session in view goal.
<filter>
<filter-name>wicket.web</filter-name>
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
<init-param>
<param-name>applicationClassName</param-name>
<param-value>com.atomicgamer.web.WebApplication</param-value>
</init-param>
</filter>
<filter>
<filter-name>warpPersistFilter</filter-name>
<filter-class>com.wideplay.warp.persist.PersistenceFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>warpPersistFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>wicket.web</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
We’re almost there. In our subclasses WebApplication, we need to configure Warp-persist’s PersistenceService, tell Guice about it, and tell Wicket-guice about everything. One difference from Warp-persist 1.0 is that we don’t need to manually start the PersistenceService. The PersistenceFilter takes care of that for us.
//We'll be wanting to use Hibernate
Module warpModule = PersistenceService.usingHibernate().across(UnitOfWork.REQUEST).buildModule();
//And use the Warp-persist module followed by our own module for Guice.
Injector injector = Guice.createInjector(warpModule, buildWebModule());
//And we'll probably be wanting to use some injecting inside of our Wicket classes
addComponentInstantiationListener(new GuiceComponentInjector(this, injector));
For completeness, here’s the buildWebModule() method inside my WebApplication. There’s no magic here. I’m using a Hibernate annotation configuration and telling it about my DAO classes.
protected Module buildWebModule()
{
return new Module()
{
public void configure(Binder binder)
{
AnnotationConfiguration configuration = new AnnotationConfiguration().configure();
binder.bind(Configuration.class).toInstance(configuration);
configuration.addAnnotatedClass(Game.class);
binder.bind(GameDAO.class).to(GameHibernateDAO.class);
}
};
}
With this all set, I can take those DAO and use them finally! Let’s get a session.
public abstract class HibernateDAO<T, ID extends Serializable> implements DAO<T, ID>
{
@Inject
protected Provider<Session> session;
And more importantly, let’s start a transaction.
@Transactional
Game getGame(long id)
{
return gameDAO.findById(id);
}
And that’s all. If you’re already running 1.0 versions of everything, it’s not too bad to upgrade to 2.0. Practically everything is backward compatible and just deprecated at this point. So if you want to be on the bleeding edge of Hibernate 3.5, Guice 2.0, Warp-persist 2.0, Wicket 1.4.2, well, there you go.
I decided to take a break from my duel with Tapestry and look into Wicket. It’s similar to Tapestry in that it’s a Java component-based web framework and I was really tired of smashing my head into the wall with Tapestry, so I started playing around with it.
I’m only had a handful of hours into it, so take it all with a grain a salt. The same with my Tapestry thoughts as well.
The code is more concrete in Wicket. I can write regular Java code that uses interfaces and inheritance to let IntelliJ IDEA know that the code is actually being used somewhere. Compared this to Tapestry which leaves my IDE with a plethora of grayed methods and variables.
By convention is fine in the beginning of a project, but it can become a nightmare as you work to maintain that code and forget whether that “unused” method is really used or not. I’ll take a extending a class over magic methods any time.
However, as I’ve gotten older, I’ve become lazier. The second thing I noticed once I got a project running is how little Wicket provides out-of-the-box. IoC? Install your own. ORM? Find it yourself. Wicket simply manages the “web” portion of being a web framework.
And that’s not necessarily a bad thing. It’s not shameful to do one thing well. But it does mean, I have to do more work at the beginning to make a useful web application. I spent last night getting Guice, warp-persist, and Hibernate to play nice. (There’s probably a useful blog post from that experience). Getting frameworks to work together is not the most productive thing I can do with my time.
I don’t mean to turn this into a Tapestry vs Wicket article, but I can’t help but compare them. Tapestry, out of the box so to speak, does offer IoC and Hibernate components. And Tapestry does a decent job without becoming a bloated, huge monster.
If I just went by Tapestry and Wicket, I would think open source fails at documentation. Luckily, Hibernate and Spring prove that good documentation is possible. I think both Wicket and Tapestry just need to reorganize most of what they already have written. To find the useful Wicket documentation, you have to scroll past the blurbs about how cool Wicket is to use, how you should have been using it yesterday already, and how you can get it now. Move past all that and you can get find some useful info scattered in the wiki.
As my spare time allows, I’ll continue to play around with both Tapestry and Wicket. I don’t want to rush into any decision and be stuck with it for the next few years. Right now, neither is jumping out and screaming “productivity” to me.