GWT and Java2Script

17 05 2006

And suddenly there is GWT, google's Java framework. Looks like an interesting next version of Echo, though in some aspects (like not being bound to any other widget framework) Echo 2 feels a bit lighter/ less prone to nasty surprises. And then while following GWT's list, I heard about Java2Script. That project looks even nicer (at least at first sight)! It's fully open source, and you can use Eclipse's designer tools with it.

Not enough reasons to get away from Wicket though. For instance, I really prefer to work with markup instead of layout managers. I like Wicket's model integration and the fact that there isn't a lot of magic going on (just plain java dummy). And I like the fact that with Wicket I can just use ajax/ javascript for just the areas where I like it, and leave it out where I don't want it.

These frameworks are really good news imo. I was starting to fear that the flow/model2/webmvc/xmlheavy/ioc-centric/whatever-latest-fad-to-get-as-far-away-of-object-orientation-as-possbile crowd was impossible to beat. I hope the projects will be useful for many people, and I hope Java2Script gets some attention alongside GWT, as it looks like it deserves that.





Skillsmatter Wicket course

13 05 2006

Looking for a course on Wicket? Here's one, provided by Skills Matter, written by Nick Heudecker.





A word about custom components

12 05 2006

I'm writing a chapter on creating custom components for Wicket In Action currently. We actually didn't even plan on making this a separate chapter – almost everything you do with Wicket results in creating custom components anyway -, but after some recent discussions on The Server Side and JavaLobby, I decided Wicket In Action really needs such a chapter.

What amazed me in these discussions is how being able to create custom components in an easy way was waved away as being of secondary importance. It's all back to EJB 1/2 with the idea that it's okay if it is harder to author custom components because they will be written by either third parties or by the senior coding gods of your company. The grunts just need an extensive library to work with, and be happy with that.

Wow. Imagine being told that you can use Java as your programming language, but at the same time being told not to create your own classes. You probably could get a long way with that. But think about the loss of elegance, creativity and expressiveness you would loose. To me the whole fun and usefulness of programming with 3GL is that I can create any data structure I want, and that I can model an API that matches the domain I'm programming for. I fail to understand why that has to be different for UI development, and Wicket proves it doesn't have to be so.

