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.


Reply via email to