Blazorise: DataGrid: same context for both DisplayTemplate and EditTemplate

Created on 13 Apr 2020  路  4Comments  路  Source: stsrki/Blazorise

I'm trying to use DataGrid for displaying and inline editing user permissions. When displayed, the cell shows permissions as a single string. And when edited, permissions change into checkboxes:

<DataGridSelectColumn TItem="UserRoleVM" Field="@nameof( UserRoleVM.Permissions )" Caption="Permissions" Editable="true" Context="mycontext">
            <DisplayTemplate>
                @{
                    var permissions = (mycontext as UserRoleVM)?.Permissions;
                    @(permissions.EnabledPermissions())
                }
            </DisplayTemplate>
            <EditTemplate>
                @foreach (var p in (mycontext.CellValue as UserPermissions)?.PermissionList ?? new List<UserPermissions.UserPermission>())
                {
                    <CheckEdit @bind-Checked="@p.Selected">@p.ClaimType</CheckEdit> @if (role.IsAdmin) {<span>[DISABLED]</span>}
                }
            </EditTemplate>
        </DataGridSelectColumn>

From what I could find though, value of "context" is different depending on which template you are in:

  • in Display: the list item is fully accessible
  • in Edit: only specific attribute is accessible

I tried looking into possible solutions, went through the code for these templates and I can see that CellEditContext only provides that specific value and there's no way to access the object. This is quite troublesome if the object is a display model that contains information about how to display/render the edit view. So for example in my case, if the row that is being edited is for Admin role - the checkboxes are not needed/should be disabled.

For now as an alternative I have added an event handler that catches Edit button click, updates selected item and continues to invoke the call. It seems that just by clicking Edit button selection isn't change, so this works as a workaround.

I understand this probably won't be a high priority, especially because it seems this is very much made intentionally. But I'm also really interested in finding out if there is any reason at all for why contexts are different based on template, and why Edit would have to be narrowed down (compared to Display).

Also, thanks for the absolutely great work!

Question

All 4 comments

Having full Item on DisplayTemplate is to have more freedom when you want to display custom text. For example you can set Price as a Field but then on DisplayTemplate you can show Price with currency, eg. 123 USD which is a combination of multiple fields.

EditTemplate have CellEditContext so that I can keep track of editing cells so they do not overwrite Item. Without it every change woould be automatically be written on an unredline Item, and Cancel or Undo would not work.

PS.
I just recently discovered that DisplayTemplate can also be used to edit Item values so I need to see how to disable that.

The combination of fields is indeed the use scenario that I also have for the edit as well - a bit like a combobox scenario, where certain options for a property are not allowed depending on other property of an object that's being edited. But I can definitely see the point of separation in order to not update the object while editing, so that f.ex. cancel-action wouldn't need to reload it from DB.
Sounds like a good practice to keep in mind, thank you!

Would it be a lot of trouble to invoke select of item upon edit button press? I think it makes sense that selection would change to the item that is being edited. In this way, after editing process is done the highlighted row would match to the one that was just updated instead of displaying the previous. I have solved this right now by catching click event on edit button, updating selected item to the one passed with click event and then invoking the rest of click call. It seems to work as it should, but I'm not sure if it's a hacky way of doing it.

I really tried looking through the source code (even debugging) to find where this could "fit" in Blazorise, but I'm afraid it's a little beyond my level of coding :-)

If it's working for you then I think that is perfectly fine.

Select cannot be invoked upon Edit buttons press because Blazor works in a way that you cannot work with components directly until they are rendered. That is one of it's limitations unfortunately.

I see, thanks a lot for explanation and your time!

Was this page helpful?
0 / 5 - 0 ratings