Shandor Xul Merge plan

Owned by Former user (Deleted)
Last updated: Jun 04, 2010Version comment
2 min read

As we wrap-up the latest release and look forward to upcoming sprints, I'm planning on merging the Pentaho and Shandor XUL branches. There are a lot of features in Shandor that can benefit us and others that we absolutely need. As this merge isn't trivial and many core APIs are going to change, I'm seeking all feedback about your experiences with Pentaho XUL and specifically feature requests or API changes. Now is the time to realize broad changes and new ideas. Hit me up yo!

I've compiled a list of features in Shandor that will make it through the merge to give you an idea of what's upcoming.

Asynchronous APIs everywhere.

This mainly impacts the loading of overlays at runtime, but also includes a generic callback interfaces to base service calls on. Coding asynchonously facilitates code portability from SWT/Swing to the thin-client GWT world.

Completely abstracted DOM

The current Pentaho XUL uses Dom4J in the loading and parsing steps. Shandor has abstracted this away allowing us to use the same parser between Swt/Swing and GWT as well as facilitating the replacement of the Dom4J implementation for a strait W3C one

Simplified Component design

No more 4-arg constructors. Components are given their abstracted DOM node from the parser (see above) from which they can extract all needed information.

BeanUtils has also been emulated for GWT removing the need to extract component values from attributes as the GWT components currently do. Note this still needs to be evaluated for performance.

onDomReady Event

The onDomReady event is propigated down the Component tree when everything has been parsed. This allows SWT to construct it's components in the natural manner by passing in the intended parent. By contrast the current design re-parents all components in the layout routine. This will speed up SWT loading and solve some layouting issues.

Integrated Messaging

Access to the message bundles used to contruct the UI via document.getMessage("key", args...). Results are computed with overlays taken into account allowing overriding of default values

Other things on my wish-list which haven't been coded yet:

  • Component Listeners. These would be used as alternatives to bindings similar to how we're using manual PropertyChangeListeners today. The Listeners would also allow the vetoing of continued propagation.
  • Enums on the components listing the bindable properties e.g. XulButton.Props.DISABLED == "disabled". More of a convenience for authors.
  • A metric ton of unit tests with a focus on generic component testing. These tests would be run on all three implementations checking for consistency of behavior i.e. when initially loaded all listbox implementations have a selected index of -1.
  • Base classes shared between the implementations. For instance the SwtTree and SwingTree share ~50% identical code.
  • Upgrade XUL-GWT to GWT 2.0