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