Stover, Michael wrote: > I want to change the way JMeter's pop-up menu's are generated. Currently, > implementors write code that creates JMenu items for every component they > build. This has two unfortunate side-effects: > 1. non-gui code is dependent on swing classes > 2. For every type of add action, we need separate menus (ie, "add" and > "insert" can't use the same exact JMenu objects, because the actions must be > different). Rather than add a "getInsertList()" method, I'd prefer another > alternative. > > I see two choices. One, have the classes return a structure that specifies > class names rather than fully created JMenu items. This solves both > problems, but I don't like it. > > The other choice, and the one I prefer, is to remove this "configuration" > stuff from the java files, and put them into an XML configuration file(s). > By doing this, we can specify a lot of the behavior of the classes in XML, > and, to some extent, it will be possible for a user to modify these files to > customize their experience (ie, they can cut out FTP & JDBC classes from > appearing if their just doing web testing). > > Here is my five-minute effort at designing such an XML description of the > classes (it's obviously incomplete):
It seems to me that you want to actually use *Components*. For that, I would strongly recommend you check out Avalon Framework. They have a "Developing with Avalon" document that is pretty good. One of the nice things about the Avalon framework is that you can use their XML to configuration object logic. Also, by separating the GUI completely away from the component, we can make the distributed JMeter approach easier to work with. In essence, the GUI is merely a face on the JMeter engine. We would be able to generate the configuration of the JMeter engine with the GUI, send it to the JMeter engine, and have it do the actual work. That way we can play with the GUI code to our hearts content, and have a neatly organized component architecture. Granted, the JMeter code would have to be revamped, but we can take advantage of Avalon's components (like the JDBC connection pooling code), and the Phoenix micro-kernel if we get serious about distributed load testing. Another thing worth examining is the new Intrumentation code that is in Avalon Excalibur. In essence, we can make the GUI a Sample Listener. Work is already under way to make the GUI run in a separate JVM. THere are also some excellent graphs in the default GUI. The graphs provide a window into the sample data with crosshairs to zero in on exact values. If you click on the absolute sample lines, you see an average value. After you look at Avalon, let me know what you think. <snip>XML example</snip> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