Let me state some problems I have with the idea that having a bunch of component libraries should suffice for us grunts.

  • It depends on the quality of the components. Do a search on the internet for ‘components’ in the broad sense. Look up calendars, rich editors and tree widgets for instance (or search for reusable EJBs if you're really in for a laugh). You will find a lot of these, but how many of them are really good? My experience with this is very disappointing, whether it concerns Java Applets, JavaScript widgets or JSF and .NET components, the quality is often quite below par. And the better components are often only commercial available, forcing you into extra bookkeeping, additional costs – usually not a lot, but for some components quite extravagant – and dependency on third parties (are you sure they will fix the issues you find rapidly?).
  • There is a fat chance such components and the libraries they are part of will be pretty bloated. You either have a lot of components that all have their own specialties, or you have fewer components with larger sets of configuration options.
  • Having the mind set of primarily using components instead of creating your own specialized components does not encourage code reuse on a project level. In fact, it will encourage code duplication and copy ‘n paste behavior. If you have a table to display users on several pages, but on every page in a slightly different manner, you probably would use a third party table component and configure it will all the parameters from scratch.
  • It will be rare that third party component libraries know about the domain of your applications. So, instead of having a component that understands what an ISBN code is, and that knows how to look it up using AJAX, you would have to configure the ISBN specific validation and program the client side AJAX part every time you have to put in such a field.
  • If you can ‘customize’ components just by extending and combining them, you’ll have much more flexibility than any prefab component can ever give you.
  • And even if you would mainly use third party component libraries it should never be an excuse for a framework for their components to be tedious to author. The easier it is to write them, the higher the quality of these components probably will be!

This list is not exhaustive, but gives you an idea of why I think you should not just blindly buy into the argument that framework X is good because it has big libraries of prefab components. 'But they have all the functionality you will ever need!' Yeah, right. I don't need that color select component. Just give me a framework that will let me develop one myself easily and elegantly if I ever need it.





Added Japanese to FormInput example

12 05 2006

And another locale was added to the FormInput example: Japanese. I love to look at these funny characters!

So we now have English, Dutch, German, Chinese and Japanese for that example. I asked some people of the list to provide translations for other languages – Persian, Brazillian and Danish, and I'm asking my girl friend to do Thai -, but if you read this and you don't see your language here yet, please contribute!

I also just added a feature request to create a variant of the form input example that works solely with localized messages. It's cool functionality that if you have templates like MyTemplate_nl.html they get picked up if they match the current locale, but I think it shouldn't be considered good practice. Localizing like this is an exellent break out option if you want to format whole regions of your templates differently according to the locale, but in general just having one page and a bunch of message bundles is much easier to maintain.

Here's the Chinese version:
Chinese FormInput





Rant on Windows-only software

9 05 2006

I switched to Mac a couple of months ago. I'm totally happy with it. Browsing through all the available little cheap apps is like walking through a candy store. I bought more software for the Mac last month than the whole last two years combined for Windows. I've got a slick, fast machine (MacBook Pro 2.0), OSX is stable and pretty, and just in general it feels 'right' to have switched to Mac for development and bookwriting.
There is only one major annoyance: some software isn't available for OSX.

Some of that stuff I can live with. Like Picasa 2 – which is 10 times better than iPhoto – and Skype 2. I hope those products will come out for OSX soon, but until then, I'll use something else.

Others, like Enterprise Architect, are more annoying. If you target the development crowd, I think it is just plain stupid to only support Windows. I posted on one of their forums (started by other people that also were asking for OSX support) and got the unsurpising reply that they thought the market was too small. Imagine that: they make an UML tool – and a good one – which doesn't run on Linux* and OSX! I seriously wonder if the marketing people over there did their homework and have any idea how many developers they are shutting out from their market potential. Btw, I put a * at Linux as they kind of support it, but they want you to install a 'windows compatability layer' – available commercially only – and some other Windows bs first. Right… that looks like an attractive offer (not). Anyway, the licence that I bought last year is pretty useless now. It'll be the last time I bought something without first making sure it runs on more than Windows.

My major annoyance is my Sony MP3 player though. Last year I bought their MD-HD5 music player. It's a great player. It has a good sound, a decent user interface, and the battery life totally rocks (minimum of 30 hours in my experience). What's not so great about the MD-HD5 is that it must be used with software that runs on Windows only. WTF?! They must have spent millions on R&D, production and marketing, but those last couple of bucks to put some extra effort in making software that runs on OSX and Linux too was too much? And how are you supposed to deliver an 'iPod killer' without at least trying to penetrate the main competitor's base camp – the Mac? I am ready to buy an iPod now and ditch the MD-HD5. And Sony will be on my wallet's black list for the next couple of years.

Think of the incredible rise of Firefox. Many companies are finding out that it pays off to not tie their products into a specific browser. And really, if you make browser independence your goal from the start it's not that hard to achieve. I hope publishing software that does run on multiple platforms will be the normal practice soon. Even without using Java it's very doable to write software for multiple platforms nowadays, and if I look at the number of people (developers) that I know personally that use Linux or OSX, many of them being pretty vocal with their books, blogs and conference speaking schemes, I think we'll see something like we saw with Firefox. First people laugh it away, pointing at that 1% market share it has, only to find out that 2 years later they have a problem as Firefox suddenly accounts for 10-15 % market share, and customers start complaining they can't use their favorite browser on some sites.





Wicket and magical stuff

5 05 2006

So you want Wicket to do more magical stuff for you? Great, because I just added a wizard component to the wicket-extensions.

Wicket wizard

You probably already know, but for the sake of clarity: a wizard component is a dialog component that takes it's users through a number of predefined steps. It has common functionality like a next, previous, finish and cancel button, and it uses a transition rules to let clients navigate through it's steps.

The standard implementation of the wizard component is wicket.extensions.wizard.Wizard, and the interface that abstract what the wizard does/ could do is wicket.extensions.wizard.IWizardModel. This model knows what the current step of the wizard is, and knows what transitions are available – handy for turning buttons on and off – and how these transitions should be made (or how to delegate them). A single step in a wizard is defined in interface wicket.extensions.wizard.IWizardStep and it's default panel based implementation wicket.extensions.wizard.WizardStep. Wizard steps are responsible for managing their state (quite natural, as they are just objects like everything is with Wicket), and deliver the header and main content components (typically panels or fragments).

There is an example in wicket-examples that shows a basic use of the wizard. It shows two not-so-useful static wizards and one form based wizard. If you look at the NewUserWizard example, you can see this in it's constructor:

user = new User();
setModel(new CompoundPropertyModel(this));
WizardModel model = new WizardModel();
model.add(new UserNameStep());
model.add(new UserDetailsStep());
model.add(new UserRolesStep());
model.add(new ConfirmationStep());
init(model);

This is how a wizard and it's model gets configured. A new default wizard model is created, the steps are added in the sequence that they will be executed. An interesting note here – not visible from this code fragment, is that the UserRolesStep is an optional step. The condition is encoded as part of the step itself, but you can also externalize the condition if you prefer that.

Here is what a step looks like (the user name step, of which a screen shot is displayed above).

private final class UserNameStep extends WizardStep {

public UserNameStep() {
    super(new ResourceModel("username.title"), new ResourceModel("username.summary"));
        add(new RequiredTextField("user.userName"));
        add(new RequiredTextField("user.email")
            .add(EmailAddressPatternValidator.getInstance()));
    }
  }
}

