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 as any changes to a XulCompoent you might with wish to make have to do with are on properties of the component and should be handled via a binding.