Hello again,
Ok, because I needed the features I mentioned, I added them for myself.
Now I'm able to write swigxml-code like this:
...
<menuitem id="mi_exit" InitClass="test.actions.ExitAction"
FactoryMethod="getInstance"/>
...
<button enabled="true" InitClass="test.actions.ExitAction"
FactoryMethod="getInstance"/>
...
All these objects use the same instance of ExitAction. If no ExitAction
is used at all, no object of this type is created (of course...).
So, this code moves swigxml a bit more to the business-logic part of the
code. It allows you to switch some (maybe expensive) parts of your gui
on and of. Especially if the components do create without further
arguments you do not have to take care on them. Just implement them,
test if they work correctly and leave it to someone else to decide if
he/she wants to see them.
On the original swigxml you have to take care on the creation of the
actions for yourself. You have to (correct me if I'm wrong) assign an id
to every button or menu item in the xml. Then you have to write code
which iterates over all of the id's you defined. If one is used (e.g.
the component by getIdMap().get(id) returned a value != null), you have
to create the appropriate Action and assign it to the {button, menu
item, ...}. Of course, one might use a clever String for the id (like
"1.test.actions.ExitAction<getInstance>") but this is not as clever as
to provide the factory method :)
Just tell me what you think of it...
Frank
