Monday, August 31, 2009

Alternative to Wicket Ajax serialization

In the last post, I talked about an issue I found with Wicket. The JIRA I filed with the Wicket team (WICKET-2437) was resolved as "Won't Fix". The reason is that they do not want to make the compromise of having the user synchronizing the page, what is quite understandable.

Igor (Wicket's author) suggested that I created a shared resource and point all my images to this shared resource. That is done by removing my panels and modifying the img src attribute directly. Of course that was painful as I need to serialize all my parameters to the panels as URL parameters, and then be able to parse on the other end shared resource). I tried this path and it worked beautifully.

I know that Wicket supports multiple content types for a DynamicWebResource, but I wonder if I can make some other parts of my site (which were supposed to be async) truly async making them async. For now I can stick with Wicket, which is pretty good.

Thursday, August 27, 2009

Apache Wicket and Ajax: deal-breaker?

I've been using Wicket for the past months and found something that it's a deal-breaker if you have a web application with lots of Ajax where you rely on asynchronicity. Wicket serializes client and server side requests for the same page. You understood it correctly: serialized. So, if you have multiple panels, all the requests will be serialized. The whole purpose of ajax for asynchronicity is defeated.

So, this is a big disadvantage and, although I've been a big Wicket advocate, I would not consider it unless I find a good and simple workaround.

For more context, see this JIRA I file with the Wicket team:

Update: I found an alternative. See this post.