De Tout Et De Rien

When browsing the Eclipse SWT website, you can be a bit surprised... Here is what you can see if you read the SWT 3.2 Plan carrefully :

Needless to say, that these babies won't be part of the download...

When dealing with message folder, the temptation is strong to re-invent the wheel when it comes to make a search through its messages. One evident solution is to grab all the messages, test against the criteria, and if the message matches, store it for further need.

Since JavaMail 1.1, a search facility has been provided. It is located in the jaxax.mail.search package. To make a complex search, you just create the needed search terms and compose them with a AND or OR operator. The next step is to call the magic method on the message folder : Folder.search(SearchTerm term) that returns an array of Message instance.

It may be look weird to add such complexity to a simple search in a mail folder, but when it comes to term composition, this solution is the most flexible and above all, when you look at your code, the nicest one.

In Tapestry, a page or a component development usally involves three elements : a template file, a specification file and Java class. It is the most common case (even if there are some cases where one or two of theses elements are not used).

What I find annoying in the Tapestry specification files is :

• Inheritance : pages or components class can inherit but not their specifications. It leads to duplication of informations.
• Composition : pages or components class can be composed but not specifications. It leads to duplication of informations.

As I am exploring the JDK 5.0 and its annotations, I wonder if Tapestry 4.0 could handle components and pages definitions without specification files (the .page or .jwc files), only by using Java annotations. The basic idea behing is to move the content of the specification file into Java class by using annotations. Let's take an example :

The following specification part :

<component id="select" type="DirectLink">
    <binding name="listener" value="listener:makeGuess"/>
    <binding name="parameters" value="letterForGuessIndex"/>
    <binding name="disabled" value="letterGuessed"/>
</component>

@Component(type = "DirectLink", bindings = { "listener=listener:makeGuess", "parameters=letterForGuessIndex", "disabled=letterGuessed" })
public abstract DirectLink getSelect();

To go further and to illustrate the general concept on a sample application, I took my port of the Hangman application and convert all the pages and components using the method described above. It is available for download (please note that a JDK 5.0 is required to run this application), source code is included (under public domain of course). In short, I am using an ISpecificationDelegate implementation that can handles specification-less pages and components.

As a conclusion, I will said that without specification files, the development under Tapestry can benefit from :

• True inheritance. Annotations are inherited by sub-classes so pages or components are clearer and simpler.
• True composition. As most annotations are put on abstract methods, they can be gathered in interfaces. Creating a page can be as simple as compositing interfaces on top of abstract class.
• Less error-prone. The specification file can be a source of error as it must be in sync with the template and the class.

This development method as also its drawbacks :

• Class have more lines and mostly reference components through abstract getters. This can be addressed by factorisation and use of inheritance and composition.
• Annotation syntax is hardier to read than its XML counterpart.
• JDK 5.0 is required to support this feature.

I am requesting feedback from the community about this approach. Is it a way to reduce the development cycle in the KISS philosophy or is it just a overuse of the Java annotations ?

I have updated the Hangman application for Tapestry 4.0. It is now running with Tapestry 4.0b13 and Hivemind 1.1. Of course, source code is included, released in the public domain et feedback is welcomed.

For those who are insterested, my initial port is here.

If you are a Confluence user, here is a trick to display SkypeMe buttons within Confluence pages. It is a simple macro that takes the Skype pseudo and set up a button around it. The result is an inline image which starts a Skype call when clicked (of course you need Skype installed on your machine).

To define the macro, log into Confluence as an administrator and select the "User Macro" menu on the left. Select "Create Macro" and type the following :

<a href="callto://$generalUtil.escapeXml($body)">
<img src="http://goodies.skype.com/graphics/skypeme_btn_small_green.gif" border="0">
</a>

Use the macro as following :

Wiki Source	Result
{skypeme}bill.gates{skypeme}

Update (2005-12-23) : Charles Miller has added this macro to the Confluence Site. I have modified the code to reflect his advice : using the $generalUtil.escapeXml() function to avoid cross-site scripting attacks. Thank to you Charles !