Yes, I'm proposing to have the current viewers so that they no longer do logging (I can't understand the reason to mix these two different functionalities).
Then, have one Logger component which does the logging, and put all these configuration parameters in the GUI for those Logger components.
In this way, you could define loggers with different configurations for different branches of the tree.
There's one difficulty to this approach I'm proposing: to get the functionality you have now, you'd need to find a way to load the results back so that you can view them in your Viewers. But I'm guessing your proposal breaks this functionality too...
I'd propose to work on creating that Logger component first. Then we could think on how to solve the save/load test results problem (if we think we need to solve it -- I've never used that capability anyway). I guess the best option is to have each viewer save its digested (not raw) data in some XML format.
Makes sense now?
Salut,
Jordi.
[EMAIL PROTECTED] wrote:
How about separating the Viewer functionality form the Logger functionality (in different components, I mean) and having all these config parameters in the GUI?Salut, Jordi.I don't understand what you mean. I don't intend to modify view functionality, only those things that get saved. Currently, you can save everything in the SampleResult to an XML (JTL) file by using "functional test" mode, or you can save a fixed subset of the SampleResult's fields. I am merely trying to allow a user-specifiable subset of the SampleResult's fields to be saved. I intend to provide a UI to modify these properties eventually. However, we still need these to be specifiable outside the GUI, because the user won't always be in GUI mode. That's why I want to use a properties file. Did I miss your point entirely? -- 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]>
