Mike Stover wrote:
I think you are talking about the request defaults elements which are all instances of ConfigTestElement but use different GUIs. I don't know why it is done this way - I thought this was some kind of copy&paste bug - because there are special classes in the code base for all the defaults but they are not used. I don't see any use of having two different GUIs for HTTPSampler to stay with your example. And how will JMeter decide which one to use?On 4 Feb 2003 at 0:15, Oliver Rossmueller wrote:No, one factory to create all of them. In fact it is just Class.forName(elementClassName).newInstance(). Filling the properties with default values should not be done by the GUI but in the element's constructor. So the only property the test element constructor can not set is the gui class name. But the test element should not know about GUIs anyway so I don't see the need to hold the name of the corresponding GUI class in the test element's properties. There are other ways to assign GUIs to test elements (e.g. ask the GUI which kind of test elements it can handle and then select the right one) and to keep separation of concerns. The test elements are the model and should not know about the very existence of a GUI.
Couple things. One, I'd like to avoid a 1:1 mapping of testelements to gui classes. Right now, 5 guis can serve the same test element, and that's a nice feature. It means I can make a different gui for the HTTP Sampler if I want, and the only thing I have to write is the GUI - I don't have to make a new copy of the HTTPSampler class.
Two, related to that is that the GUI's are the authorities on how to initiate test element's and their data - because they fully control the data that goes into them anyway.Well, the GUI fill the test elements with data, but the test elements have to control if the values set by the GUI are valid and correct. They don't do this at the moment but IMHO they have to because they rely on correct data when executing the tests. And there is another way to fill test elements with data by loading a jmx file, and this should not go through the GUI.
Three, the gui class is saved in the test element so that when test plans are reloaded, JMeter knows which gui goes with it. Otherwise, you need that 1:1 mapping to figure it out, plus that would be slower, as JMeter would have to search through all the gui classes to find the right one.It is not hard to create a map holding the required information e.g. when searching for the classes at startup.
As far as I'm concerned, the separation of concerns is not violated by the testelement holding gui related data. As long as the code is completely ignorant, I'm not worried about what data the gui's stuff in them.
Ok.
I noticed on some other wiki site developers were maintaining a discussion by writing pro-con lists. I'd like to see your pro-con thoughts on making this factory. What would be the advantages? What would be the disadvantages?The factory is not the key point, the key point is that I would like to have a clean separation of GUI and test elements. Then for example I could create a command line tool to record test plans and use the same functionality to create test elements that is used by the GUI. And I could run this recorder on a linux box without X-Windows because the GUI would not be used in that case. This is not possible at the moment.
Anyway, I will stop this discussion now. I see no way to convince you that a clean separation of GUI and model is an advantage and you will not convice me that it is good as it is now. As nobody else seems interested in this topic I'll stop wasting our time.
Oliver
-MikeOliverOliver-- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
