First – I have to install Roo and get the Roo shell up and running.  I’m really excited at this point because Roo does look really cool – really RAD!

So I download Roo and explode it out to where I explode all of my 3rd party tools and then open cygwin (I’m on Windows and am trying hard to move away from Dos…) and navigate to the new directory.  I find a bin directory with two scripts in it: roo.bat and roo.sh.  Sweet!  They have a linux version ( cygwin == linux in many ways ).  So I run roo.sh and get:

./roo.sh

Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/roo/bootstrap/Bootstrap
Caused by: java.lang.ClassNotFoundException: org.springframework.roo.bootstrap.Bootstrap
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: org.springframework.roo.bootstrap.Bootstrap.  Program will exit.

OK – take a step back.  What have I done wrong here.

I back up a directory and also try ./bin/roo.sh.  I look in the readme.txt and create the symlink for install on linux that they recommend:

ln -s /path/to/roo/bin/roo.sh /usr/bin/roo

I type in ‘roo’ and get the same BootStrap Exception.

So then I invoke the wisdom of Google and learn that most everyone who encounters this error gets it because they are in Dos and are working in a different drive than where Roo is installed.  I’m on the same drive – but it’s not working in cygwin!  No hits on this somehow?!?  I find some other results which want me to additionally set an environment variable ROO_HOME.  I do this by running from the Roo install directory ( above bin, that is…):

export ROO_HOME=`pwd`

env | grep ROO

I still get the same problem (ClassNotFoundException: org.springframework.roo.bootstrap.Bootstrap), so I cave and go into a Dos prompt. Well, first I add %ROO_HOME%\bin to my path, and *then* go into a Dos prompt. I run ‘roo’ and get the same Bootstrap Exception again. But now, I am on the wrong drive, and cd to the same drive I installed Roo on – now things are working.

Time to even start using Roo in this example : 15 minutes

So, Roo is working now – I have a shell up and running. I’m stoked because it really is cool. It has ‘hint’ as a keyword and tab-based auto-completion which is contextual – it auto-completes the correct things at the correct times.
Creating a project with Roo is a very nice experience : 3 minutes

I already have maven2 installed so I’m able to exit out of Roo and run ‘mvn eclipse:eclipse’ and import the project into Eclipse : 2 minutes

