> I don't think the target is to remove UI.
I personnally think it's a big power of Jmeter and highly increased
productivity of test development.
DSL only is less productive.

+1

Please do not remove/replace GUI, it allows for a very gentle learning
curve.

RaGe

On Fri, Jul 29, 2016, 8:15 AM Philippe Mouawad <[email protected]>
wrote:

> On Friday, July 29, 2016, Antonio Gomes Rodrigues <[email protected]>
> wrote:
>
> > My opinion
> >
> > The "github diff" is a false problem, users must use comment when they
> > commit
>
> diff in git is very useful.
> As a developer I highly use it, so I think it's a good point from Vladimir
>
> >
> > About users who don't like the GUI, a DSL is mandatory but not
> necessarily
> > the target of JMeter
>
> yes.
>
>
> >
> > About jsr223 XXX, if JMeter become a full DSL like
> > LoadRunner/Gatling/Grinder/...., we can remove all of them and use the
> > original language (Scala in Gatling, C in Loadrunner...) to add missing
> > functionality
>
> I don't think the target is to remove UI.
> I personnally think it's a big power of Jmeter and highly increased
> productivity of test development.
> DSL only is less productive.
>
>
> >
> > Thanks to the ruby-jmeter  feedback
> >
> > @Philippe, do you want to replace GUI by a DSL or do you want to add a
> DSL
> > to JMeter?
>
> No , Keep improve UI but introduce dsl or compent first then dsl.
>
> >
> > Antonio
> >
> > 2016-07-29 13:06 GMT+02:00 Vladimir Sitnikov <
> [email protected]
> > <javascript:;>>:
> >
> > > >I think it ends up being a dsl anyway no ?
> > >
> > > It ends up being write only DSL.
> > > We can put whatever makes sense for humans, and do not care
> > > of the grammar/parsing stuff.
> > >
> > > The set of "printed" values/fields could even depend on the project.
> > > For instance, some kind of regexp for "exluded/included" header names
> so
> > > the output is both concise and useful at the same time.
> > >
> > > >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.
> > >
> > > >If so it does not answer the requirement of some users to be able to
> > > change
> > > >the plan without xml format.
> > >
> > > I do understand that "pretty-printer in the comment" does not cover all
> > > the use cases.
> > > However, I think pretty printer will be both useful and easy to
> implement
> > > at the same time.
> > >
> > > my concern about language would be:
> > > > - its popularity ,
> > > > - its easyness for users
> > > > - it's easyness to build dsls
> > > > - its future
> > > >
> > >
> > > I would add IDE support to the list as well
> > >
> > >
> > >
> > > > Groovy is ASF now also and it's already embedded.
> > > >
> > >
> > > This does not immediately solve "easyness for users" problem of Groovy.
> > > Have you seen Groovy puzzlers?
> > > https://www.infoq.com/presentations/groovy-puzzlers ,
> > >
> > > Take a jsr223 preprocessor that has 4 to 10 lines of groovy code in it,
> > how
> > > > do you represent it ?
> > > > That's what I mean.
> > > > It can make dsl less readable.
> > > >
> > >
> > > Do you mean "abandon jsr223 in favor of a full blown programming
> > language"?
> > > Initially I thought you wonder how to add "a jsr223 preprocessor" when
> > > using some kind of DSL.
> > >
> > > When using a programming language, some kind of IDE is required to
> craft
> > > the script.
> > >
> > > I find "http sampler" rather hard to express in DSL so it is readable.
> > > >
> > > >
> > > > look at ruby-jmeter it does a nice job at doing that
> > > >
> > >
> > > 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).
> > >
> > > Vladimir
> > >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Reply via email to