Sure: Things I don't like:
1. The plugin thing - the advantage of starting faster, to me, isn't worth the disadvantage of making gui elements harder to write, or more tedious to write. Maybe because I have too much of a developer perspective, but an extra few seconds at start time don't bother me. And not the whole classpath is searched anyway - only the jars under /ext. If it's really important, there are other ways we could speed up JMeter's start up time (JMeter could "remember" the information and only re-search if timestamps on the jar files have changed or new jars added since last start). 2. Requiring that GUI elements have to transfer changes immediately to the test elements. I didn't see that as necessary. I like making the nodes hold test elements and reusing GUI objects, but I was thinking the transfer from GUI to test element could occur at a "trigger" event, and the duty could be handled by an action, thus relieving GUI component writers of this duty. For instance, an event could be generated when needed that results in a call to "createTestElement" of the GUI component in question, thereby extracting the data for the test element. The even could occur when focus is lost/gained, when a test run is started. Making GUI writers responsible for keeping test element and gui object in sync is a real pain. 3. I don't get the whole properties in test element objects, or replacing the map with instance variables. How does cloning work now? In what way was handling user-defined variables difficult that is now easier? I could see how property objects could make some things easier and more modular, but not as instance variables. I would think you'd still want some sort of collection to organize and track all the properties. But what's this have to do with changing tree nodes from GUI objects to test element objects anyway? 4. Changing the jmx file format - seems completely unnecessary. I can't hardly imagine what you did that means you can't write the jmx in a compatible format? Things I like: 1. Using test element objects in the tree; only one instance of each gui class - should make a marked difference in performance. 2. Property objects have potential, but should hurt file format compatibility. 3. Splash screen, toolbar, and tabbed main panel all seem good. -Mike On 27 Jan 2003 at 20:46, Oliver Rossmueller wrote: > Mike Stover wrote: > > I only object to some pieces of it, > > Mike, > > you already mentioned in the Wiki that you disagree with several things > in my list. Would you mind to let me know what these things are and why > you disagree? Thankx > > Oliver > > > but it's all been lumped together in the different > > branch. I don't think branching for individual developers works well - I probably > > should have said something earlier. > > > > -Mike > > > > On 27 Jan 2003 at 9:31, Oliver Rossmueller wrote: > > > > > >>I added some information about what I'm doing on the branch I started some > >>time ago to the Wiki > >>(http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterArchitecturalOverview). > >>Mike raised his objection there that I might be to far on the wrong road > >>already. Therefore I would ask you to check the Wiki page mentioned > >>above and tell me what you think. > >> > >>Oliver > >> > >> > >>-- > >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >> > > > > > > > > -- > > Michael Stover > > [EMAIL PROTECTED] > > Yahoo IM: mstover_ya > > ICQ: 152975688 > > AIM: mstover777 > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
