[luxor-xul-develop] Luxor goals for the future

[David C. <da...@ca...>]

Is there a document anywhere that specifies the goals of the Luxor
project, and the plan for acheiving them?

>From the Luxor overview:
-Separate the UI into 4 distinct parts: content, appearance, behavior,
locale
-Make UI building easier than writing it all in Java
-Free from GUI toolkit lock-in

Others I think should be included:
-Ease of development (rewording of #2 above; easy-to-use API with
complete documentation)
-Well-defined XML formats
-Simplicity (avoiding feature creep, excess XUL tags, etc.)
-Use "standard" libraries when appropriate
-Dependencies on external libraries only when "needed"

With these in mind, I think that the first goal should be ease of
development, with the discussion in the user list on Thursday in mind,
starting with discussion of how we think users should interact with the
Luxor API, and then design of an API that facilitates this.

An approach:
-Have a class (for now, call it XulManager) with the following methods:
Object getRootComponent(final String path);
Object getComponent(final String path, final String id);

The "path" argument is the name of a XUL bundle (set of XML files), which
defines a top-level window (frame, dialog, etc.).  Using getRootComponent,
you can retrieve that window.  Alternatively, using getComponent, you can
retrieve any arbitrary component within the window by id as specified in
the XUL.

In this example, the return types are Object.  This allows flexibility as
to the GUI toolkit used to implement the manager.

-For a particular GUI toolkit, provide a Facade.
For example, a SwingFacade might provide the following methods:
public final JPanel getPanel(final String path, final String id);
public final JFrame getFrame(final String path);
public final JDialog getDialog(final String path);
public final JWindow getWindow(final String path);
public final JTextArea getTextArea(final String path, final String id);
public final JTextField getTextField(final String path, final String id);
...

If it turned out that retreiving components by id was a frequent
operation, we could have a variation on the Facade that was specific to a
XUL bundle, thus requiring only the component id as an argument.

-XML format restructuring
As stated on the Luxor overview, we wish to separate the UI into 4
distinct parts.  Our existing XUL format handles content/layout fairly
well, though it could use a bit of tuning.

Appearance can be handled by CSS, which is a standard format with a
standard API to read (SAC).  Rather than embed our styling information in
the XUL file, I would prefer to have it in an external file, to promote
distinctness between the 4 UI parts.

I think that behavior should be handled by some form of behavior mapping
XML file, where you associate standard GUI controller classes with
components defined in the layout file.  For example, you could have an
entry specifying that the action for the OK button should be
com.something.OKAction, and that the mouse listener for a certain table
should be com.something.MyListener.  This might also be an appropriate
place to allow things like setting custom models, renderers, editors, etc.

For localization, traditional Properties ResourceBundles are a good start.
These could be linked into the layout file either by defining certain
attributes to specify the name of a key in the ResourceBundle, or by using
a ${key} syntax to allow localization in any attribute.  I'm less
clear on how the internationalization of layouts themselves works.  For
example, when in a locale with right-to-left reading order, the labels
should be to the right of their associated GUI objects.  Perhaps to
support this, we should look up layout files by locale similarly to how
localization properties files are located.

-----------------------------
David Carr
-----------------------------
Email: da...@ca...
-----------------------------