RE: DO NOT REPLY [Bug 8801] - Prompt to save Test Plan on exit

["Stover, Michael" <Mi...@usa.xerox.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>