You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Oliver Rossmueller <or...@apache.org> on 2003/01/27 18:31:22 UTC
refactorings_branch
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: refactorings_branch
Posted by Mike Stover <ms...@apache.org>.
Rather than make a new branch, I'd rather see 1.8.1 go out, and then just do this in the main
branch. It really shouldn't take too long. I bet I could do it in less than a day.
-Mike
On 29 Jan 2003 at 1:14, Oliver Rossmueller wrote:
> Okay, so here is the proposal to bring all that stuff on track again:
>
> - let's take the refactorings_branch and all that is there as a sandbox
> where I built some castles and other buildings to see what is possible
> with that kind of sand; some buildings are ok, others are not, and some
> ask for improvement
> - let's create a new branch to implement the GUI/test element switch for
> the tree, and only that. I think it is better to do this on another
> branch because it still requires lots of changes and to collaborate you
> need the possibility to commit changes which might break the build for
> some time without effect to the main branch.
> - I'll start a new thread on the list to discuss how to implement the switch
>
> Oliver
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: refactorings_branch
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Okay, so here is the proposal to bring all that stuff on track again:
- let's take the refactorings_branch and all that is there as a sandbox
where I built some castles and other buildings to see what is possible
with that kind of sand; some buildings are ok, others are not, and some
ask for improvement
- let's create a new branch to implement the GUI/test element switch for
the tree, and only that. I think it is better to do this on another
branch because it still requires lots of changes and to collaborate you
need the possibility to commit changes which might break the build for
some time without effect to the main branch.
- I'll start a new thread on the list to discuss how to implement the switch
Oliver
I'm going mad [Was: Re: refactorings_branch]
Posted by Jordi Salvat i Alabart <js...@atg.com>.
Hi.
This discussion is driving me crazy. So many really difficult really
different subjects in the same message!
In short, I agree with Mike's in asking Oliver to be a little but more
step-by-step in introducing architectural changes (at least for those
which are not requisites for others).
Actual technical discussion in separate message(s) as soon I have time
for it.
Salut,
Jordi.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: refactorings_branch
Posted by Mike Stover <ms...@apache.org>.
> [snip]
> Yes, now the GUI components create their test element and know all about
> them. On the branch it is the other way around: the tree panel holds the
> test element tree and when a test element is select in the tree the
> corresponding GUI has to be selected and displayed. The test elements
> have no information about the gui (models) so I have to hold the test
> element to GUI class mapping somewhere and the plugin is one way to
> provide this mapping information. It is not the only way, and in fact
> the plugin stuff can be removed with very little effort should it be
> necessary.
I like the current uni-direction: from gui to test element. It can still work that way. All you
have to do is use the current system, except at the last moment, rather than plug the GUI
object into the test tree, call "createTestElement()" on it and plug that into the test tree.
>From that point on, the GUI class for that test element is held as a property.
> [snip]
> I can't see how this should work, how should properties a test element
> does not know of affect the way the test element is doing its work? But
> if you have a scenario where this makes sense it can still be done one
> way or another.
Many test elements are simple holders of data and don't do any work.
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: refactorings_branch
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Mike Stover wrote:
> On 28 Jan 2003 at 3:38, Oliver Rossmueller wrote:
>
>
>>
>>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.
>
>
> I don't see why mapping was necessary. The way it is now, the GUI components create their
> test element and know all about them. Good point about the message resources - perhaps
> that could be addressed by breaking the message bundles out of the jars so they can be
> modified more easily?
Yes, now the GUI components create their test element and know all about
them. On the branch it is the other way around: the tree panel holds the
test element tree and when a test element is select in the tree the
corresponding GUI has to be selected and displayed. The test elements
have no information about the gui (models) so I have to hold the test
element to GUI class mapping somewhere and the plugin is one way to
provide this mapping information. It is not the only way, and in fact
the plugin stuff can be removed with very little effort should it be
necessary.
>>>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.
>
>
> One thing nice about having many developers is often someone can find a solution you didn't
> see. You're trying to solve it all by yourself.
>
>
>>>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.
>
>
> This sounds pretty good then. I agree the property objects are probably useful. I'm still not
> sure I like them as fixed instance variables. Why not allow new properties to be added ad hoc
> to a test element?
I can't see how this should work, how should properties a test element
does not know of affect the way the test element is doing its work? But
if you have a scenario where this makes sense it can still be done one
way or another.
>>>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.
>
>
> So these problems are a result of a) the mapping from plugins and b) making properties
> instance variables, thus requiring that every test element be it's own class. Neither of which
> seems necessary to me, so we could probably fix those things and remain compatible with
> current .jmx files.
Might be possible. I was thinking about this matter and am quite sure
now that it would be possible to transform my new file format to the old
jmx format on the XML level using XSLT. And if it is possible using XSLT
than it can also be done in Java when the XML is generated. Needs
further investigation but I think this issue can be solved.
>>>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
[snip]
Oliver
Re: refactorings_branch
Posted by Mike Stover <ms...@apache.org>.
On 28 Jan 2003 at 3:38, Oliver Rossmueller wrote:
>
>
> 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.
I don't see why mapping was necessary. The way it is now, the GUI components create their
test element and know all about them. Good point about the message resources - perhaps
that could be addressed by breaking the message bundles out of the jars so they can be
modified more easily?
>
> > 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.
One thing nice about having many developers is often someone can find a solution you didn't
see. You're trying to solve it all by yourself.
>
> > 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.
This sounds pretty good then. I agree the property objects are probably useful. I'm still not
sure I like them as fixed instance variables. Why not allow new properties to be added ad hoc
to a test element?
>
> >
> > 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.
So these problems are a result of a) the mapping from plugins and b) making properties
instance variables, thus requiring that every test element be it's own class. Neither of which
seems necessary to me, so we could probably fix those things and remain compatible with
current .jmx files.
>
> > 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: <ma...@jakarta.apache.org>
> > > >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Michael Stover
> > > > mstover1@apache.org
> > > > Yahoo IM: mstover_ya
> > > > ICQ: 152975688
> > > > AIM: mstover777
> > > >
> > > > --
> > > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > --
> > 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>
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: refactorings_branch
Posted by Oliver Rossmueller <or...@apache.org>.
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: <ma...@jakarta.apache.org>
> > >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >>
> > >
> > >
> > >
> > > --
> > > Michael Stover
> > > mstover1@apache.org
> > > Yahoo IM: mstover_ya
> > > ICQ: 152975688
> > > AIM: mstover777
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> --
> 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>
Re: refactorings_branch
Posted by Mike Stover <ms...@apache.org>.
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: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: refactorings_branch
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
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: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: refactorings_branch
Posted by Mike Stover <ms...@apache.org>.
I only object to some pieces of it, 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>