Am 20.11.21 um 14:28 schrieb Vladimir Sitnikov: >> The annotations could be used for scanning for TestPlan elements on > startup, too. > > I remember we have discussed it, however, it sounds like a different > feature. > Of course, some level of code generation might help, however, I have no use > cases for it now.
Well, maybe we see use cases, when we see the first implementation of
the generating function (`http`, `aggregateReport` in your example).
I thought it might help developers of plugins to get started on
integration into the dsl.
>
>> Maybe start with a global org.apache.jmeter.experimental.dsl
> package/module name
>
> I think experimental works better with annotations like @OptIn(Experimental)
> If you put experimental into a package name, you can't remove it without
> breaking the usages.
My idea was to use it to explicitly hinder us from re-using the code :)
but we could try with an annotation and see how it works out.
>
> A single .dsl. package would help indeed, so users could import
> jmeter.dsl.* and use the functions rather than import every package or
> class individually.
> On the other hand, the users won't be able to unimport features they do not
> need
If you have a clear idea, of a structure, we could use that, but if not,
it is (in my opinion) valid to start with such a mess.
>
>> Kotlin has a very similar string template format to JMeter, is there a
> good way to distinguish those, or guard the JMeter ones?
>
> That is indeed a problem.
> I've (no) idea what would work the best to resolve it.
> Changing syntax to %{..} might work.
I think, we already use %{..} inside JMeter, too. (Template language for
the https script recorder naming logic)
> Changing syntax to explicit expr("__javaScript(...)") might work as well.
Can the kotlin templating mechanism be switched off in that case?
> Making variables explicit might work as well. For instance, we can declare
> "variable holder", and pass it to regex extractor, and later use it for
> retrieving the result.
> That would reduce the number of cases where $ is needed in the test plan as
> every use of $ is basically a place for hidden error like "use of undefined
> variable", and so on
I don't understand it, can you give an example? Something like a
dsl-function (`http(jmVar("host))` and `http("""${jmFunc("upper",
jmVar("hostname"))}""")` (not sure, if it is valid kotlin))
>
>> It seems, that `aggregateReport` has its parameters given by a closure
> (is that the right name?) , while `http` per positional parameter. Is
> this a Kotlin feature, that we can mix those, or is it only a first
> example and showing different ways of settings parameters on the elements?
>
> Kotlin has positioned parameters, it has named parameters, parameters can
> have default values (even computed values based on other parameters), and
> the final lambda can be outside of the parenthesis.
I wanted to ask about the intended usage. How should those possibilities
map to the elements?
>
>> And a completely other construction site: Currently JMeter uses a global
> context, which could trip off users of the dsl, when they want to
> execute plans in parallel. Would this be worse, than now?
>
> Do you mean static context when running the plan?
Currently we get the JMeterContext by a static function and everyone
would get the same context. That is no problem when used inside the GUI,
but might be a problem, when used by developers in other circumstances
(and not aware of this)
Felix
>
> Vladimir
>
OpenPGP_signature
Description: OpenPGP digital signature
