Closed gela-d closed 8 years ago
You have to use the same js parameter id
for this case.
You have to use the same js parameter id for this case.
If I understand correctly, I shall use this entry:
{
block : 'radio',
mods : { theme : 'islands', size : 'm' },
name : 'radio-islands',
js: { id: 123 },
val : 'BEMHTML',
text : 'Использовать BEMHTML-1'
},
{
block : 'radio',
mods : { theme : 'islands', size : 'm' },
name : 'radio-islands',
js: { id: 123 },
val : 'BEMHTML',
text : 'Использовать BEMHTML-2'
}
? If this entry correct - it doesn't work, both of radio checked simultaneously
Oh. You mustn't use radio
without radio-group
.
Yes, this is my problem - to use radio in table, where I haven't possibility to use radio-group.
It's not a problem, just use radio-group
s (with the same id
) instead of radio
s.
Thanks, it works, but I still think that posiibility to use this:
{
block : 'radio',
mods : { theme : 'islands', size : 'm' },
name : '123',
text : 'first'
},
{
block : 'radio',
mods : { theme : 'islands', size : 'm' },
name : '123',
text : 'second'
}
is better than
{
block : 'radio-group',
mods : { theme : 'islands', size : 'm' },
js: { id: 123 },
options : [
{ val : 1, text : 'first' }
]
},
{
block : 'radio-group',
mods : { theme : 'islands', size : 'm' },
js: { id: 123 },
options : [
{ val : 2, text : 'second' }
]
}
radio
isn't supposed to be used without radio-group
.
Dima, thanks for answers.
Let's discuss it a bit more.
We claim that bem-components
provide blocks which work the same way as native.
Shouldn't we keep this task as improvement for radio
to work independently?
By the way, i have some problem with radio-group
.
I use two radio-group
with one option and one ID in bemjson.
Then, I add one more radio-group
width the same ID from javascript BEMHTML.apply({})
. In html I see that all of three blocks have identical ID, but two of them (from bemjson) works together, and third, from js, hasn't connected to them.
@gela-d blocks are joined during initialization. You can't add another part after.
We claim that bem-components provide blocks which work the same way as native.
It can't be true. We already have blocks and behaviours which don't have corresponding ones in html.
It can't be true. We already have blocks and behaviours which don't have corresponding ones in html.
I meant «not worse than native».
Suggested solution:
_onChange : function(e) {
var blockName = this.__self.getName(),
selector = this.buildSelector(),
controlSelector = this.buildSelector('control'),
control = e.currentTarget,
name = this.getName(),
isChecked = control.attr('checked');
$(controlSelector + '[name=' + name + ']')
.parents(selector)
.each(function() {
$(this).bem(blockName).delMod('checked');
});
this.setMod('checked', !isChecked);
}
I don't like the idea to use global selectors just to support this edgecase.
Maybe we can implement it as a modifier?
Can't such modifier be implemented on the project level first? We could backport it to the library if the case'd be seen more often.
In html-word we have possibility to use two separate
<input type="radio"
with identical name combined two radio-buttons in different places of the page.But, if I combine two radio-buttons from bem-components, they do not want to be combined, even though they have the same names.
This feature is very important to use block
radio
in such structures as tables, when we haven't posibility to use blockradio-group
.