> ruby-jmeter implements just a small subset of the options that can be > configured in JMeter UI. > It will hardly be that much readable when order options are > implemented/used (e.g. lots of parameters passed to the application).
Philippe>I think issue would be the same for all dsls no? I think so. I advocate for UI here (or "graphical DSL") I could easily understand a case when parts of the script are written in JMeter UI, then reused in some glue-like test code. However, I can hardly see "textual-dsl-first" kind of future. ok , clear for me. > It could be a first step for a DSL and feasible with not too much work. > I would suggest we build it so that implementing the read is possible as > second step. > "Reading" is a rabbit hole. For instance, if a user writes some random code (with for loops, try-catches, etc), how JMeter should read that into a UI and write that back? That scares me. That is why I have no idea how "turing complete programming language" can effectively be used for read/write kind of DSL. I'm not fond of showing abstract synax tree right in the JMeter UI. I'm not sure there are lots of language designers around JMeter committers/users. > > >Or does it in your mind work only from xml => comment > > > > As I stated in the comment itself, the comment is not supposed > > to be modified. Neither it is supposed to be parsed by JMeter. > > It is there for presentation purposes only, so dump views like "github > > diff" > > can make a basic sense of a file and show a decent diff. > > Philippe: In addition to xml comment in header, I would prefer it to be > also in a > separate file generated on save or through command line option or gui > menu-item. > That makes sense. Vladimir
