Kate, I understand, you would like to be able to fill combo boxes through XML Descriptors - I admit this is an absolutely valid request. In fact if you read through some older posts I think it was requested a couple times already.
So far we have pushed this off because we think that for most other widgets that support models (like JTree, JList etc.) java code is much more appropriate to setup the models. But then again, most of the time I need models, the data is generates at runtime on a remote server and therefore I have to use code to parse the incoming XML ... I think we will introduce custom tags to setup combo boxes and maybe some others as well but probably not for trees etc. You could implement and register your own tags to make this happen. There is a short but I think helpful example about custom tags an the sample page: http://www.swixml.org/samples/index.html Wolf > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Kate Rhodes > Sent: Friday, March 07, 2003 8:37 AM > To: [email protected] > Subject: RE: [Forum] Events and Models > > > 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 > > > _______________________________________________ > Forum mailing list > [email protected] > http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com > >
