Any example of using cascading combo boxes to edit a grid

[CaiusJard]

Suppose there was an employee list:

Dept, Manager, Employee
Tech, Bossman, Worker1
Tech, Bosswoman, Worker2

Let's say I wanted to move worker2 to a new department and give them a new Manager. (Dept:Manager relationship is 1:M), so imagine I want to hit Edit, see two dropdowns (one for dept, one for manager), and I want to change the Dept dropdown to "Sales" and then that will cause the Manager dropdown to change to just "SalesBoss1" and "SalesBoss2" options, and then I want to pick "SalesBoss2" - i.e. changing the first dropdown filters the list of the second

Are there any examples floating around that do this that I can use for inspiration?

[stsrki]

Unfortunately, I don't think there are any examples in our ticket list. Maybe I need to search better, I think there was some mention about this feature...

Maybe you can try asking on Gitter(https://gitter.im/stsrki/Blazorise)?

[CaiusJard]

I've got this working and I can make the first combo filter the second by taking the unorthodox approach of disobeying the "treat the model as read only" and making SelectedValueChanged write the model parent id, which then nicely triggers a filtering in the second combo. I went this route because I saw advice to the effect of "within the edittemplate of the second combo you can't get access to the current value selected in the first combo, during an edit operation" - i.e. the first combo can be changed but its selected value is only committed to the model during update/save. As you don't leave edit mode between changing the first and changing the second there isn't normally a chance for the model to be updated and the context only carries the model item it's working from and the current cell value (not the value of a different cell)

I'm not bothered about editing the model because the model handles the memory of "old" and "new" data (like a System.Data.DataRow class would - it knows the original and the current value and if told to cancel/rejectchanges it sets the current back to the original)

It means my combo columns are:

    <DataGridSelectColumn TItem="DepartmentManager" Field="DepartmentId" Caption="Department" Editable="true">
        <DisplayTemplate>
            @(FormData.Departments.Find(d => d.DeptId== (context as Department)?.DepartmentId)?.DepartmentName ?? "Unknown")
        </DisplayTemplate>
        <EditTemplate>
            <Select TValue="string" SelectedValue="context.Item.DepartmentId" SelectedValueChanged="v => context.Item.DepartmentId=v">
                @foreach (var d in FormData.Departments)
                {
                    <SelectItem TValue="string" [email protected]>@d.DepartmentName</SelectItem>
                }
            </Select>
        </EditTemplate>
    </DataGridSelectColumn>

    <DataGridSelectColumn TItem="DepartmentManager" Field="ManagerId" Caption="Manager" Editable="true" >
        <DisplayTemplate>
            @(FormData.Managers.Find(m => m.ManagerId== (context as DepartmentManager)?.ManagerId)?.ManagerName?? "Unknown")
        </DisplayTemplate>
        <EditTemplate>
            <Select TValue="string" SelectedValue="context.Item.ManagerId" SelectedValueChanged="v => context.Item.ManagerId = v">
                @{
                    
                    var dm = context.Item as DepartmentManager;

                    foreach (var x in FormData.Managers.Where(y => y.DepartmentId == dm.DepartmentId)) //fill combo with only managers of dept X
                    {
                        <SelectItem TValue="string" Value="x.ManagerId">@x.ManagerName</SelectItem>
                    }
                }
            </Select>
        </EditTemplate>
    </DataGridSelectColumn>

The model handles old and new values:

    public class DepartmentManager
    {
        private readonly string[] _originalValues = new string[2];
        private readonly string[] _currentValues = new string[2];

        //get always returns current. Original is initially set but then never changs unless Accept is called
        public string DepartmentId { get => _currentValues[0]; set{ _currentValues[0] = value; _originalValues[0] ??= value; } }
        public string ManagerId { get => _currentValues[1]; set { _currentValues[1] = value; _originalValues[1] ??= value; } }

        //copies original values to current
        public void RejectChanges()
        {
            Array.Copy(_originalValues, _currentValues, 2);
        }

        //copies current to original
        public void AcceptChanges()
        {
            Array.Copy(_currentValues, _originalValues, 2);
        }
    }

So it means if I want to update, i can use the model like normal (it returns the updated values) and if I hit cancel i can revert the model line

    <CancelCommandTemplate>
        <Button Color="Color.Secondary" Clicked="@(() => { context.Item.RejectChanges(); return context.Clicked.InvokeAsync(); })">Cancel</Button>
    </CancelCommandTemplate>

This last part was the biggest nuisance; there isn't any event fired when Cancel is clicked unlike when Update is clicked.. I guess because DG handles the cancelling internally, fetching the original values back from the model and overwriting the cells with them. This seemed to be a reasonable way to break into the process

So, are there any flaws with the approach or things I need to watch out for?

[stsrki]

At first I saw that you're chaging the model directly but since you have the custom logic inside of it I think you're good. It is not an easy task on its own, and especially in DataGrid. So I think you did well. I don't see any major issue.

[CaiusJard]

The only slight problem i hit with this, mentioning now for future readers' benefit, is that if the user clicks Edit on another row while theyre in edit mode on this row, the grid internally just tosses out the value dictionary for this row and starts editing the other row - but there isn't any indication to the model that the current editing row has changed.

This meant I was ending up with a model whose values were edited, but then no Save or Cancel had occurred to commit or reject them - the grid looked changed (as if they'd hit save) but if the user refreshed, all their edits were lost (confusingly different to the save process).

To resolve it I modified the Edit button click handler so it compares the row-just-hit-edit-on to a remembered variable of the previous row-that-was-hit-edit-on and if they were different, the previous row was saved (I wanted hitting edit on a new row to save the previous row) then the current row was remembered into the "previous" variable:

<EditCommandTemplate>
  <Button Color="Color.Primary" Clicked="async _ => { await HandleUnsavedChangesAsync(context.Item); await context.Clicked.InvokeAsync(); }" ><FAIcon Name="FontAwesomeIcons.Edit" /></Button>

And the relevant code for handling unsaved changes:

        private DepartmentManager _previouslyEditingItem;
        private async Task HandleUnsavedChangesAsync(DepartmentMnaager model)
        {
            if (_previouslyEditingItem?.HasChanges ?? false) //haschanges returns true if there is any diff between the _original and _current value arrays
            {
                _previouslyEditingItem.AnyOtherChangesNeeded = blah blah blah;
                await Db.UpdateDepartmentManagerAsync(_previouslyEditingItem).ConfigureAwait(false);
            }

            _previouslyEditingItem = model; //remember current row we just hit edit on for next time
        }

Note: Save and Cancel would set _previouslyEditingItem to null