that's what I've been doing.... I guess this is another one for the "requested features" pile then.
-kate -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Wolf Paulus Sent: Wednesday, March 05, 2003 2:59 PM To: [email protected] Subject: Re: [Forum] Re: swixml .. What is still missing? Kate, You need to use a data model to set up the combo-list. There are no tags that would support setting up a combo box through XML Kate Rhodes wrote: >speaking of missing documentation.. I think it would be fairly easy and not >too time consuming, but immensely helpful if on each tag page there was an >example of that tag with all it's potential attributes. > >ex. I can't figure out how to add elements to a combo-list in the xml but >I'm sure it's possible. an example of each tag would solve this and many >other questions without having to write lengthy documentation. > >-Kate > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Wolf Paulus >Sent: Wednesday, March 05, 2003 1:54 PM >To: [email protected] >Subject: Re: [Forum] Re: swixml .. What is still missing? > > >Frank, >While there is nothing wrong with your approach, there was a particular >reason why we did it differently. >I guess the missing documentation is to blame. However, let me try to >explain how we pictures the link between the GUI Widgets and the actual >evenbthandlers. > >All the SwiXml Tags representing Swing objects that inherit from >Abstract Button (like JButton, JMenuItem, JCheckBox, etc.) accept the >ActionCommand and the Action attribute. > >When the Action attribute is used, the following will happen with the >example for instance: > > >XML Code: >.. ><button Text="Click" Action="Handle_Click"/> ><button id="btn2" Text="2nd Button"/> > >.. >Java Code: >.. >public class HelloWorld extends WindowAdapter { > private SwingEngine swix = new SwingEngine( this ); // *1* > public JButton btn2; // *2* > > public Action Handle_Click= new AbstractAction() { > public void actionPerformed(ActionEvent e) { > System.out.println( "Click was pressed" ); > btn2.setEnable(false); //*3* > } > } > > private HelloWorld() { > try { > swix.render( "xml/HelloWorld.xml" ).setVisible( true ); > } catch (Exception e) { > e.printStackTrace(); > } > } > > public static void main(String[] args) { > new HelloWorld(); > } >} > >The button Tag triggers the instatiation of a JButton object. Then after >the parsing and instantiation work of the whole XML document is done, >EventHandlers, (in our case the _public_ Action Handle_Click is linked >with the Button. > >The Button does not need an ID if you don't need to refer to it later. >The example has another button (//*2*) that we want to disable if the >1st button was clicked. Therefore this button needs an ID. > >If there is a _public_ Button in the class of the object that was passed >into the SwingEngine at construction time (//*1*) and the button's name >matches the tag's then this button gets initialized automatically during >parsing as well. >If you need to make your members private you will have to use the >SwingEngine's find method to init those yourself. > >Now here comes the benefit of during it this way. Swing programmers are >used to use inner classes. The Action class used in this example is an >inner class, allowing easy access to the outer class members and >methods. See how easy it is to disable the 2nd button in the event handler. > > >When you want to use the alternative (built in) way hook up your event >handlers, you need to use the ActionCommand attribute. This requires a >little more java code to write but in certain situations this might be >preferable over the Action attr. way. >Check the sample code at http://www.swixml.org/samples/index.html for >details. > >Wolf > > > > > > > > >Frank Mei�ner wrote: > > > >>Hello again, >> >>Ok, because I needed the features I mentioned, I added them for >>myself. Now I'm able to write swigxml-code like this: >> >>... >><menuitem id="mi_exit" InitClass="test.actions.ExitAction" >>FactoryMethod="getInstance"/> >>... >><button enabled="true" InitClass="test.actions.ExitAction" >>FactoryMethod="getInstance"/> >>... >> >>All these objects use the same instance of ExitAction. If no >>ExitAction is used at all, no object of this type is created (of >>course...). >> >>So, this code moves swigxml a bit more to the business-logic part of >>the code. It allows you to switch some (maybe expensive) parts of your >>gui on and of. Especially if the components do create without further >>arguments you do not have to take care on them. Just implement them, >>test if they work correctly and leave it to someone else to decide if >>he/she wants to see them. >> >>On the original swigxml you have to take care on the creation of the >>actions for yourself. You have to (correct me if I'm wrong) assign an >>id to every button or menu item in the xml. Then you have to write >>code which iterates over all of the id's you defined. If one is used >>(e.g. the component by getIdMap().get(id) returned a value != null), >>you have to create the appropriate Action and assign it to the >>{button, menu item, ...}. Of course, one might use a clever String for >>the id (like "1.test.actions.ExitAction<getInstance>") but this is not >>as clever as to provide the factory method :) >> >>Just tell me what you think of it... >> >>Frank >> >> >>_______________________________________________ >>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 > > > > > _______________________________________________ Forum mailing list [email protected] http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com
