Wicket and a rich ajax website: easiest way to do it?

Question

I want to use Wicket to build an application, but I have some designers that would like to write/maintain the javascript, and they basically expect 1 JS-segment per page, and a global JS-file. I think the most natural way to add javascript in wicket is to add it per component (not per page), which would create problems for those designers (fractioned javascript, and having to write it in java-files). Is there a better way to solve this? (of course, I expect things to work after a partial refresh.)

And a second (related) thing they'd like (and I'd like actually) is the possibility to request information in JSON-format through a static link , is this possible in Wicket?

Answer 1

Quick answer to your second question is yes it is possible. Use bookmarkable links to access a resource that returns JSON data.

Answer 2

Wicket's built in AJAX support is always stateful and thus accessed with changing URLs. If your designers aren't planning to use Wicket's JS library, it's pretty straightforward to mount a JSON page:

public class JsonReturningPage extends WebPage {
  public JsonReturningPage(PageParameters params) {
    String json = "{foo: 4711}";
    IRequestTarget t = new StringRequestTarget("application/json", "UTF-8", json);
    getRequestCycle().setRequestTarget(t);
  }
}

Alternatively, you could also implement your own AbstractRequestTargetUrlCodingStrategy to directly return an IRequestTarget from IRequestTarget decode(RequestParameters params) and mount it in your application.

Regarding JS files, I'd try to educate them to use one file per component. This certainly has the advantage of less copy-paste code and simpler maitenance. Additionally, I'd certainly discourage JS in Java code. It's normally only needed to pass data or config to JS , either as variable definitions or method calls. As this data is typically in Java and JS is written by designers, it's time for designers and programmers to team up.

Answer 3

I started with JSON by making my wicket pages return the JSON, but quickly realized there are better tools for the job, especially if you will have a full web services layer. If you just need a little JSON here and there, always via a GET, then sure, just make a Wicket page.

I ended up using Jersey with Jackson alongside of Wicket. Jersey simplifies the configuration of URLs that can do different things with different http methods (GET/POST/PUT/DELETE), as well as easily parsing query strings, etc. I'd consider going this route for heavier JSON needs.

You can easily run both Wicket and Jersey in the same web application with a little web.xml configuration.

Answer 4

You can easily use the following code to dynamically communicate with Wicket:

AbstractDefaultAjaxBehavior callme = new AbstractDefaultAjaxBehavior(){
        @Override
        protected void respond(AjaxRequestTarget target) {
        }
};
page.add(callme);


//From any ajaxrequesttarget you can simply append the following code:
target.appendJavascript("wicketAjaxGet('"+callme.getCallbackUrl()+");");

This way you can have an ajaxlink etc... that will transfer the ajaxrequest to the Wicket side. If you want to pass data (though a static link doesn't sound like that) do the following:

"wicketAjaxGet('"+callme.getCallbackUrl()+"&x='+value_to_pass_back''";
//to Read the value in the respond:
String x = RequestCycle.get().getRequest().getParameter("x");

So the url to the callback is dynamically generated (as the callback url is specific to the session) but it is formed like any other url....

To me this is 10 times simpler than building a JSON system on top of wicket instead of using the one built into it.... I use this all the time and it works great for me at least. If your solution is different/better I would like to know why perhaps.