Last Updated: 20 Nov 2014 18:49 by ADMIN
Created on: 15 Nov 2012 17:42
Category: Kendo UI for jQuery
Type: Feature Request
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
Posted on: 19 Feb 2014 19:42
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.
Posted on: 31 Jan 2014 20:35
Why isn't this fixed yet?
Posted on: 30 Aug 2013 01:27
Not really happy about having to include data-value-primitive on all my DropDownLists.
Imported User
Posted on: 27 May 2013 15:18
Telerik, could you at least respond why you feel this should not be addressed?
Imported User
Posted on: 10 May 2013 09:34
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.
John Peterson
Posted on: 04 Apr 2013 17:14
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:  

Come on guys.  Totally different behavior for nulls?  How did this slip through the cracks?
Imported User
Posted on: 22 Mar 2013 11:02
Imported User
Posted on: 22 Mar 2013 10:21

This is really a top priority issue. It doesn't make sense to make such functionality inconsistent.
Posted on: 22 Mar 2013 00:12
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.
Imported User
Posted on: 25 Feb 2013 14:59
wow, such a basic thing is not working - wtf?
Posted on: 19 Feb 2013 20:52
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.
Imported User
Posted on: 16 Jan 2013 16:43
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? 
Imported User
Posted on: 20 Nov 2012 09:06
Yes, this new Bug is very disappointing. Please find a fast solution and make it useful again... 
Posted on: 19 Nov 2012 16:26
i have the same problem here. it's a very disappointing bug... we had to implement a workaround to get it work.
Posted on: 19 Nov 2012 15:01
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: