On Mon, 27 Jan 2003, Mike Stover wrote:
> 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). In fact I started with the plugin thing because I needed a way to map gui elements to test elements. As the tree holds test elements now and the test elements know nothing about the gui this kind of mapping is necessary in one way or another. The fact that detecting element classes is faster is just a nice side-effect. The real potential of plugins for me is the possibility to extend JMeter without having to change the JMeter sources (e.g. because you need a new message resource for your gui). Using a plugin you tell JMeter about your additional test elements, corresponding gui elements and icons, and additional message resources. > 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. I tried it using focus and other events but it is not that easy and I was not able to find a working solution this way. In fact writing guis is not that much more complicated than before. I most cases you just have to register a DocumentListener for the entry fields and there are helper classes available to support this. If you now a little bit about Swing it should be a matter of minutes to write the necessary stuff. > 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? Cloning works like before, instead of cloning the map I have to clone the properties. This is not direct related to change tree nodes from GUIs to test elements, but the property objects allow for simple dirty checking and transparent user variable substitution. > > 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? Here is why: the current jmx format holds information like the name of the gui class which are not held by the test elements anymore. That's the easy part. The more difficult part is that because of what I think is a bug all - or almost all configuration elements like FTP Defaults or HTTP Defaults - are stored with class org.apache.jmeter.config.ConfigTestElement in the jmx files but are separate test element classes now. All this would require some kind of mapping from the new to the old structure to write compatible jmx files. So perhaps I should better say that I'm not confident this can work and that from my point of view the effort required to do/try it is not worth it. I'm still not 100% sure that it will be possible to create a mapping from the jmx files to the new internal structure. It is always a problem to change file formats, but it will be possible to load jmx files - at least I hope so - so you will not loose your any existing test plans. And with the new JMeter you have a new file format, a tradeoff that hopefully will be worth the deal because of all the other great new features which will be available. > 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 Probably it was the wrong decision to do all this changes at once and not cleanly separate them, but anyway if I'm wasting my time from your point of view I will continue my work on the branch. At some point we will have to decide if what I did is okay for all of us. If this is not the case that was my own risk. At least I have my private JMeter version then ;-) And of corse I'm open for discussion, ideas, contribution, ... Oliver > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