The two resource models are for the header component, and will return the localized labels for the title and summary, and the two text fields will work on the parents's CompoundPropertyModel (note that using a required textfield is just short hand for using a text field and setting the required property to true).

The markup of that step looks like this (NewUserWizard$UserNameStep.html):

<wicket:panel>
 <table>
  <tbody>
   <tr>
    <td><wicket:message key="username">Username</wicket:message></td>
    <td><input wicket:id="user.userName" type="text" /></td>
   </tr>
   <tr>
    <td><wicket:message key="email">Email Adress</wicket:message></td>
    <td><input wicket:id="user.email" type="text" /></td>
   </tr>
  </tbody>
 </table>
</wicket:panel>

If your reaction to seeing this is: 'hey, but that's not magical enough for me', do something creative and create a nice useful base step for your case. For example, a panel that analyzes the object (model?) you give it, and based on that creates a dynamic form. Or render an xform definition. The wizard package provide you with a basic working model, and some convenience classes, and the rest is up to you. We wouldn't want to spoil all the programming for you ;).

Check the wizard out in the next release. Hope you'll find it useful.





Wicket header contributions with behaviors

3 05 2006

Since Wicket 1.1, it has been possible to do what we call 'header contributions'. You would use header contributions when you want a component to 'contribute' to the head section of the page it is placed in. For example, the date picker component needs JavaScript and CSS to function properly. Using header contributions, components can be truly self contained and keep their dependencies implementation details that users of components do not have to know about.

The basic pattern to achieve this in 1.1, was to let components implement wicket.markup.html.IHeaderContributor, and write the contributions directly to the response that is provided in that interface's method renderHead(wicket.Response repsonse). While that works, it's far from elegant and it doesn't provide you the flexibility adding header contributions through composition instead of via inheritance.

From Wicket 1.2 on, you can use wicket.behavior.HeaderContributors to let components do header contributions. Like other Wicket behaviors (e.g. wicket.behavior.AttributeModifiers), you can add these behaviors to components using the Component.add(IBehavior) method.

There are several convenience methods on HeaderContributor. E.g.

c.add(HeaderContributor.forJavaScript(MyComponent.class, "myscript.js");

adds the packaged JavaScript file that sits in the same package as MyComponent. But you can also do things like

HeaderContributor contributor = new HeaderContributor();
contributor.addContributor(new IHeaderContributor() {
  public void renderHead(Response response) {
    ... write to response directly
  }
});

Further convenience is provided by wicket.behavior.StringHeaderContributor, which contributes the literal string you provide it. That's generally a bit more elegant than just writing to the response directly.

Finally, we combined packaged resources, variable substitution and header contribution to make contributing dynamic JavaScript (or whatever dynamic header part you want) less cumbersome. For example, this is how the YUI (Yahoo User Interface) extensions project at wicket-stuff contributes it's JavaScript initialization script. The code for the model:

IModel variablesModel = new AbstractReadOnlyModel() {
  /** cached variables; we only need to fill this once. */
  private Map variables;

public Object getObject(Component component) {
    if (variables == null) {
      this.variables = new MiniMap(7);
      variables.put("javaScriptId", javaScriptId);
      variables.put("backGroundElementId", backgroundElementId);
      variables.put("imageElementId", imageElementId);
      variables.put("leftUp", settings.getLeftUp());
      variables.put("rightDown", settings.getRightDown());
      variables.put("tick", settings.getTick());
      variables.put("formElementId", element.getId());
    }
    return variables;
  }
};

The code to add a contributing behavior that contributes init.js from the package of Slider and that uses the model we created above for variable substitution (note that currently, TextTemplateHeaderContributor can be found in the wicket-extensions project):

add(TextTemplateHeaderContributor.forJavaScript(
  Slider.class, "init.js", variablesModel));

And finally the contents of init.js:

var ${javaScriptId};
function init${javaScriptId}() {
  ${javaScriptId} = YAHOO.widget.Slider.getHorizSlider(
    "${backGroundElementId}", "${imageElementId}",
    ${leftUp}, ${rightDown}, ${tick});
  ${javaScriptId}.onChange = function(offsetFromStart) {
    document.getElementById("${formElementId}").value = offsetFromStart;
  }
}

There are many ways you can combine these classes. Play around with it and find out!





Moved to WordPress

2 05 2006

I moved my not-so-frequent blogging efforts to WordPress. I like the styles and the functionality, and hopefully this new start will have me blogging slightly more often. It'll be mostly about Wicket, but it might be of a more personal nature now and then. See you around!