Default field implementations don't pass the backing data item through template functions

[tonisostrat]

Looking at the core Field, editTemplate function is defined as:

editTemplate: function(value, item) {
    this._value = value;
    return this.itemTemplate(value, item);
}

which is all well and good.

However, all the concrete fields extending from it override that function and discard the item object. Following example is from SelectField:

editTemplate: function(value) {
    if(!this.editing)
        return this.itemTemplate(value);

    var $result = this.editControl = this._createSelect();
    (value !== undefined) && $result.val(value);
    return $result;
}

This means if I have a "perfect storm" combination where a field is non-editable and references other item properties to render itemTemplate() it will break the row-editing functionality because item = undefined.

[tabalinas]

Are you sure this is the case? It doesn't matter that item is not used in this concrete field, you can redefine editTemplate and you will get the item as a second parameter. Everything should work fine.

[tonisostrat]

I apologize for leaving out a crucial bit of information - this only happens if I create a custom Field that inherits from one of the concrete Field types instead of the base Field class.

I have created a simple example to showcase the problem: JSFiddle. Toggle the row edit and you'll see.

EDIT:

After re-reading your answer, yes, that's the workaround I've implemented right now but my original scenario, like the fiddle I linked, was without the editTemplate() override.

[tabalinas]

Now I see. Yes, you are right. But the base field doesn't support editing, that's why it just calls itemTemplate. While editing option of the field currently only defines whether the field will get in updateItem(item) or not. From this prospective, I guess we could say that these are different use cases.

I agree this could be reasonable to render itemTemplate once editing is turned off, but this would be a breaking change. Moreover it's pretty easy to define editTemplate for the custom field just returning the value.

Let me know, what you think.

[tonisostrat]

I agree this could be reasonable to render itemTemplate once editing is turned off, but this would be a breaking change.

I don't see how that can be a breaking change considering that it already works like that, snippet from SelectField again:

editTemplate: function(value) {
  if(!this.editing)
    return this.itemTemplate(value);

  //rest of the code
}

The only change I propose is that the item is also passed through:

editTemplate: function(value, item /*just like in base Field */) {
  if(!this.editing)
    return this.itemTemplate(value, item /* just like in base Field */);

  //rest of the code
}

But, obviously, it's totally up to you. I have it working by overriding editTemplate() in my custom Field implementation but it just.. looks weird considering that I have editing turned off yet on the next line I do something with editTemplate().

[stephenlawuk]

I just ran into this issue as I wanted to adjust the item template based on a piece of data. So in the example below this field has editing off but if my DateLeft has a value then I wanted to do something to the field, my test was putting a line through but eventually I will colour code. The itemtemplate works for viewing but the editing for other columns didn't work at all on mine (would not even open).

However it did work after I added the overridden editTemplate that tonisostrat suggested which seemed strange as I wasn't even using editing for that column. Anyway thanks for the work around tonisostrat.

{ name: "FirstName", type: "text", title: "Forename", inserting: false, editing: false,
    itemTemplate: function (value, item) {
        if (value != null && value != undefined) {
            if(item.DateLeft != null) {
                return $("<div style='text-decoration: line-through;'>").html(value);
            } else {
                return $("<div>").html(value);
            }
        } else {
            return "";
        }
    }
}

[tabalinas]

@tonisostrat, ah, now I see. I thought you are proposing to put this logic (fallback to itemTemplate if editing is false) from fields to the grid level. The problem you are describing is definitely a bug.
Thank you for reporting and detailed explanation.