HybridJava vs. Wicket

The promise of initial JSP was about interlaying (which means combining, not separating) HTML markup and Java within the presentation layer code. Respecting the boundary between the Presentation Layer and the Business Layer is a must, but note that the former has logic of its own too. The JSP way of doing things is in using Java to code presentation logic.

To understand Wicket, I got the book “Pro Wicket” by Karthik Gurumurthy. What does this specific technology provide to express the component structure of the application? The book tells “You can liken Wicket development to Swing development” and also “the component hierarchy is specified explicitly through Java code” (p 9). In other words it is done the way it was some 25 years ago with Visual Basic and all the rest desktop UI development tools. There is nothing bad in such an approach, but alas, that is a pre-HTML presentation technology. Technically it is about manually coding endless “new” and “add” operations. Reading further one finds out that the “component hierarchy” (structure) is simultaneously depicted in a form of markup. This duplication of information is a big step back even compared to the Visual Basic. See Listings 4.19 to 4.22 pages 129-130 – MyBorder is the most compact example I found. If you code the same example in HybridJava all will look indeed very similar … except that there will be NO listings 4.20 and 4.22 (repeated below) at all.

What is the need for MyBorder to be a component if it does have neither state nor behavior? A simple answer is that the Wicket framework has nothing of lighter weight than a component. HybridJava has. HybridJava approach is that presentation components (in that they have place in the hierarchy) are nothing different from HTML elements and thus markup is sufficient. A clever enough framework may (and HybridJava does) figure out all the rest behind the scenes. In particular HybridJava framework performs all necessary “new” and “add” operations and assigns dynamic IDs. 

More on IDs: page 216 states “This feature demonstrates Wicket’s excellent support for dynamic templates.” They probably meant to say that Tabbed Panel example (NOT a feature!) demonstrates something. What it demonstrates in reality is that the Wicket framework has completely failed to solve the dynamic IDs puzzle. This specific example works, but only because in the book’s own words “At any given point in time, only one Panel can be active or visible”. HybridJava has solved the dynamic IDs puzzle.

Another thing that the book shadows is the Wicket solution for loops. In the Wicket framework even a plain loop is a component, so the “Wicket way” of coding repetitions in presentation layer is (in ADDITION to markup!) something like:

Loop loop = new Loop( new LoopItem( … // Lisp is immortal !!!

HybridJava is not that “revolutionary” and sticks to using traditional Java “while” keyword.

// From “Pro Wicket” book, listings 4.20 and 4.22 (not needed in HybridJava!)

package com.apress.wicketbook.layout;

import wicket.markup.html.border.Border;

public class MyBorder extends Border {

public MyBorder(String id) {

super(id);

 }

}

…

package com.apress.wicketbook.layout;

import wicket.markup.html.WebPage;

import wicket.markup.html.basic.Label;

import wicket.markup.html.border.Border;

import wicket.model.Model;

public class MyPage extends WebPage {

public MyPage() {

Border border = new MyBorder("myborder");

add(border);

border.add(new Label("label", new Model(" Wicket Rocks 8-) ")));

}

}