You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by OUFDOU Anas <ou...@gmail.com> on 2021/11/25 04:35:28 UTC
[Jmeter] Enhancement , Disable component using attributes
Hello community,
I have create enhacement
https://bz.apache.org/bugzilla/show_bug.cgi?id=65702, related to adding
attribute on all components to disable/enable at runtime.
There are many cases when we need to disabled/enable components based on
variables or functions.
1- Disable listener
2- Disable post processor (when extracting value from home page, there is
no need to consume CPU with each iteration to get the same value )
3- Disable debug sampler.
4- disable the thread group used for testing scripts.
....
I think this change will be easy, i will work on it soon, if there is any
suggestion please let me know.
--
Best Regards
Anas OUFDOU
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ou...@gmail.com>.
Hello,
Enable/disable attribute concerne two different use case :
1- Generic problem related to some boolean already present in many
components that may will interessant to have a generic solution to also
have the possibility to use expression.
2- Evaluate enable at runtime, actually enable is used before test to
filter components, and I think each case (listener, controller, sampler,
..) will be adapted especially to have this feature.
I think these two concepts should be resolved in separate ways.
Best regards
On Thu, Nov 25, 2021 at 9:45 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> By the way, in order to make enabled/disabled state dynamic, TreeCloner
> should
> automatically convert "enabled expressions" into
> IfController(condition="enabled expression") { originalComponent(...) }
>
> Then we won't need to touch executor logic, and we would get automatic
> support for all the plugins.
> WDYT?
>
> ----
>
> >How would you trigger those modes? Another checkbox?
>
> It could be a checkbox in the menu.
> Here's one of the discussions on that:
> https://lists.apache.org/thread/lzdoljpwr9kzm4kqns9cyz1v45ppo19d
>
> >I think it is important to have the two boolean states plus a third form
> >to be able to convert older checkboxes to such a new ui element without
> >breaking the old save format.
>
> If checkbox + edit is UI only feature, then
> "boolProp" => boolean value
> string "true" => true
> string "false" => false
> else => treat as expression (third state)
>
> So far it looks ok. We should be able to read old files, and as we save we
> could save it as "stringProp" always.
>
> Vladimir
>
--
Cordialement,
-------------
Anas OUFDOU
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>wrapper registry
I think wrapper is just a single case, and it is unlikely "wrapper
registry" would be reused in the future.
Test plan transformations will likely be on a case-by-case basis.
>that might come to a curious mind.
Let me put it this way: expression transformation is a very common pattern
in optimizing compilers.
See https://stackoverflow.com/a/21295297/1261287
In other words, we have two options:
a) We could make the logic of every test element more complicated, and
force every plugin to implement support for "dynamic enable"
b) We could rewrite the user-provided test plan into a suitable format for
execution using the currently available operators
It turns out, that "dynamic enable" can be represented with the currently
existing IfComponent.
In that regard, we add a lowering that transforms "component with a
possibly complex enabled condition" into
a couple of existing components: IfController and a component with a
trivial enabled=true condition.
Then "backend" (==executor) don't even need to know there are
"conditionally disabled elements".
The engine can already execute IfControllers just fine.
Of course, the approach with transforming the plan might fail in certain
cases (e.g. how should ThreadGroup with dynamic disable should even work?!)
However, I really see no value in going with option "a".
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 26.11.21 um 12:35 schrieb Vladimir Sitnikov:
>> I have no idea, how TreeCloner works, so maybe a good idea
> I do not know if you want to figure out the implementation on your own, or
> if you need detailed instructions.
> Here's the code that deals with isEnabled:
> https://github.com/apache/jmeter/blob/a75fc427de8ce6ce80d3f39e955dda9c68d01483/src/core/src/main/java/org/apache/jmeter/JMeter.java#L1165-L1167
>
> Feel free to submit PRs, however, note that the current enabled-disabled is
> universal across plugins,
> so if you add "dynamic enabled", then it should be transparently supported
> for the plugins as well.
OK, so the idea is basically using the same functionality, that handle
older elements, as a wrapper builder, that transforms the "new" elements
to something more complex.
We might add a wrapper registry, that could handle this and other stuff,
that might come to a curious mind.
Will have to look at it a bit more deeper.
Felix
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I have no idea, how TreeCloner works, so maybe a good idea
I do not know if you want to figure out the implementation on your own, or
if you need detailed instructions.
Here's the code that deals with isEnabled:
https://github.com/apache/jmeter/blob/a75fc427de8ce6ce80d3f39e955dda9c68d01483/src/core/src/main/java/org/apache/jmeter/JMeter.java#L1165-L1167
Feel free to submit PRs, however, note that the current enabled-disabled is
universal across plugins,
so if you add "dynamic enabled", then it should be transparently supported
for the plugins as well.
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 25.11.21 um 21:44 schrieb Vladimir Sitnikov:
> By the way, in order to make enabled/disabled state dynamic, TreeCloner
> should
> automatically convert "enabled expressions" into
> IfController(condition="enabled expression") { originalComponent(...) }
>
> Then we won't need to touch executor logic, and we would get automatic
> support for all the plugins.
> WDYT?
I have no idea, how TreeCloner works, so maybe a good idea (maybe not
:)). Are we doing such stuff already?
Felix
>
> ----
>
>> How would you trigger those modes? Another checkbox?
> It could be a checkbox in the menu.
> Here's one of the discussions on that:
> https://lists.apache.org/thread/lzdoljpwr9kzm4kqns9cyz1v45ppo19d
>
>> I think it is important to have the two boolean states plus a third form
>> to be able to convert older checkboxes to such a new ui element without
>> breaking the old save format.
> If checkbox + edit is UI only feature, then
> "boolProp" => boolean value
> string "true" => true
> string "false" => false
> else => treat as expression (third state)
>
> So far it looks ok. We should be able to read old files, and as we save we
> could save it as "stringProp" always.
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ao...@sqli.com>.
for the sampler and controller it's possible to use ifController but some
time it's heavy for a small check, but for processor you should duplicate
the sampler with two if controler to have if else behavior.
On Fri, Nov 26, 2021 at 12:39 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >Because to check if a sampler is enabled at the moment of the execution i
> >think it should be checked in GenericController, in the next method
>
> If you wrap a component with "if controller", then ANY component (not sure
> regarding pre/post processors) would get
> dynamic support for free.
>
> That is exactly what I suggest in
> https://lists.apache.org/thread/grjhy5qzw0lc94n5fngsffd99qxlxnk3
>
> User plan:
> ThreadGroup
> HttpRequest(enabled=${httpreqenabled}, url="example.com")
>
> That plan should be auto-converted as follows:
> ThreadGroup
> IfController(condition=${httprequest})
> HttpRequest(enabled=true, url="example.com")
>
> Then individual components could be left as is.
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Because to check if a sampler is enabled at the moment of the execution i
>think it should be checked in GenericController, in the next method
If you wrap a component with "if controller", then ANY component (not sure
regarding pre/post processors) would get
dynamic support for free.
That is exactly what I suggest in
https://lists.apache.org/thread/grjhy5qzw0lc94n5fngsffd99qxlxnk3
User plan:
ThreadGroup
HttpRequest(enabled=${httpreqenabled}, url="example.com")
That plan should be auto-converted as follows:
ThreadGroup
IfController(condition=${httprequest})
HttpRequest(enabled=true, url="example.com")
Then individual components could be left as is.
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ou...@gmail.com>.
Because to check if a sampler is enabled at the moment of the execution i
think it should be checked in GenericController, in the next method.
I don't have time to do a full check, but my first vision is that the
Controller just implements interface and there is no generic way to skip
sampler/controller.
On Fri, Nov 26, 2021 at 9:48 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >actually enable is used before test to
> > filter component, and I think each case (listener, controller, sampler,
> ..)
> >will be adapted especially to have this feature
>
> Why do you think each component needs to treat "dynamic enable"
> differently?
>
> Vladimir
>
--
Cordialement,
-------------
Anas OUFDOU
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>actually enable is used before test to
> filter component, and I think each case (listener, controller, sampler,
..)
>will be adapted especially to have this feature
Why do you think each component needs to treat "dynamic enable" differently?
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ao...@sqli.com>.
Hello,
Enable/disable attribute concerne two different use case :
1- Generic problem related to some boolean already present in many
components that may will interessant to have a generic solution to also
have the possibility to use expression.
2- Evaluate enable at runtime, actually enable is used before test to
filter component, and I think each case (listener, controller, sampler, ..)
will be adapted especially to have this feature.
I think this two concepts should be resolved in separate way.
Best regards
On Thu, Nov 25, 2021 at 9:45 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> By the way, in order to make enabled/disabled state dynamic, TreeCloner
> should
> automatically convert "enabled expressions" into
> IfController(condition="enabled expression") { originalComponent(...) }
>
> Then we won't need to touch executor logic, and we would get automatic
> support for all the plugins.
> WDYT?
>
> ----
>
> >How would you trigger those modes? Another checkbox?
>
> It could be a checkbox in the menu.
> Here's one of the discussions on that:
> https://lists.apache.org/thread/lzdoljpwr9kzm4kqns9cyz1v45ppo19d
>
> >I think it is important to have the two boolean states plus a third form
> >to be able to convert older checkboxes to such a new ui element without
> >breaking the old save format.
>
> If checkbox + edit is UI only feature, then
> "boolProp" => boolean value
> string "true" => true
> string "false" => false
> else => treat as expression (third state)
>
> So far it looks ok. We should be able to read old files, and as we save we
> could save it as "stringProp" always.
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
By the way, in order to make enabled/disabled state dynamic, TreeCloner
should
automatically convert "enabled expressions" into
IfController(condition="enabled expression") { originalComponent(...) }
Then we won't need to touch executor logic, and we would get automatic
support for all the plugins.
WDYT?
----
>How would you trigger those modes? Another checkbox?
It could be a checkbox in the menu.
Here's one of the discussions on that:
https://lists.apache.org/thread/lzdoljpwr9kzm4kqns9cyz1v45ppo19d
>I think it is important to have the two boolean states plus a third form
>to be able to convert older checkboxes to such a new ui element without
>breaking the old save format.
If checkbox + edit is UI only feature, then
"boolProp" => boolean value
string "true" => true
string "false" => false
else => treat as expression (third state)
So far it looks ok. We should be able to read old files, and as we save we
could save it as "stringProp" always.
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 25.11.21 um 20:14 schrieb Vladimir Sitnikov:
>> The second variant would hide the expression text in the two static cases.
> I thought behind those lines as well. It might be we could add a small
> marker that
> informs the user that checkbox is configurable.
>
> ----
>
> I just attended a talk by
> https://www.smashingmagazine.com/author/vitaly-friedman/
> I asked Vitaly for the ideas for this "crazy checkbox" UI element.
>
> As expected, Vitaly was quite puzzled, so unfortunately I got no ideas :)
>
> ---
>
> One more idea would be having "regular" and "expert" modes, where regular
> mode looks like checkbox,
> and in expert mode, all "supercheckboxes" always show their "text fields".
>
> Vitaly said regular/expert modes are a good pattern for UI.
>
> In other words, "the first variant" by Felix could be "expert mode", and
> "the second variant" could be "regular mode".
How would you trigger those modes? Another checkbox?
(I sometimes think, we should try to make all those properties we have
available in a GUI somewhere)
>
> ---
>
> One more option is to show the text field in a popup/tooltip:
> [ ] ▼ enable element
>
> When you click on ▼ (triangle down or whatever), a popup appears that
> overlays extra controls for the checkbox in question.
> As an extra, it could contain extra information like JMeterProperty name,
> option for configuring the field from a command line, etc
>
> It could be a right triangle, so it "folds/unfolds" the text field (and
> "global expert mode" unfolds all the folded fields)
Yes, that would make it more clear, that there are more possibilities to
use the checkbox.
Would the "enable element" text be visible or is it a marker to
higlight, that the triangle would be used to enable the element?
I think it is important to have the two boolean states plus a third form
to be able to convert older checkboxes to such a new ui element without
breaking the old save format.
Felix
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
> The second variant would hide the expression text in the two static cases.
I thought behind those lines as well. It might be we could add a small
marker that
informs the user that checkbox is configurable.
----
I just attended a talk by
https://www.smashingmagazine.com/author/vitaly-friedman/
I asked Vitaly for the ideas for this "crazy checkbox" UI element.
As expected, Vitaly was quite puzzled, so unfortunately I got no ideas :)
---
One more idea would be having "regular" and "expert" modes, where regular
mode looks like checkbox,
and in expert mode, all "supercheckboxes" always show their "text fields".
Vitaly said regular/expert modes are a good pattern for UI.
In other words, "the first variant" by Felix could be "expert mode", and
"the second variant" could be "regular mode".
---
One more option is to show the text field in a popup/tooltip:
[ ] ▼ enable element
When you click on ▼ (triangle down or whatever), a popup appears that
overlays extra controls for the checkbox in question.
As an extra, it could contain extra information like JMeterProperty name,
option for configuring the field from a command line, etc
It could be a right triangle, so it "folds/unfolds" the text field (and
"global expert mode" unfolds all the folded fields)
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Felix Schumacher <fe...@internetallee.de>.
I think it would be nice to have a general UI component, that is a
tristate checkbox, where the clicking on the checkbox in front would
toggle a possibly hidden text field, where an expression could be placed.
A text representation of the three states might be either
[_] <grayed>expression</grayed>
[x] <grayed>expression</grayed>
[#] <editable>expression</editable>
or
[_]
[x]
[#] expression
The states would mean [_] => false, [x] => true, [#] => result of
expression at runtime
The first variant would display the expression text in all cases, but
indicate, that the expression can't be edited and won't be used.
The second variant would hide the expression text in the two static cases.
Felix
Am 25.11.21 um 15:37 schrieb OUFDOU Anas:
> The screen UI will look like this,
>
> image.png
> I prefer using simple text input to not be the preferable way when
> it's a static value true or false, in this case the enabled from menu
> is preferable as the component will be grayed ..and skip is not to
> used to replace the old enabled case, only to be used when value it's
> dynamic.
>
>
> best Regards
>
>
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrCZCtvfjIH0__06sMX98JTpw==>
>
>
>
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5_O9YaWlk4nBKUHhaZ1phej_QXSutzSvDX6YXlPu8rPc>
>
>
>
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50ufVx8dW6gZtUFvZ1gMVIvbJOeuljB2LWaLJI8NlhGlKD921mmu9UHBGPvb6ZuPGw==>
>
>
>
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5-jpVnIV_are3Z-m5blBfs6qRL1kX_L0DRlcirdCgINiQ_Y62P6vso5Oi8QshaN52w==>
>
>
>
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrC71_qMKBe73RCHKRjGeDsE68U-TmlvnN27_c7uQRHayw=>
>
>
>
> Anas Oufdou
>
> Technical expert
>
> aoufdou@sqli.com
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H57Cwsks_wvHOp7OaK36PwiZ1WXD24t4ovd5t4eGFMTS5>
>
> T.
>
>
>
> M. 070 31 96 40
>
>
> www.sqli.com
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H57vyBkJAMjiVOosPWFU_7Z4=>
> - www.sqli-carrieres.com
> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5z4siItpRerryTmLr0LvuqjHGeDYPIxxNs1sMlZTnBbArxT5OaW-c3bv9zu5BEdrLA==>
>
>
>
> <https://cloud.letsignit.com/collect/b/6148b0e305b7e6c73bb28748?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrC71_qMKBe73RCHKRjGeDsE68U-TmlvnN27_c7uQRHayw=>
>
>
>
>
> On Thu, Nov 25, 2021 at 3:00 PM Vladimir Sitnikov
> <sitnikov.vladimir@gmail.com <ma...@gmail.com>> wrote:
>
> Frankly speaking, I would start with UI first (mockup or something).
>
> Do you know how the screen would look like?
> Can you share it?
>
> ---
>
> I think that "enabled/disabled" should look like a checkbox so one can
> enable-disable even without a context menu,
> and there should be an option to "convert" the textbox into an
> editable
> field for typing ${...} expressions.
>
> I do not mean full-blown control with autocomplete and things like
> that.
> Just a checkbox-like component with ability to turn it into a editable
> field or something like that.
>
> In other words, there might be a "JConfigurableCheckbox" component
> that can
> be used for "enabled-disabled" control, and for other controls.
> For instance, the combo-box you show for "ignore first line only"
> is too
> verbose for "follow redirects" case.
> Of course, components would have to use this control explicitly,
> however,
> having such control would make JMeter UI more consistent.
>
> Vladimir
>
>
> чт, 25 нояб. 2021 г. в 15:53, OUFDOU Anas <aoufdou@sqli.com
> <ma...@sqli.com>>:
>
> > It's not clear for me what do you mean by generic solution??
> >
> > Can you detail more what you expect to have ?
> >
> > On Thu, Nov 25, 2021 at 12:15 PM Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com
> <ma...@gmail.com>> wrote:
> >
> > > >if any boolean or integer who doesn't support using the
> expression , i
> > > think it should be corrected at component level like CSV dataset
> > >
> > > JMeter should provide a solid foundation so other components
> can reuse
> > and
> > > extend core approaches.
> > >
> > > This case has clear and generic solutions for the problems you
> list, so I
> > > do not see why should we
> > > implement a very specific solution, especially when a more
> generic one is
> > > possible with little effort.
> > >
> > > Vladimir
> > >
> >
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ao...@sqli.com>.
The screen UI will look like this,
[image: image.png]
I prefer using simple text input to not be the preferable way when it's a
static value true or false, in this case the enabled from menu is
preferable as the component will be grayed ..and skip is not to used to
replace the old enabled case, only to be used when value it's dynamic.
best Regards
On Thu, Nov 25, 2021 at 3:00 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Frankly speaking, I would start with UI first (mockup or something).
>
> Do you know how the screen would look like?
> Can you share it?
>
> ---
>
> I think that "enabled/disabled" should look like a checkbox so one can
> enable-disable even without a context menu,
> and there should be an option to "convert" the textbox into an editable
> field for typing ${...} expressions.
>
> I do not mean full-blown control with autocomplete and things like that.
> Just a checkbox-like component with ability to turn it into a editable
> field or something like that.
>
> In other words, there might be a "JConfigurableCheckbox" component that can
> be used for "enabled-disabled" control, and for other controls.
> For instance, the combo-box you show for "ignore first line only" is too
> verbose for "follow redirects" case.
> Of course, components would have to use this control explicitly, however,
> having such control would make JMeter UI more consistent.
>
> Vladimir
>
>
> чт, 25 нояб. 2021 г. в 15:53, OUFDOU Anas <ao...@sqli.com>:
>
> > It's not clear for me what do you mean by generic solution??
> >
> > Can you detail more what you expect to have ?
> >
> > On Thu, Nov 25, 2021 at 12:15 PM Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com> wrote:
> >
> > > >if any boolean or integer who doesn't support using the expression , i
> > > think it should be corrected at component level like CSV dataset
> > >
> > > JMeter should provide a solid foundation so other components can reuse
> > and
> > > extend core approaches.
> > >
> > > This case has clear and generic solutions for the problems you list,
> so I
> > > do not see why should we
> > > implement a very specific solution, especially when a more generic one
> is
> > > possible with little effort.
> > >
> > > Vladimir
> > >
> >
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
Frankly speaking, I would start with UI first (mockup or something).
Do you know how the screen would look like?
Can you share it?
---
I think that "enabled/disabled" should look like a checkbox so one can
enable-disable even without a context menu,
and there should be an option to "convert" the textbox into an editable
field for typing ${...} expressions.
I do not mean full-blown control with autocomplete and things like that.
Just a checkbox-like component with ability to turn it into a editable
field or something like that.
In other words, there might be a "JConfigurableCheckbox" component that can
be used for "enabled-disabled" control, and for other controls.
For instance, the combo-box you show for "ignore first line only" is too
verbose for "follow redirects" case.
Of course, components would have to use this control explicitly, however,
having such control would make JMeter UI more consistent.
Vladimir
чт, 25 нояб. 2021 г. в 15:53, OUFDOU Anas <ao...@sqli.com>:
> It's not clear for me what do you mean by generic solution??
>
> Can you detail more what you expect to have ?
>
> On Thu, Nov 25, 2021 at 12:15 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > >if any boolean or integer who doesn't support using the expression , i
> > think it should be corrected at component level like CSV dataset
> >
> > JMeter should provide a solid foundation so other components can reuse
> and
> > extend core approaches.
> >
> > This case has clear and generic solutions for the problems you list, so I
> > do not see why should we
> > implement a very specific solution, especially when a more generic one is
> > possible with little effort.
> >
> > Vladimir
> >
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ao...@sqli.com>.
It's not clear for me what do you mean by generic solution??
Can you detail more what you expect to have ?
On Thu, Nov 25, 2021 at 12:15 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >if any boolean or integer who doesn't support using the expression , i
> think it should be corrected at component level like CSV dataset
>
> JMeter should provide a solid foundation so other components can reuse and
> extend core approaches.
>
> This case has clear and generic solutions for the problems you list, so I
> do not see why should we
> implement a very specific solution, especially when a more generic one is
> possible with little effort.
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>if any boolean or integer who doesn't support using the expression , i
think it should be corrected at component level like CSV dataset
JMeter should provide a solid foundation so other components can reuse and
extend core approaches.
This case has clear and generic solutions for the problems you list, so I
do not see why should we
implement a very specific solution, especially when a more generic one is
possible with little effort.
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ou...@gmail.com>.
This attribute will be a string value, like name, and can have value using
function. it will be present on all screens on the same line, let's name it
"skip".
yes it will be different from "follow redirects" as follow redirect is a
checkbox.
For other case when checkbox is used, each boolean depends on its
component, and I don't think all attributes have the same importance as
enabled attributes, if any boolean or integer who doesn't support using the
expression , i think it should be corrected at component level like CSV
dataset.
[image: image.png]
Best regard,
On Thu, Nov 25, 2021 at 11:08 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >In my case I will add a new string value and keep the static enabled also
>
> Is this "enabled" property any different from other properties like "number
> of threads", "sleep delay", and so on?
> Is this "enabled" property different than "follow redirects" property in
> HTTP Sampler?
>
> I would suggest making a more generic approach (support other properties,
> not just "disabled" one) rather than fixing a single use-case only.
>
> Vladimir
>
--
Cordialement,
-------------
Anas OUFDOU
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
>In my case I will add a new string value and keep the static enabled also
Is this "enabled" property any different from other properties like "number
of threads", "sleep delay", and so on?
Is this "enabled" property different than "follow redirects" property in
HTTP Sampler?
I would suggest making a more generic approach (support other properties,
not just "disabled" one) rather than fixing a single use-case only.
Vladimir
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by OUFDOU Anas <ao...@sqli.com>.
Yes, they are very similar,
In my case I will add a new string value and keep the static enabled also,
as I suppose the old enabled is just for temporary use or a deprecated node
before deletion.
it will be possible to disable/enable node with property but it should be
taken in consideration i the script, for example you can use
*$P(only.for.gui,true)
*on nodes that need to be disabled by property, and then you can disable
them later , you can have many property to group components or using
variable . The evaluation will be done at runtime for each execution so
checking groovy also will be available.
Best Regards
On Thu, Nov 25, 2021 at 7:22 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Hi,
>
> That is great.
> Do you think it duplicates
> https://lists.apache.org/thread/1mplrt4bqd6h08kj38hkvxwy527nckpn ?
>
> >Disable post processor (when extracting value from home page, there is
> >no need to consume CPU with each iteration to get the same value )
>
> Currently, JMeter ignores disabled elements forever, and it never
> re-evaluates enabled-disabled state during execution.
> If you really want to make "is element disabled" check dynamic, it would be
> not that easy.
>
>
> Frankly speaking, adding a **text field** just for disabling elements looks
> like overcomplicating UI for an infrequent feature.
> On the other hand, a smaller "enabled" checkbox might be OK.
>
> What do you think of the following?
>
> a) Making a "smart checkbox" Swing component that looks like a checkbox,
> however it has an extra "button" (or something) to convert the checkbox
> into text field.
> Then all JMeter sampler and plugins could use that checkbox to make
> "boolean-like" properties configuration consistent across the UI
>
> b) Implementing a special "element.Thread Group Name.Transaction
> Name.Sampler Name.enabled=true" property syntax
> that would allow overriding element properties from a command line.
> Of course, component names can drift over time, so it might make sense to
> add a notion of "element ID" that would be persistent across load/save
> operations.
> The syntax then could be like
> element.82f0e0cd-ee42-49db-a0ec-b8b9c6cb8bc1(comment-here).enabled=false or
> even
>
> element.7c3161d9-ade9-4f82-b183-308774149a78(user-search-thread-group).ThreadGroup.num_threads=42
> The comment in braces would be ignored, and it would be there just for the
> humans to understand the intention of the property.
>
> Do you think you could work on those features?
>
> Vladimir
>
Re: [Jmeter] Enhancement , Disable component using attributes
Posted by Vladimir Sitnikov <si...@gmail.com>.
Hi,
That is great.
Do you think it duplicates
https://lists.apache.org/thread/1mplrt4bqd6h08kj38hkvxwy527nckpn ?
>Disable post processor (when extracting value from home page, there is
>no need to consume CPU with each iteration to get the same value )
Currently, JMeter ignores disabled elements forever, and it never
re-evaluates enabled-disabled state during execution.
If you really want to make "is element disabled" check dynamic, it would be
not that easy.
Frankly speaking, adding a **text field** just for disabling elements looks
like overcomplicating UI for an infrequent feature.
On the other hand, a smaller "enabled" checkbox might be OK.
What do you think of the following?
a) Making a "smart checkbox" Swing component that looks like a checkbox,
however it has an extra "button" (or something) to convert the checkbox
into text field.
Then all JMeter sampler and plugins could use that checkbox to make
"boolean-like" properties configuration consistent across the UI
b) Implementing a special "element.Thread Group Name.Transaction
Name.Sampler Name.enabled=true" property syntax
that would allow overriding element properties from a command line.
Of course, component names can drift over time, so it might make sense to
add a notion of "element ID" that would be persistent across load/save
operations.
The syntax then could be like
element.82f0e0cd-ee42-49db-a0ec-b8b9c6cb8bc1(comment-here).enabled=false or
even
element.7c3161d9-ade9-4f82-b183-308774149a78(user-search-thread-group).ThreadGroup.num_threads=42
The comment in braces would be ignored, and it would be there just for the
humans to understand the intention of the property.
Do you think you could work on those features?
Vladimir