ok a) I think combo boxes, lists, trees, and anything similar should be able to be populated in the XML. b) I agree with frank about not wanting swixml to start including any scripting functionality. I like that it's just basic GUI. c) why couldn't we have something like action="windowAction" actionType="java.awt.event.WindowListener"
which would call addWindowListener on the object in question and add the windowAction object. in swixml it would be a JFrame ... if the person it silly enough to try adding a WindowListener to a List, for example, it dies. wouldn't this be doable and useful without getting to far into scripting? as for "a" I think there should be something like a <listItem>item one</listItem> for -Kate -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Frank Mei?ner Sent: Friday, March 07, 2003 11:18 AM To: [email protected] Subject: Re: [Forum] Events and Models 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 > > _______________________________________________ Forum mailing list [email protected] http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com
