Allow "single" as well as "unlimited" cardinality

Also wondering why the widget only displays fields with unlimited cardinality.

We only want the user to be able to select one item. Really, we want radio buttons rather than checkboxes.

yes me too I need to restrict to choose only one entity

I have created a new module that allows for much more flexibility in creating the view. It doesn't have any cardinality limitations, but the UI doesn't currently restrict the user's from selecting more then your maximum (I am planning on putting in some jQuery validation though). You can use the table view layout and add any addition fields you want. It also is much more light-weight in its implementation with less ajax calls back to Drupal.

I made my module due to a large Drupal site I was working on, the Entity Reference View Widget just wasn't scaling due to all the form processing it was doing along with every click being a big ajax call. I did base parts of my module on Entity Reference View Widget and it would be interesting to see if some of these things could be merged back into this project.

It is currently in a sandbox: http://drupal.org/sandbox/davidseth/1489176. You will have to check out the 7.x-1.x branch.

davidseth, sounds cool!
could you please provide module file for those who are not yet well familiar with git.

@davidseth
I am really annoyed by the fact that you decided to spam every issue with a link to your sandbox, instead of opening a new issue. It is rude.

@bojanz my intent was not to be rude or to spam. I replied thoughtfully to *just* the issues that were relevant and that I thought my sandbox would help. You will notice that I was careful to add that I am happy to work with you guys. I specifically didn't open a new issue because I didn't want to appear to "take over" from what you are doing. I just wanted to address the people who were looking for more flexibility.

I specifically didn't open a new issue because I didn't want to appear to "take over" from what you are doing.

and

 I just wanted to address the people who were looking for more flexibility.

are in opposition.

Nowhere in this queue did I say I was against removing unnecessary ajax calls. There's a big difference between:
- addressing problems in a sandbox and then opening an issue in the main project requesting review (and even co-maintainership)
- addressing problems in a sandbox and then posting to all open issues saying "just use this one instead".
One of them is the open source way. The other is just clumsy and smells like a fork.

@bojanz - If you re-read my original post it says what my module does (for each case) and also says I was wanting to work with you guys on your module. Of course you never said you were against less ajax calls. But it has been 17 weeks since the last commit to this module. And many of the requesters have had no interaction with any of the module maintainers. There were quite a number of people who could immediately benefit from some of the work that I did.

I am doing this work on my own dime. I am not getting paid for it. I am keen to "help" people and to give back to the community since it has given me a lot.

Using words like "clumsy" is not the most beneficial way forward. If you would like we can open a new issue or simply email to help resolve this and turn down the volume a bit so that we can work in a more efficient and friendly fashion :)

I am happy to redact any or all of my posts to your issue queue. Please let me know how you would like me to continue...

Okay. Please open a new issue intended for sandbox review. I will go through your code this week and we can discuss merging the code there.
I am keen to move the module forward, but mostly held back by the hackish nature of the current code. Hoping your code will help.

Yeah!!! Join your forces guys, the whole Community will be grateful for this.

Thank you very much for your work.

I posted some patches in the issue queue of Entityreference Browser. You should apply them first.

What's the status of this issue? I need to limit the number of selected items.

If you need it immediately you could count the ticks with javascript and unbind the click/change event when the user has reached the maximum.

I ended up getting this to work by applying a contextual filter against the field itself. Found out by total accident... but any contextual filter will limit the view to one item!

So in my case, the name of the field on my content type was field_design. I put a contextual filter on the view (using that field) and put the default behavior to show all results. It works just as it should, and I lost no functionality (that I can tell).

Hope this helps someone else out there... and if this is an unintended hack... please don't fix it. Haha.

Any updates?

Thanks. You solved my problem perfectly.

the original issue is in fact a reasonable feature request.
excluding other cardinalities for now.

Dammit, tried #19 on mine and it didn't work :(
It's a shame as it would otherwise give me all that I need for a project. The form I'm using it for pulls the information into a new node, so multiple cardinality is really problematic.

[EDIT: it worked when I selected "Pass selected entity ids to View". When you select an item it hides all others. It's still a little hacky, but it does the job.

The 2.x branch fixed this.
Open a new issue if you think it should be tweaked further.