Re: Action and ActionConvertors

>Have a careful look at the code, it is (or may be) used again ;) Probably you

Well I was searching for the variable named 'action' which isn't found again,
except in the mac_map. Which I confess, I do not understand!

>It is the line you mentioned: method.invoke( obj, new Object[]{para} ); //
>ATTR SET

Yes, that's it. Sorry, my confusion was that I was thinking obj is the client
object, rather than the Swing-created-from-XML-object. The client object, I now
realise, is the getEngine().getClient() ..

>private. Furthermore, the AbstractButton.setAction(Action a) does a bit more
>the just this.action = action;

Yes, especially the Action setters register the callbacks etc.

>So, SwixML has to use the setter, likewise in probably 99% of all other
>attribute assignments. The attribute "myAction" of the class provided to the
>SwingEngine-constructor is another thing. It may be seen as "public interface"
>because it is used as user interface anyway -- that's what actions are for,
>arent't they? See the public Action attributes somewhat as unibersal "button"
>represantations. The last point is pure practical: the object given to
>SwingEngine is usally written by yourself, so you have the choice/possibility
>to make these attributes public.

Exactly. And these are 'beans' so they are made public.

Let me explain what I was trying to do. I may be going about it the wrong way,
in which case someone may have a better idea.

I had thought to have a 'wizard' like interface, with back and forward buttons.
The outer panel would have these buttons, arranged at the bottom. The panel
would have a center panel for cards (cardlayout), and my wizardbase class would
a) populate the cards panel using a constructor file list (ie call swix to make
the UI for each card, setup the cardlayout etc.) , and b) provide a default
implementation of the back and forward buttons, for going to the next and prev
cards.

A class which wanted this wizard functionality would derive from wizardbase,
and if it needed extra func. would simply override the behavior.

The difficulty is that swix directly accesses the client object field for
action, and of course that means I have to put Action X in either the base or
the child. If there had been a getter instead of a direct field access, I could
have used method overriding to call different getters (in parent for default,
and in child when new functionality is added).

I guess what I was planning was a hack, and like all hacks, there were
significant reasons why it was a bad idea :-)

>I hope I did shed some light on the topic,

again, many thanks.

-- 
Nandan Bagchee


We need a language that lets us scribble and smudge and smear, not a language
where you have to sit with a teacup of types balanced on your knee and make
polite conversation with a strict old aunt of a compiler.

		-- Paul Graham