Dropdown Null Values
I'm using the MVC wrappers, I have a foreign key column in my grid and I use the standard foreignkey editor-template. It is not possible to bind a null value (foreign key not set) to the dropdown. It works when I change the template and replace the kendo dropdown with the standard mvc dropdown.
So I guess there's a problem with null values on the kendo dropdown
We implemented the data-value-primitive attribute which enforces the data-value-field to be always used as the “value” . Here is a demo: http://jsbin.com/ulubuq/2/edit
In the last few months I've worked with this quite a bit. Come to find that in most cases, I actually do want the default behavior.
Suppose I have a list of customers in a dropdownlist. I want to display the selected customer's name, e-mail address and phone number. Using MVVM bindings, I can tell the dropdownlist to get its data from an array, and put the selected customer into a observable model field. Now I simply bind my HTML fields for name, e-mail etc. to that model field. I don't have to do any selecting from the array by id.
At first I thought I'd need data-value-primitive on all my DropDownLists. Usually I don't, so I'm happy with Telerik's implemented behavior.
Why isn't this fixed yet?
Not really happy about having to include data-value-primitive on all my DropDownLists.
Wayne Brantley commented
Telerik, could you at least respond why you feel this should not be addressed?
Since the Telerik support has clearly decided to ignore any further input on the forum topic, this seems to be the only remaining forum for discussion of this issue. You've written a data-binding mechanism that reads the ID of an object from the value binding, but writes back an object. I challenge Telerik to justify their "it's not a bug because people rely on this behaviour" claim by describing just ONE plausible scenario where:
1) There's a non-primitive value & source type with an ID and a label property
2) There's a data-bind value binding
3) There's a value field and text field defined
4) The desired behaviour would be to read the value binding as the object's ID, but write it back as the full object as is the current behaviour.
I agree. This type of inconsistent behavior is pretty unbelievable in a public facing framework. I was able to hack around it using the technique in this post: http://www.kendoui.com/forums/ui/combobox/combobox-mvvm-binding-entire-object-instead-of-object-value-mvvm-bug.aspx.
Come on guys. Totally different behavior for nulls? How did this slip through the cracks?
Maurycy Widera commented
Maurycy Widera commented
This is really a top priority issue. It doesn't make sense to make such functionality inconsistent.
Douglas Cameron commented
This design decision makes absolutely no sense. My experience with kendo to date has been favorable, but this is very disappointing.
Please fix this asap. If you need to support clients that have already adapted to this issue then provide an additional configuration field and provide the logical behavior by default.
wow, such a basic thing is not working - wtf?
Paul Anthoney commented
This is an annoying problem, particularly when spending time developing a complete model object for the binding, including the nullable property. It seems to me that this could be fixed by either honoring the nullable property along with the specified data type or by introducing a new model property, that those who do not like the default behavior of setting the value to the object when it is null, can use to get what seems to be the more logical behavior. I can see that if you don't specify any properties for the model field that is being bound how having it bind to the selected object in the drop down makes sense, but if you specify both a primitive type and the nullable property, the binding framework should be smart enough to know that you want a nullable primitive.
The Telerik Admin got torn apart in that thread, and he fell back on the classic excuse "This behavior is by design". Come on now... you are talking to programmers... I use that line everyday to BS regular users.
As Paul mentioned in the thread, what is the point of having a data-value-field attribute if it doesn't do anything. Was it by design to create an attribute with no purpose?
Yes, this new Bug is very disappointing. Please find a fast solution and make it useful again...
Roman Thommen commented
i have the same problem here. it's a very disappointing bug... we had to implement a workaround to get it work.
Marco Bachmann commented
Sorry, I was wrong: It even does not work with normal checkbox. The problem is the data binding that has a problem with assigning null to a number field.
My problem is the same as described in the last post in this thread: