Hey, I'm glad you like it. I like it too :-) Regarding monitoring the state of a test plan - I would really like that not to be in the JMeterGUIComponent interface. I would prefer to use something akin to the Visitor pattern for such things - whereby the test plan is made transparent to some code that processes the plan and returns some result from the processing.
For instance, say I want to verify that the test plan hasn't been changed since the last save. Send the test plan to some code that looks through and returns information on which elements have been modified. How would this work? One simple way would be to have a static or singleton "dirtiness" checker that preserved the most recently saved state of all elements in a test tree. Then, when the current test tree is passed to it, it can return information about which elements have been modified. By doing it in this manner, we can add lots of utilities without requiring that developers implement a huge number of tedious methods. In src_1, I have eliminated the need for developers to implement code to save or to clone test elements. I think this is good. It will not be possible entirely (obviously, some information has to come from the element itself), but for anything for which it is possible, it should be done externally to the component, I think. Regarding your patch - ya, that would be a straightforward way to do it. But tedious. How about if we create a new action (as in org.apache.jmeter.gui.action.CheckDirtiness, or whatever) that takes the test tree, converts it into the test elements (just like the Save action does), and then tests those elements against a statically held tree from the last time a save or load action happened? There's some details to work out, but I bet it can be done. And then, your done for any elements subsequently created. BTW, I'm finding that, currently, the src_1 code is running better than the src code, and I've switched over to it for my actual work with JMeter (as a user). -Mike ================================ I like the new 'NumberFieldErrorListener' component.This is obviously a better way to handle things (most of the components inmy patch implement similiar code). As well, it should offer a substantialperformance improvement, as unnecessarily listening to keystrokes is a realkiller.Of course, if it is still desirable to monitor the state of the test plan,then more is required than just the numeric fields. I guess the interface'JMeterGUIComponent' would be the place to define this contract.Any comments (favourable or otherwise) on these thoughts or my patch ? -- 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]>