Wow, now we’re flying.  Except, wait, there a bunch of “.aj” files in my project.  Cool, Roo is leveraging AspectJ.  Suck, I don’t have AJDT plugin configured for Eclipse and I’m missing a bunch of the stuff Roo has added to my project ( 9 .aj files in all ).  Thinking this might not matter, I run the JUnitTest that Roo created for my project and see only 1 test being run – the demo has a bunch of tests being run ( added via AspectJ ).  Also, when I auto-complete on my entity class I created, I don’t get any of the framework added static methods.  Translation: I need to install the AJDT plugin for Eclipse: 10 minutes ( http://download.eclipse.org/tools/ajdt/34/update ).

Now things are good to go – I now see the out-of-the box static methods added to my domain class ( Choice.java ).   And now when I run the JUnitTest I see that 8 new tests have been added and run.  But there’s something else stinky in the state of Denmark!

IllegalStateException: Entity manager has not been injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?

No, the SpringAspects JAR is *NOT* configured as an AJC/AJDT aspects library!  I don’t know what the SpringAspects JAR is nor what it means to configure it as an AJC/AJDT aspects library.  Basically, this means you need to select the spring-aspects.jar to be in the Aspect Path of the AspectJ Build configuration of the project.  A picture is worth a 1,000 words here

Adding spring-aspects.jar to AspectJ Build path

10 minutes

So, we’re up to 40 minutes of time spent when the whole thing up until now should only be 5 minutes.

But wait, there’s more.  Now I find that I don’t have setters being woven into my Choice.java class by the Choice_Roo_Javabean.aj aspect.  I see the correct code in the aspect, but Eclipse’s autocomplete and the actual compilation fail when I attempt to access new Choice().setNamingChoice().    I can deal with this later because I’ve got to get on with the demo.

Next up – Roo will automatically update the companion aspect files it creates as new properties are added to the domain entity.  That is, if I simply add a new property called ‘description’ to my entity, and I have roo running in the background, then the Choice_Roo_Javabean.aj is automatically updated with the new getter/setter methods, and the Choice_Roo_ToString.aj is updated to include description.  SUPER COOL.

On a tangent, it is not mandatory that these woven aspects dictate the toString and javabean parts of the entity class.  The class has annotations in it to specify that the framework will handle these concerns: @RooJavaBean, @RooToString.  There is also a @RooEntity which adds all of the dao-ish methods to the class.  This is a pattern taken from Grails.

At this point we have an autogenerated JavaBean and a companion TestCase that works.

What about the webapp?  Inside of Roo shell, we can now run:

new controller automatic

With a few arguments to generate the framework jsps, the wiring, the formBackingObject functionality and even the crud forms for the domain entity.  The ordering of the fields on the crud forms matches the order in which they appear in the java file.  Changing the order of properties in the java file will change their order in the ToString.aj and crud JSPs as well. 2 minutes

So, basically everything ( apart from the WebApplication itself ) in Wicket is a Component. Now the Wicket Component is no slouch; it’s a 3,000+ line abstract class with loads of functionality built right in. I’ll dig into this base class later, but for now, let’s focus on the two immediate subclasses of Component: MarkupContainer and WebComponent.

MarkupContainers include things like: WebPage, RedirectPage, Form, FormComponent, FormComponentLabel, Button, CheckBox, TextArea, and TextField.

WebComponents include things like: Image, Include, Label.

I’m surprised, initially, to find controls such as Button, CheckBox, TextArea and TextField as MarkupContainers and not as WebComponents.

Also of interest is that subclassing is used to achieve behavior that might seem best placed in attributes of some of the classes. For example, to create a hidden input field, I might expect to create a TextField instance and set its visible property false. Instead, TextField is subclassed as HiddenField. This is also true for adding password characteristics (PasswordTextField) or making the input required (RequiredTextField). This same pattern of subclassing is used most thoroughly for Links ( AjaxFallbackLink, BookmarkablePageLink, DownloadLink, PageLink, PopupCloseLink, and ResourceLink ).

So, there’s a very rich Component-Model existing within Wicket for creating all the elements you’ll need on a web page, but where does the web page come from? For this we look to another subclass of MarkupContainer. The class WebPage is the primary analog to a conventional webpage. So much so, that the Wicket convention is actually to sit an HTML file of the same (prefix) name as the (simpleName) of the Java class extending WebPage. That is, if you were to write a new class called FunPage like this:

package org.javatech.wicket.examples;
class FunPage extends WebPage {}


Then you would have an HTML file named FunPage.html located in org/javatech/wicket/examples which would contain the HTML used in rendering the webpage.

Cool.

But this is still a bit too abstract – should we really bother writing (yet another) Hello World application for Wicket? No – there are plenty of them out there. Instead, let’s discuss how the Components get added to the WebPage and then how the HTML is able to provide the layout used to create the desired web page. And since every website since the beginning of time has forms on it, let’s show how to add a form.

Adding a form using Wicket Components and a Wicket WebPage:

When I think of an html form, my mind drifts towards thoughts of Maps where the form element’s names are the keys and the values entered by the user are the corresponding values. Then there are just a few other lingering details like the form’s name, whether to use POST or GET, and to what URL the form data should be sent. Having isolated the Component Form as the candidate for the job, I’m immediately stunned by the Constructor which takes an id and/or an IModel. The id makes sense. I mean, really, every html element should have one. But what on god’s green earth is an IModel? I know one thing, it’s an interface – score one for the I-school of thought! Upon inspection, it turns out that an IModel is simply a wrapper for a model object used by a component. It provides methods to get/set the actual model object and to drill down into a nested model object. This being learned, I see that it isn’t required for such humble beginnings as just getting a form to work and shall be forgotten for at least two days now.

So, our first form will be called DemoForm and starts out on the Java side as:

package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;
import wicket.markup.html.form.Button;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;

public class DemoForm extends WebPage {

public DemoForm() {
Form f = new Form( “myForm” );
f.add( new TextField( “myTextField” ));
Button button = new Button(”mySubmitButton”);
f.add( button );
f.setDefaultButton( button );
add( f );
}
}
Which should look something like:

When I start Wicket and hit the URL, I get an exception, because I haven’t created the appropriate HTML file.
WicketMessage: Markup of type ‘html’ for component ‘org.javatech.wicket.pages.LandingPage’ not found

So, it turns out that you need to have EVERY component added in the Java represented in the corresponding HTML. In this case, the HTML would need to contain:

<form wicket:id="myForm">
<input wicket:id="myTextField" />
<input type="submit" wicket:id="mySubmitButton"></button>
</form>


So I gotta admit that my Spidey-sense is tingling at this point. This has the potential to grow quite ugly – having to manage the same essential layout in both Java code and in the HTML. More on that later – so, now my form comes up and works.
I can type into the textbox and click on the button. When I do click on the button, however, I’m taken to a urHell:
http://localhost:8080/hello_wicket/?wicket:interface=:24:myForm::IFormSubmitListener – SAY WHAT?

So, enough suspense. Here are the remaining hoops that Wicket requires you to jump through:
1) You must have a backing model object for your form.
2) You must explicitly implement onSubmit() on the Form object being used.
3) The onSubmit() method will ( in Java code! ) specify the response page for the form.
4) You must (manually) pass the model object to the Confirmation Page.

