Do you only want to select a single value? How about using a dropdown instead using the SelectOne attribute and a custom SelectionFactory?

http://world.episerver.com/blogs/Linus-Ekstrom/Dates/2013/12/SingleMultiple-selection-in-EPiServer-75/

Hi Nilsson,

Thanks for your precious reply.

Yes, we can use dropdown instead but my project requirement is to use radiobutton options and get this value for business logic implementation.

Is there any other way to do this ?

Thanks in advance!

In my point of view, Radio Button vs Dropdown list should not make any difference.

The LanguageSelectionFactory in my example link above only have a hard coded list of languages as example.
In your implementation of ISelectionFactory, you can gather your information from anything you like for example database, web service or any other API.

Technically, radio buttons and dropdown lists solve the same problem: "Select exactly one value".

UX wise, however, there's a fundamental difference. And UX should not be neglected, as it too often is in the Episerver world.

If you have three choices, radio buttons are nice - they give you an immediate overview, making a choice simple.

If you're choosing between 100 values, a dropdown list make more sense, since it can fit loads of data in a tiny (initial) space.

OP: You should look into Registering a custom editor. I don't know exactly what you'll need to set, but probably just find the correct ClientEditingClass value, so your selection factory outputs a radio button list instead of a checkbox list. I'm guessing there exists a default Dojo widget for this somewhere...

An opinionated solution for SelectOne from Episerver's side should be:

• 2 choices => toggle control or radio button list
• 3-5 choices => radio button list
• 6+ choices = dropdown with autosuggest

There's a lot of research behind this sort of thing, something that should be built-in to a CMS. The developer could then be given the option to override this research-based algorithm for deciding the UI if there are some particular aspects of the project that demand it.

Here's an article about when to use alternatives to a dropdown list and why: Dropdown alternatives for better (mobile) forms

Good that you bring UX up. I would like to add extendability and say "avoid checkboxes" for some cases.

For example

• You want to have on/off for address fields in a custom form.
• Later on you might want to have different variations of the address fields based on which country the form applies to.
• Then I think it's easier to start with a dropdown that has on/off values and later on change the options to be off, Swedish address Form, UK address form.