On Friday, July 29, 2016, Vladimir Sitnikov <[email protected]> wrote:
> > 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. why not map each element to a keyword of dsl. Foreach would be used for ForEach Controller . No try/catch concept. > 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 > -- Cordialement. Philippe Mouawad.
