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

Versions Compared

Key

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

...

Info
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 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 method methods within your controller . The end result is your controller will take on a dual role, it will handle UI events via handler methods and it will setup bindings.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 to make have to do with properties of the component and should be handled via a binding.

Data Binding and Component-state Events

...