SwixML does an excellent job of setting up a GUI. I hate GUI code in
java, and SwixML makes this much more clean. I want to talk about two
things I think I see that are perhaps missing from SwixML: Models, and
Events.
I've included descriptions of these below. I am willing to do the work
to support these. But first, some questions: Do these belong in the
same XML? Or should they be in different branches or whole different
files? Do these belong in the same project? a sister project? Or has
all this been done somewhere already?
"Models" includes, at the very least, a way of populating ComboBoxes,
Lists, Tables, and (in 1.4) Spinners. It might be useful to take this a
step further, and actually abstract access to all component types,
allowing a setValue(componentID, someValue) or a getValue(componentID)
[An example: this setValue call would know how to handle JComboBoxes as
well as JTextFields, though their 'set' methods are different].
"Events" also includes a few things. ActionEvents are the only events
currently managed, and, although they are by far the most useful, there
are others, such as DocumentListeners on textfields. With support from
"Models" above, this could also take the step of abstracting out the
diferent event types into a single unified event type. With this event
structure, data could be easily "piped" from one component to another,
or allow dynamic enabling/disabling of fields.
[A couple of examples: A Radio button group that "pipes" its selection
to a JPanel with a CardLayout, that switches its card to display
another. Another: An 'Execute' button is disabled when a text field
has less than three characters.]
Am I crazy? I don't think so. I actually wrote a Properties-driven GUI
engine 3-4 years ago, and I found the features I mention above quite
useful. My real concern is that I don't want to change what SwixML is,
or step on anyone's toes. Does anyone else want this kind of functionality?
Pat.