Hi Felix, I added patch so you can have a look to it: https://bz.apache.org/bugzilla/show_bug.cgi?id=63101
I think it is highly "improvable". For now I put in Menu Item (alpha), this way it can easily be tested. Regards On Tue, Jan 22, 2019 at 9:03 PM Felix Schumacher < felix.schumac...@internetallee.de> wrote: > > Am 22.01.19 um 20:36 schrieb Philippe Mouawad: > > Hello, > > Do you think this feature as of now (based on XSL) is worth being > committed > > to core as alpha? > > That depends on how alpha you think it is :) > > Maybe include it, but disable it by default with a clear warning, that > it is there for testing the usability? > > > > > In terms of implementation, it relies on Saxon BasicTransformer as it > > supports xslt 2.0 functions. > > Are the used functions comfort functions or necessary ones? (Just out of > curiosity). > > Felix > > > > > Regards > > > > On Monday, January 21, 2019, Felix Schumacher < > > felix.schumac...@internetallee.de> wrote: > > > >> Am 21.01.19 um 20:56 schrieb Philippe Mouawad: > >> > >>> On Monday, January 21, 2019, Felix Schumacher < > >>> felix.schumac...@internetallee.de> wrote: > >>> > >>> Am 21.01.19 um 11:40 schrieb Philippe Mouawad: > >>>> Hello, > >>>>> This will better explain feature: > >>>>> Menu: > >>>>> > >>>>> - http://ubikloadpack.com/demo/schematic/MenuSchematicView.png > >>>>> > >>>>> Plan: > >>>>> > >>>>> - http://ubikloadpack.com/demo/schematic/testRequest.jmx > >>>>> > >>>>> Schematic View: > >>>>> > >>>>> - http://ubikloadpack.com/demo/schematic/testRequest.html > >>>>> > >>>>> Where do the names "handle Cookies", "add Headers", "Virtual Users > >>>> executing", ... come from? How would extensions (plugins) fit into > this? > >>>> > >>> It currently comes from the xsl file. > >>> There would be a default display using element name. For now plugins > would > >>> have a very basic display. > >>> > >>> There would be a need to provide registration for implementations, I > see > >>> how to do it for java implementation, but for XSLT, for now I don't. > >>> > >> Yes, I think the java implementation would have advantages over the > >> xsl-only version, especially with respect to extensibility. > >> > >> > >>> Working on this feature (within some consulting work, I was asked to > >>> document a plan to provide a textual description and ease > understanding of > >>> errors (make other users find to what request an assertion was > related)), > >>> I > >>> find that it makes the reading/understanding of a test plan more easy. > >>> I ran it on previous plans, and I see at least this major benefit. > >>> Another one (if we move forward) , would be to provide a more source > >>> version friendly representation of a JMX test plan. > >>> > >> Would this lead to something like Vladimir described? A textual > >> representation of the test plan, possibly with explanations for the > >> elements, that is diff and reader friendly. > >> > >> On the other hand, this reminds me of something. I sometimes dream of > >> having markers in the test plan tree, that could be used to show > >> > >> * errors that happened during execution of a test plan (linked to/by > >> samples in result tree) > >> > >> * common misconfigurations like double timers (scoping issues mostly) > or > >> beanshell/javascript scripts :) > >> > >> * samplers with long response times > >> > >> * ... > >> > >> Felix > >> > >> > >>> > >>> Felix > >>>> > >>>> For now, it's html (I'm using XSLT), but a textual format like YAML > would > >>>>> be better for source comparison. > >>>>> > >>>>> Regards > >>>>> > >>>>> On Mon, Jan 21, 2019 at 11:04 AM Vladimir Sitnikov < > >>>>> sitnikov.vladi...@gmail.com> wrote: > >>>>> > >>>>> Paulo Maia Borges> Why not export to standard HTML? > >>>>> > >>>>>> For instance, if jmx is stored in a Git repository (GitLab? > GitHub?), > >>>>>> then > >>>>>> markdown would be much easier to review in diffs than HTML. > >>>>>> E.g. https://twitter.com/jamiebuilds/status/1085377471057412096 > >>>>>> > >>>>>> In other words, it could make sense to render markdown > representation > >>>>>> on > >>>>>> save. > >>>>>> However, it is not clear how tables should be rendered (e.g. HTTP > >>>>>> parameters). > >>>>>> > >>>>>> Vladimir > >>>>>> > >>>>>> > >>>>>> > >>>>> <https://www.openstreetmap.org/#map=18/50.69454/3.16455> > >>>>> > >>>>> > >>>>> > -- Cordialement. Philippe Mouawad.
