Hitachi Vantara Pentaho Community Wiki
Child pages
  • Advanced Guide to MVC in Pentaho XUL Applications

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


titleEvents vs State Changes - the story

A major motivation of introducing MVC in XUL applications is to remove all XUL dependencies from the backing model. In a rudimentary MVC implementation, the housekeeping work of wiring up XUL components to the backing model would be handled in the controller. Fortunately, we were able to take one more step in minimizing XUL dependencies by implementing XUL Binding. What this means is now it is possible for your controller to have zero XUL dependencies. I say possible because this is not always the case. There are some limitations to XUL Binding. XUL Binding is simply the synchronization of two Java Bean properties and since user interface events such as a button click are (rightly so) not represented as a bean property, they cannot be bound. So here is the important distinction, UI _events_ must be handled in their own handler methods within your controller while component _state changes_ will be bound to your model in the onLoad method of your controller.  So back to my statement that it is possible for your controller to have zero XUL dependencies.. this is true if your view doesn't require any event handling, but if it does, your controller will have to handle the event explicitly.  As such your controller will typically have references to XulContainer subclasses (the events will typically launch dialogs and windows).  Even so, your controller should still have zero references to XulComponent subclasses since changing a component in a controller means setting bean properties on it, which would be better handled by a binding.

Data Binding and Component State Changes

It is the responsibility of your Controller implementation to setup bindings between your XUL components and your model (a POJO/Java Bean). What do we mean by "binding"? Binding is a way to associate bean properties so that when one changes, the other is kept in sync. Binding can be unidirectional or bidirectional, but we won't get into that here.  For more information on this see XUL Bindings. For the purpose of this document we will assume that a binding is always bidirectional meaning when either side of the binding changes, the other will reflect the change. This is useful in UI applications because we can tie, say, a text box's value to a model bean String property.  Consider the following XUL file snippet that defines a text box component by id "nameTextBox".  Notice that there are no attribute specifying event handler calls; these are not needed when using data binding.


titleHow do I know which properties to bind?

A helpful point to realize is that binding is not magic, it is simply a synchronizing of 2 java bean properties. Bean A is your XulComponent subclass and Bean B is your model. If you want to know what component properties you can bind simply lookup your xul component, say XulTextbox, and take a look at its bean properties. You can configure a binding to any property of your xul component object.

Handling of UI Events

In the diagram you will see that the XulDom fires "events" to the FooController.  As we mentioned before, these events are not state changes of a XulComponent, rather these are launching and routing operations such as displaying a dialog.  Events are declared in xul source file as tag attributes, e.g.:


Code Block
XulDomContainer container = xulLoader.loadXul("/path/to/my/xul/source/file.xul");

Foo Example Source

Code Block
// Manages the state of the view or form.  This includes component values as well as enablement,
// visibility and form validation.  Your ViewModel could delegate to or synchronize with a (persistent) domain
// model if you require.
public class FooViewModel extends ViewModel {
	private boolean okEnabled;
	private String name;

	public boolean isOkEnabled() {
		return okEnabled;
	// Any bean property that is using for binding must fire property change events
	public void setOkEnabled(boolean okEnabled) {
	 	this.okEnabled = okEnabled;
		firePropertyChange("okEnabled", null, okEnabled);

	public String getName() {
		return name;
	public void setName(String name) { = name;
		firePropertyChange("name", null, name);

	// A very simple validator that allows the user to procede if there is anything in the name field.
	// Notice that we are not manipulating  UI component here to achieve this, just a bean property.
	private void validate() {
Code Block
// The Controller has two roles 1) setup bindings for view state and 2) handle UI events
// A Controller should not contain references to XulComponent or subclasses.  If you find yourself
// referencing these, you should probably be binding to them instead.

public class FooController extends AbstractXulEventHandler {
	private FooViewModel fooViewModel;

	public FooController() {
		fooViewModel = new FooViewModel(); //FYI we prefer to inject the models via an IOC container, but for the sake of simplicity...

	// This is the name with which to register instances of this controller.  Typically we would set this, but for simplicity we hardcode it.
	public String getName() {
		return "fooController";  //this name should match event handler aliases in the XUL source file

	// Here we are binding two properties from the model to properties on two XUL components.
	public void onLoad() {
		bind(fooViewModel, "name", "nameTextbox", "value");
		bind(fooViewModel, "okEnabled", "okButton", "!disabled");

	// The XUL framework will find and call this method when the Search button is clicked
	public void displaySearchDialog() {
		XulSearchDialog searchDialog = new XulSearchDialog();; = searchDialog.getName();

Quick Reference


  • Represented as a Java Bean (with property change support)
  • "Models" view state as bean properties
  • Contains view logic such as enablement and visibility
  • Applies form validation
  • Contains *no* references to Xul of any kind


  • Represented in the XUL dom (via XUL source file)
  • Contains syntax for creation of UI components
  • Layout of UI components


  • Represented as a Java class that implements XulEventHandler
  • Binds UI state to the model
  • Performs UI evnt handling (not related to component state) such as launching of dialogs (XulDialog and XulWindow)
  • Should *never* reference XulComponent or subclasses