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.

MVC in Pentaho Xul XUL applications can be acheived by architecting your application using the pattern we will detail here.  As a refresher, the purpose of the MVC pattern is separation of concerns in UI applications.  The idea is to keep a clear separation between the data we would like to display and how that data is being displayed.  In Pentaho Xul XUL framework (PXF) the view layer is represented at least partially represented in a xul dom object (typically coming from a xul file).  I say "partially" because you could consider view logic to be part of the view and view logic is not included in the xul dom. XUL DOM

The diagram below shows how Pentaho Xul XUL MVC would operate in an example UI widget project Foo.  Starting from the left we see that the xul XUL file foo.xul is represented in your application as a XulDom.  The XulDom is what we consider to be the View of our MVC implementation  The Xul framework PXF by way of the XulDom is responsible for instantiating and laying out UI components, however, as we mentioned earlier view logic is not handled by the XulDom.  The responsiblity for handling view logic rests on the Controller and can be thought of as being component-state changes or non-component-state events. These two classes of events are handled differently in the Controller.  Events are handled directly in the controller whereas component state changes are simply mapped in the controller, leaving the handling of state changes to the binding layer.  By structuring your application this way, you will have zero dependencies on Xul inside your Model which makes your model much more testable.  Only your Controller code will know anything about Xul in the case that it needs to launch XulDialogs for example.  Your Controller, however, should never need to reference a XulComponent directly.


Code Block
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

	public void onLoad() {
		bind(fooViewModell, "name", "nameTextbox", "value");
		bind(fooViewModell, "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();; //I wish launching a XulDialog were this easy! = searchDialog.getName();