I'm currently working on reversing the relationship between JMeter test
components and GUI components.  Right now, it's sort of a two-way street,
and the test components are required to know certain information about the
gui (ie, class label, gui class, name and the like).  So, I'm in the process
of reversing this so that test components are blissfully unaware of a gui
(they don't even exist until the test is started), and instead, gui code has
to know all about test components.  

I have two interfaces:
JMeterGUIComponent
TestElement

I'm reworking all JMeter elements to fit into this model.  I think the
advantages will be obvious:
1.  No longer 1-1 correspondence of gui classes to test classes.  Now, there
can be three different gui's that can create HTTP Requests - each for
different needs.  A gui that simply asked for the URL on one line would be
quite useful, I think.
2. I'm pretty sure I can get rid of all specialized save handlers.  This
would save everyone the effort of figuring out how to make their
implementations save correctly to .jmx files.
3. I think I'll be able to implement correct cloning procedures for
everyone, provided they follow some simple rules.
4. GUI code is already simplifying itself - after reworking a class, I find
most event handling code unused.  
5. Many current config classes are becoming unnecessary - such as UrlConfig,
MultipartUrlConfig.  
6. No more "Logical" and "Generative" controllers.  Now, there are simply
Controllers (all are Logicial Controllers), and Samplers.  The generative
controllers are going away, and instead, the Samplers are taking their
place.  Previously, Samplers were only created in the JMeter Engine.  Now,
they are Test Elements that get configured by gui components, and then
bubble up through the test the way Entry objects did before.  Entry objects
will probably go away too.

One disadvantage is that the format of .jmx files will be completely
different than before. I'm not even sure if it will be feasible to bring old
jmx files "up-to-date".

After doing this work, I think it will be considerably easier to apply the
Avalon framework and ideas to JMeter.  

-Mike

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to