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 < [email protected]> 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 >
