On 10 Jul 2002 at 19:13, Berin Loritsch wrote: > > [snip] > > I agree with you to a point. Keeping in mind who your user > is, we can provide the GUI that builds the script under the > hood. Either that, or the tests are converted on the fly to > the scripting language in question.
I could create some new components that allowed the JMeter user to choose different implementations of JMeterThread. By doing so, new implementations of JMeterThread could be written, including one that provided such bindings to Jython and the like. Thus, a user could write arbitrary Jython code in the GUI, and then submit it to be run within a special implementation of JMeterThread which provided access to all the other JMeter resources, like listeners, controllers, timers, etc. This way, there's no need to write a code generation engine (whew!), and the underlying language of JMeter doesn't have to change. And better yet, I can pawn off the work involved to someone who wants this feature - and who is more familiar with Jython. I may have used a poor choice of words by referring to what I'm doing as a "scripting language". In reality, I'm providing static variables and built-in functions for use within test elements. These functions only provide substitute values within the configuration data - there is no control of program flow, and no actions can be taken. I apologize for being misleading, but I hadn't really thought it entirely through. I'm believe that what I'm trying to provide is very different from what you and Llia are talking about. -Mike -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
