Hello,
this was another intention I had in mind with the topic concerning init
classes. I just tried it out.
You (or currently actually it's me only ;-) as long Wolf has'nt released
a new version with my code in it) are able to write xml-code like this:
<table id="itemtable" visible="true" InitType="test.model.ItemTableModel"/>
This automatically calls ItemTableModel.getInstance() if available
(otherwise a constructor is used). This works well if you want to create
models which can take care on themself and some data source finds them
with the help of the id of the table the model is connected to.
Defining (or rather: assigning) actions to GUI elements is a very fine
thing to do. But to define the control flow of the application entirely
in XML is IMHO a bit off the road... You will probably end with swixml
becoming something like luxor (xul) or jelly. In fact, maybe this is
even an alternative... But, as I stated, this is my very own opinion and
I do not have any more right to judge about your idea than you to judge
about mine... Maybe though it suits well for properties to send from one
component to the other. Perhaps you should explain it a bit further...
What I liked very much on swixml is it does'nt want to do everything and
be a problem solver for whatever. It does want define a swing-gui with
XML and that's it. Nothing more, nothing less...
Frank
Patrick Forhan wrote:
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.
_______________________________________________
Forum mailing list
[email protected]
http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com