We’ll have a new class called DemoFormModel defined as:


package org.javatech.wicket.pages;

import java.io.Serializable;

public class DemoFormModel implements Serializable {

private String myTextField;

public String getMyTextField() {
return myTextField;
}

public void setMyTextField(String myTextField) {
this.myTextField = myTextField;
}
}
An instance of DemoFormModel will be instantiated in the constructor of DemoForm and will then be passed ( in the new onSubmit() method ) to the DemoFormConfirmation WebPage. DemoForm now looks like:


package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.form.Button;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;
import wicket.model.CompoundPropertyModel;

public class DemoForm extends WebPage {

public DemoForm() {
Form f = new Form( “myForm” ) {
@Override
protected void onSubmit() {
DemoFormModel o = (DemoFormModel)getModelObject();
DemoFormConfirmation landingPageSubmission = new DemoFormConfirmation( o );
setResponsePage( landingPageSubmission );
}

};
f.setModel( new CompoundPropertyModel( new DemoFormModel() ));
f.add( new TextField( “myTextField” ));
Button button = new Button(”mySubmitButton”);
f.add( button );
f.setDefaultButton( button );
add( f );
}
}
The Java and HTML for DemoFormConfirmation look like:

DemoFormConfirmation.java

package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class DemoFormConfirmation extends WebPage {

public DemoFormConfirmation(DemoFormModel o) {
this.add( new Label( “myTextField”, o.getMyTextField() ));
}
}
DemoFormConfirmation.html

You entered:<span wicket:id="myTextField"></span>


So, in a mighty big nutshell, we needed to create 5 files to pull off a simple form submission and confirmation:

DemoForm.java, DemoForm.html, DemoFormModel.java, DemoFormConfirmation.java, and DemoFormConfirmation.html.

DemoForm specifies the form, the components on the form, the model object the components will bind to, and the form’s onSubmit() method. The onSubmit() method is responsible for retrieving the model object, instantiating the DemoFormConfirmation instance with that object, and finally redirecting to that instance.

Then, DemoForm.html needs to reference the components added in DemoForm.java by the same String id’s and DemoFormModel.java needs to have properties which match these names. DemoFormConfirmation.java and DemoFormConfirmation.html have the same sort of coupling but on a smaller scale ( 1 field only ).

The big lesson here is that naming conventions are super important and having a reliable, predictable mechanism for coming up with wicket id’s is going to be essential. Fortunately, there are numerous ways to do this with the simplest being a ModelObject first driven development cycle. Once your ModelObject is created, then it’s fieldNames should be used verbatim in both the Components added on the Java side and the wicket:id’s in the HTML.

I’m not particularly excited about hardcoding site navigation inside of onSubmit() methods in Java code. I’ve been completely brainwashed that this should be configurable behavior, but I’ve seen configurable behavior become a royal pain in the butt and am willing to entertain this backward seeming restriction. Besides, there are way to dynamically wire this stuff together if one is determined to do so ( custom code at this point in time ).