@C-Lodder this one is for you

Dont forget to put a blank line at the end of the files

Some thoughts based on looking at the code (not tested yet):

• Afair we can already set a layout in the XML. Does this work with that? From the code I would think it automatically appends new layouts even if another one is specified in the XML already.
• I find it a bit counterintuitive to use different layouts based on a CSS class. Again, we can already set a layout in the XML to my knowledge.

Maybe it would make more sense to create a "switcher" layout and specify that layout in the XML instead of the class="switcher" we do currently. One could do the same for the btn-group but keep some B/C code here for extensions that still use the class for this. That would make the code a lot cleaner in the end I think.

I think the layout should be checked in setup(),
First to check if the field has defined attribute layout, then use it,
otherwise you do what you did here: use switch or buttons suffix.

Because, example, I want to set my layout to radio field, I set layout="blabla.my.field.radio", and expect that the field will use blabla/my/field/radio.php, no matter what.

@Bakual @Fedik please don't shoot me, I just moved the existing code over two separate files, nothing fancy from me here

Afair we can already set a layout in the XML

I don't remember why this approach was chosen over the layouts. I think it had to do with B/C or something similar... But I agree the layout option is more appropriate

Because, example, I want to set my layout to radio field, I set layout="blabla.my.field.radio", and expect that the field will use blabla/my/field/radio.php, no matter what.

In such case we should leave the radio as vanilla (its a basic W3C input at the end of the day) and create new fields for button group and switcher. And deal with the possible B/C break

@dgt41 I do not want to shoot you ?

In such case we should leave the radio as vanilla (its a basic W3C input at the end of the day) and create new fields for button group and switcher

I think what you did is good, just need a small improvement,
we should not confuse an user, by another unexpected behavior ?

technically here is need only a new layout for "switcher", and clean up to the default "radio" layout

@Fedik so 3 layouts:

• native w3c radios
• groupped buttons
• switcher

Looks good to me

Two layouts should be enough. grouped buttons are regular radios just with additional CSS classes and a data-toggle attribute. The HTML tags structure stays the same.
So I would do just a regular radio layout with added design feature for btn groups and a switcher layout.

"native radios" and "groupped" it the same layouts, just with fancy styling,
later if no one do, I try to make a pull to what I have suggested in another PR

@dgt41 check dgt41#70 for layout toggling

I agree with 3 layouts. Clearer code and easier to maintain. Dont forget I will be supporting inline and stacked radios so more simple structured layouts would make my life easier

@C-Lodder then can be 3 ?

I have tested this item ✅ successfully on 3eb34fd

I applied the patch and radio buttons are still there and still functional.

Also I could use a own layout file. I create a new radio button in com_content with a layout element:

	<field
		name="test_layout"
		type="radio"
		label="TEST"
		class="switcher"
		layout="joomla.form.field.radio.test"
		default="1"
		>
		<option value="0">JNO</option>
		<option value="1">JYES</option>
	</field>

Then create the layout file in the folder layouts/joomla/form/field/radio/ and I call it test.php

This new field was displayed with my test layout.

I have tested this item ✅ successfully on 3eb34fd

Ready to Commit after two successful tests @dgt41 please resolve conflicting Files.

@dgt41 - Can you fix the conflicts please?
@wilsonge please merge after

Looks like Travis is not Happy

63 | ERROR | Closing parenthesis of a multi-line function call must be on a line by itself

Radios look different now without values.

Indeed. No way to know what is Yes/No, Hide/Show...

Please open a new issue with a reference to this PR as your comments get lost.

@Bakual no need there is PR that fixes this: #19888

Even better ?