First post

Hi

I thought, since Wolf(?) was kind enough to quote from my blog
on his pages, I should send email to thank all the people who
have been working on SwiXML. As one of the original contributors
to XML, it is great to see it used in this way.

My company, Topologi, is just about to release the Professional
Edition of our high-end XML markup product. You can see snapshots
of the menus at http://www.topologi.com/products/tpro/screenshots.html
but please don't link to them: we have a lot of menus.

We only use SwiXML currently for for the frames and menus.
Previously we used Visual Age Visual Builder for these. I liked
using Visual Age (which has now migrated to Eclipse in some form)
but it generated terribly verbose code all into a single file.

By moving to SwiXML, we have
  * reduced our source code size by 500K (unbelievable, but that is 
Visual Age!)
  * improved maintainability
  * seemingly improved our start-up time, though we have other
changes so I cannot measure it.

Looking at the archives for SwiXML, here are some comments on
some of recent issues: I think speed is good now so implementing
SAX might be an unnecessary diversion; also, I think it would be
good to have bindings to other libraries such as JGoodies, but not
built-into the core jar (this is because I think that, ultimately,
there needs to be co-operation and co-ordination between different
open source software efforts to make a competitive platform
for desktops: Sun is still thinking in terms of applets and
servers.)

Some-one also recently asked about a dispatching layer for actions:
what we do is that every action name has a prefix and there is
an ActionListener for each prefix: so the dispatcher gets each action
then forwards it to the appropropriate ActionListener depending
on the prefix. So menu items with an "EDITOR_" prefix get routed
to the ActionListener for the editor. This decreases coupling
very neatly.

The area I suggest that SwiXML could be enhanced may seem at
first to be out-of-scope: when developing middle-to-large
sized applications, the issue of adjusting the interface to
accomodate the current capabilities of the objects selected
become important. This is primarily enabling and disabling
menus, but can also be changing icons, colors and sizes.

The trouble is that SwiXML hides a lot of complexity of
Swing, but then when you have this kind state-behaviour,
you need to move to code again. I think there is a
declarative way that would be quite simple to implement
reflectively.

Add to SwiXML something like

<!ELEMENT stateSets ( stateSet )+ >
<!ELEMENT stateSet  ( state )+ >
<!ELEMENT state     ( menu | menuItem | ... )+ >

<!ATTRIBUTE stateSets
	name CDATA #IMPLIED >
<!ATTRIBUTE stateSets
	name CDATA #REQUIRED >
<!ATTRIBUTE state
	name CDATA #REQUIRED >

For example, here is a stateSet to reflect that you don't
want the Save menu item to be enabled before you have
altered the file.

<stateSet name="FileState">
	<state name="fresh">
		<menuItem name="mi_save" enabled="false" />
		<menuItem name="mi_undo" enabled="false" />
		<menuItem name="mi_redo" enabled="false" />
	</state>
	<state name="dirty">
		<menuItem name="mi_save" enabled="true" />
		<menuItem name="mi_undo" enabled="true" />
		<menuItem name="mi_redo" enabled="true" />
	</state>
	<state name="clean">
		<menuItem name="mi_save" enabled="true" />
		<menuItem name="mi_undo" enabled="false" />
		<menuItem name="mi_redo" enabled="false" />
	</state>
</stateSet>

The idea is that each state contains, not a new object,
but a set of properties that get applied on an existing
object. So my code can just say

   mySwiXMLGUI.setState("FileState.dirty");

and then the properties from that states will be set to
the values supplied. Note that this only needs to use the
same reflection that SwiXML currently uses.

It is very simple: no stacks, no listeners, no undo,
no conditions, no enforced transitions.  But because
a state is just a bundle of property values, there
can be several stateSets at the same time: conflict
is the user's business. For example, in our application
we would use a stateSet at least for the kind of Tab selected,
for the fileState, for validation state, for
visual mode, and for pen selection mode, if they were available.

I think this would give SwiXML quite a leg-up compared
to other GUI systems. Anyway, that is would be at the
top-of my wishlist, because it would simplify and expose
the GUI state, allowing Swing-specific properties to
be removed more from application code.

Cheers
Rick Jelliffe