> [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 [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777
