example code:
{
view:“radio”,
name:‘test’,
id:‘test’,
label:“Branch”,
value:1, options:[
{“id”:1, “value”:“Master” },
{“id”:2, “value”:“Production”, disabled: true}
]
}
But disable property is not working.
disabled property isn’t related to a single option. But you can manually block the selection of the particular item in onChange event:
Hi webix team!!!
Are there any plans to change this behaviour or maybe you have a good workaround?
Disabling of radio options (also in visual context) is really important for us, to show all of the given options without putting up any extra clicks.
Customers should see, that an option isn´t selectable and don’t need to try it.
Hey @lBeJIuk, thank you for expressing your need in such a feature. The only workaround at the current time is using CSS. We are going to consider this feature going in the future, you might see it get implemented at some point.
Hey @Dzmitry,
we also have the same need on our side, so thanks for your answer in this thread!
Depending on the previous selection of one radio group several options of another group should be enabled/disabled.
The user should see the other options, but cannot select them. (like standard html radios)
The solution Listopad provided two (!) years ago, unfortunately does not exactly fit to our requirements and would require much work/effort on our side to implement a workaround in our abstraction of the component.
(In my humble opinion our requirements are very common, e.g. in complex apps or enterprise applications, online shops etc.,
since it is also a valid html property and many users are able to understand and interact in a perfect way with them or what do you think?)
The provided workaround is not really disabling of radios, instead its only reverting the selection.
(Setting the oldVal immediately without firing the events, but selection really changes for a few milliseconds.)
I would think that implementing such a feature, should not cause too much effort.
Might be possible to give a new Flag at option level (“disabled: true/false”) which should be considered at line “var rd = common._baseInputHTML(“input”) + " name=’” + (config.name || config.id) + “’ type=‘radio’ " + (isChecked ? “checked=‘1’” : “”) + “tabindex=” + (isChecked || i === 0 && !config.value ? “0” : “-1”) + " value=’” + options[i].id + “’ id=’” + eachid + “’ style=’” + (customRadio ? “display:none” : “”) + “’ />”;"
The deeper I look into the webix sourcecode, the more I have the impression that these problems can’t all be solved without a more complex refactoring,
because webix (like the dhtmlx) uses nested divs instead of HTML elements which were created for the purpose.
Since Webix has now also abolished the compatibility of older browsers, it may be time about thinking of a deeper refactoring of the core functions
and leaving the browsers to do their work?
Next problem is, that if there are several event listeners for onChange Events (which might be possible in complex software), the solution probably won’t be enough.
As developer I need to make sure, that every onChange Eventlistener has the same “optionIsDisabled” test implemented. If not, the given handler would get the “wrong” values.
(Technically they are correct, because the value HAS changed for a moment…)
If there would be a more comprehensive event system it could be maybe solved in this way.
Sencha has a very nice event system in extjs, which often provides three events (Before, On, After) for one action.
Such a thing (consistently implemented) would also be a possibility. If there would be an event “beforeChange” I could check selection against a “blacklist” and return false if
option isn´t allowed to get selected.
In your answer (from 19th July) you told, that the only workaround is using CSS.
How would it be possible to “disable” the option with it? Do you maybe have an short snippet as example?
Perhaps we can find a good, pracitable solution together?
Many thanks in advance!
Hey @intregal,
wow, that was really fast! Many thanks for your big help!
At first glance it looks really good an I think its a practicable workaround.
Will give it a try!
@webix team: Would it be possible to implement a solution based on intregal snippet into the core? Has the big advantage, that a possible webix update, wouldn´t break the code. Other customers would also benefit, I guess.
Wish you a pleasant weekend (and again @intregal: many thanks!)