TabPanel Issues

I invite concrete constructive corrections (3C responses)
to the following analysis ... :-)


I've almost reached the point of being able to select
TabPanels, but there appear to be some major gaps in
the underlying Luxor architecture that still obstruct
the process.

You need to add something like the following to the
luxor.swing glue. The swing action on selection should
then do what is needed.

TabBoxPeer.java:
    // TODO: mark this as a SingleSelection Interface ???
    public void setSelectedComponent(NComponent comp)
    {
       try {
          _tab.setSelectedComponent(comp.getJComponent());
       } catch (IllegalArgumentException iax) {
          // TODO:  log it and maybe rethrow
       }
    }

Note, presumably it is preferable to do this in the
luxor.swing layer under the assumption that these
classes will become interfaces and impls when the
plugin for alternate toolkits is realized. Thus one
wants to use luxor handles like NComponent and not
swing ones like JComponent.

There are two stumbing main blocks. The first is that
the NComponent, NContainer, NInput handles are all
pretty much private to Luxor (while it makes it really
easy to get JComponent handles). The N<interfaces> may
be passed in through constructors, or setComponent(),
but then all calls to them are wrapped in user level
objects like XulInputs and they become pure internal
delegate classes.

The second which follows from the first is that the
current user level wrappers are inadequate. And lookup
methods on things like ids are missing or misdirecting
(they are usually creates).

The only user level handle for operations like TabBox
selection at the moment appears to be XulInput. This
is not generally registered for lookup with the
XulManager, but rather internally registered with the
XulForm that represents the top-level container. This
is what LinkControls hooks up for you during the
constructor setup() step.

Thus if you want to get a handle to a <box id="aBox"\>
you need to create and remember the XulInput during
Form construction.

But XulInput is a fairly specialized beast that must
support methods most typical of a Button/Label. Boxes
which are NContainers are a divergent subclass of
NComponent from the NInput needed for LinkControls.

Ergo, there is no way one can create and remember or
lookup the necessary references to do something like
the following XulAction which hooks up a MenuItem
command "rEconomy" to a <tabbox id="vTabbed"/> at
the tabpanel <tabpanel id="vEconomy"/>.

     XulInput vEconomy = new XulInput(this, "vEconomy");
     XulInput vTabbed = new XulInput(this, "vTabbed");
     TabBoxPeer tabbox = ((TabBoxPeer)vTabbed.getComponent());

     new XulAction("rEconomy") {
       public void execute() {
         tabbox.setSelectedComponent(vEconomy.getComponent());
         client.execute("showreport Economy");
       }
     };


Solution?

The two key elements seem to be:
1) need a generic getComponent() method/interface
    ---  and/or  ---
2) need to generalize XulInput to handle generic
    elements, and then subclass or extend it with
    interfaces to handle specific sets of Input ops.

It seems to me easiest to define a generic
XulComponent interface that has get/setters for
NComponent, and possibly the Focus methods of
XulInput as the handle for all Xul components
that one would want to interact with. LinkControls
in the XulFormHelper could then manage the generic
component, rather than just the current label-like
XulInput flavour.

This interface could then be supported by any
Impl class like TabBoxPeer that needs to export
operations.

Each set of operations could further be classified
by interfaces like XulInput, XulSingleSelection
i.e. the user-level wrapped counterparts to NInput,
NSingleSelection, NContainer ... that would provide
the necessary handles for their recognition and use.

A last possibility is to provide a XulManager registry
for XulComponents, rather than passing them as refs
where needed. But this gets into scoping issues.


But maybe there is already another way to do this?

Cheers,
RossW
=====



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge