Hitachi Vantara Pentaho Community Wiki
Skip to end of metadata
Go to start of metadata

The Pentaho XUL Framework Developer's Guide

Project Details

Project Name

pentaho-xul

Project Description

The XUL Framework is a project that is attempting to provide an architecture for different UI technologies to be mapped and rendered from the the Mozilla XUL specification. The purpose is to be able to render a user interface across multiple technologies (Swing, SWT, GWT) without the overhead of rewriting the presentation layer every time, and providing technology agnostic business logic code for reusability.

Status

Currently in the process of merging with the Shandor XUL branch.

Source Location

svn://source.pentaho.org/svnroot/pentaho-commons/pentaho-xul/trunk

Future Mercurial Home

hg clone http://bitbucket.org/codeoncoffee/shandor-xul/

Lead Developer

Nick Baker

Use Cases

Pentaho's custom XUL framework exists so that developers can create user interface definitions that can be reused across multiple technologies and multiple products. As a consequence, you can also easily replace or redesign a user interface. The following use cases clarify the reasoning behind building the framework, and also help identify under what circumstances a developer may want to use the XUL framework instead of programming a traditional UI.

Use Case 1: Common Dialogs

All of the Pentaho tools share integration points with the platform, additional third party tools, and each other. These integration points usually require similar (if not identical) dialogs in the user interface in order to interact with that particular feature. Many of these tools are not built upon a common technology because they have separate origins. A common definition for the dialogs, along with a framework that supports the necessary renderers for that user interface definition, relieves the developer from having to change the layout or functionality, and from having to build the dialog from scratch every time a new tool comes along that is based on a new technology, or a new integration point requires another common user interface.

Use Case 2: Customizable Menu Systems and Toolbars

The Pentaho community, partners, and clients frequently request the ability to customize the options available in Pentaho client tools, as well as in the platform demo interfaces. Building the toolbars and menu systems in Pentaho's products using an XML definition allows developers to easily add or remove functional options. The XML definition describes the available options with a reference to how they should behave.

Use Case 3: New Tooling Applications

There are new applications in development which require the ability to plug into existing tools and future architectures. These "tooling applications" can generally be thought of and used as standalone applications, but don't make a lot of sense outside of the larger Pentaho client tools or the platform itself. The new Chart Editor is an example of such an application.

Overview

The XML User Interface Language (XUL) is an interface design language originally developed by the Mozilla Project for use in creating Web browser user interfaces. The project home page, which includes an in-depth explanation of the reference XUL implementation, is at http://www.mozilla.org/projects/xul/ . There is also a formal XUL 1.0 specification, but it is seven years old and mostly unwritten: http://www.mozilla.org/projects/xul/xul.html . You can find a better, more comprehensive set of XUL resources is in the Mozilla Developer Connection: http://developer.mozilla.org/en/docs/Category:XUL.

Writing user interfaces in XUL requires a complete implementation of a rendering engine to display them in. Gecko-based browsers such as Firefox, Netscape, Mozilla, and Galeon have XUL support built in, but others do not. Pentaho has its own entirely XUL 1.0 compliant rendering engine built into the BI Platform.

The XUL Framework starts by processing an XML user interface definition, as XUL is, inherently, an XML technology. The XUL specification lends itself well to providing definition for a standard widget toolset, the kind most developers would be comfortable with if they have used SWT or Swing. The spec does not allow for or account for more advanced components or completely customized components.

Pentaho has extended the XUL specification with its own namespace in order to accommodate advanced functionality and customized UI components. The rest of this document explains this custom implementation in detail.

  • No labels

10 Comments

  1. I think, this has some serious potential, if the project could actually do what it states to do. Luxor, XUI etc. have huge limitations.

    When would this roll out as a non-beta.

  2. We're in the process of refactoring some behind the scenes code before posting it to http://code.google.com/p/shandor-xul/

     I anticipate this taking place within the next 2 weeks.

     There's a lot of doc to be written / updated and sample projects to post as well. Stay Tuned!

  3. Suraj, I hope you come back to this page to get this. I've tried contacting you by email with several accounts, but the messages are not going through. Please contact me again with a different email address.

  4. There's really a lot of anticipation around Shandor. Its the "talk of the town" in the java GUI lore.

    I had certain doubts, though:

    1) I was wondering about scalability issues, if any. I mean, would it fit for huge client frameworks.

    2) Success of any software lies in its demo, I could'nt find any. Can you point me to some.

    3) Quite a lot of the test cases in SWT are failing. Seems to be some problem around "alignment" enum in AbstractSwtXulContainer( I was using Shandor 2.5 from google code)

    4) Any latest version of the code to checkout, so that we can evaluate.

    Beautiful work.

  5. In the above comment, when I mentioned "huge client frameworks", I meant to include features like docking, MDI and other RIA features

  6. Penthao Xul was designed to support MDI and the constructs are still there. We've never had a use-case for it though so I'm sure it would need some work.

    We've found that it's more convenient to run multiple XUL documents and have them share controllers or models as needed. This is a natural fit in a Spring IoC setup.

    As for other RIA work, we have a story on our Chart Editor backlog for May to add Drag & Drop support to the framework with Swing and GWT support.

  7. Thanks Nick for your fast response.

    Actually we are evaluating all XUL implementations to choose one of them for our framework usage.

    Initial analysis says that Shandor seems pretty much(the most) appropriate and seems quite extensible too.

    Some points:

    1) Planned date for non-beta release.

    2) We analysed code for Shandor2.5 from google code, but I guess the code would have changed lot since then. From where to get the latest code so that we can evaluate further.

    3) A format XML schema for Penataho XUL.

    4) Any formal feature list  supported by XUL

    It would be nice if you could shed some light on the above points

    Thanks for your support, Nick.

    PS:  I am able to recieve your emails.

  8. Suraj,

    Still getting emails bouncing back to me. I'm going to have a forum setup tomorrow for the Xul project.

    1. When Shandor is released we'll update our internal project trunks to use it. It'll probably be another quarter before formal QA is done on our next release. After that I'll be comforable with a 1.0 label.

    2. You can get the latest code at svn://source.pentaho.org/svnroot/pentaho-commons/pentaho-xul/trunk. There has been no SWT work since 2.5, it's been heavy Swing and GWT. I'm currently pulling it down to find the issue you're having. We do have much planned for SWT soon though as we have a Data Access project that will deploy on all three technologies.

    3. We do not have a DTD or XSD at this time. The enhancements we've added are all on a separate namespace, but are not many. The Binding declarations mostly.

    4. This is on my TODO list for the Shandor launch.

  9. There were several incorrect paths in the tests. Those have been fixed and all SWT tests are again passing. We're not building 2.5 artifacts in our continous build environment (http://ci.pentaho.com), but I will request a rebuild of 2.5 if you need.

  10. Thanks Nick for your support.

    I will check the latest code from the given path.