Xul, noun:
(1) the sumerian word for "evil". According to the "Necronomicon" (the book of the dead, well known from various movies (javascript:void(0);/*1220547287191*/)) conceived by H.P. Lovecraft, most of the less pleasant Gods of ancient Sumer were named "~ Xul".
(2) the name of the evil diety in the Ghostbuster movies.
(3) the name of the Xml-UserInterface-definition Language of the Mozilla Foundation.

Yesterday, on a dark and stormy night, I finally completed the ritual of summoning. While thunder rolled in like waves from the ocean, crows screamed through the night and an unholy gloom covered the landscape in a rotten light, Xul heard my calls and in (yet another) exchange for my immortal soul I gained control over powers no sane human should possess.

It all started a long time ago, on the fateful day we decided to sacrifice the old report-designer's codebase on the altar of the Gods of Clean and Maintainable Designs. The reborn designer should not only be bigger, better, faster .. [a lengthy list of positive properties later] but also more maintainable, so that we spend less time fighting the structure and more time being productive. In my book, that immediately boils down to modularization. It worked perfectly well for the reporting engine, works for Kettle, even the Platform heard the call and transformed the Platform 2.0 into a modular design.

So we all agree - "modular is good"(tm) . But only the evil guys can take the treasure without paying. Good things always come at a price. And that price in software engineering boils down to adding extra code and rules to manage the modules.

In the meantime, on a continent far far away, Pentaho created a new UI project to use the powers of Xul to make common dialogs and UI elements more reusable. Pentaho-Xul reads a subset of the Xul language and allows to create scripted UIs much similar to what Mozilla's webbrowsers do. The Kettle-Database dialog was the first one to be Xulified; later some internal projects followed.

Xul provides several easy ways to create pluggable and extensible UIs. You can either include Xul-Fragments or you can use overlays to reconfigure a existing UI from within a plugin. (Xul, being a evil deity knows: Ascetic purity is for saints. Offer an easy way, and you won't have troubles harvesting sinners.)

For the new report-designer, full Xulification was never an option. After all, we wanted to get rid of magic instead of adding yet another layer of automagical super-configurable UI-or-whatever-generators. But we still have - no, had - the problem of allowing customizations of at least the toolbar and the menu.

And so Xul entered my life through the backdoor. The voice roamed through my nightmares and promised easy salvation. At the end I had to give in. Luckily Xul is not one of the old fashioned daemons, who always request bloody sacrifices of goats or virgins (Ever tried to find a virgin these days? Forget it!) Xul just wanted to be a integral part of the project and all plugins we or anyone else ever writes, so that he can fest on the souls of the unhappy fools who try to find a Xul-specification document or officially blessed documentation of any kind. I've spend my early years as Cobol and RPG/400 programmer, there's not much soul left here, so buying in was easy for me:

Report-Designer 2.0 ships with Xul.

Pro: Plugins can inject themself in all menus, context-menus and the toolbar.
Con: Your soul may be at risk, if you try to use Xul to modify anything else in the report-designer or if you try to find documentation other than the code.