Declined
Last Updated: 07 Aug 2023 11:39 by ADMIN
Jack
Created on: 29 Jul 2023 14:54
Category: UI for Blazor
Type: Bug Report
0
TelerikGrid rows bound to object type known only at runtime do not behave well in Inline or Incell edit mode

If I create a <TelerikGrid> whose Data property is set to a collection of 'object' (actual type not known at compile time, only at runtime), I can create <GridColumn> components for each property through e.g.

@{
   IEnumerable<PropertyInfo> props = GetModelType().GetProperties();
   foreach (PropertyInfo prop in props)
   {
      string propName = prop.Name;
      <GridColumn Field="@propName" ... />
   }
}
@code {
   private Type GetModelType()
   {
      Type modelType = ...; // code determines the type of model at runtime ...
      return modelType;
   }
}

This works fine if the grid's EditMode is GridEditMode.Popup. When editing a row, the popup dialog properly displays each column header and value and binds correctly.

However, this does not work if the EditMode is GridEditMode.Inline nor GridEditMode.Incell. When placing the row in edit mode, no editor control appears at all, and the value in the cell is displayed as blank.

The design of the grid component thus only works well when given a known type at compile time, or one is constrained to always use Popup edit mode due to this flaw.

In addition to a request to fix this, it would also be great if the grid could be passed a Type (a runtime type, not a class name) to use for generating columns  automatically, rather than having to resort to developers having to use reflection to generate grid columns themselves.

For instance,
<TelerikGrid T="@GetModelType()" ...> should invoke the GetModelType() method which would return a type at runtime, not necessarily known at compile time. Currently T can only be set to a hard-coded type name such as "Employee".

4 comments
ADMIN
Dimo
Posted on: 07 Aug 2023 11:39

Hello Jack,

I discussed this thread with our developers and they were very sceptical about the RuntimeType parameter. It effectively aims to circumvent existing patterns and limitations in C# to not support passing of a generic typeparam at runtime. In other words, the runtime parameter will override and defeat the purpose of the typeparam.

However, we can check if it's possible to make the inline and incell edit modes perform reflection over a data item instance, rather than the data item type itself. This will make the behavior of the three edit modes consistent. At the same time, this is more of an internal refactoring, rather than an official feature or a bug fix. We still require an explicit FieldType for the Grid columns whenever it's unknown at compile time.

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Jack
Posted on: 04 Aug 2023 12:59

I am not suggesting that the generic constraint in C# has to be somehow magically bypassed. I am merely suggesting in this case that T="object", but that you also provide a way to tell it what the actual type of the object is, at runtime, via another property such as RuntimeType="@GetModelType()"

I can code this myself, as I have tried to demonstrate by showing some code snippets in this post when I created it. Since I can do it, I know for certain that it is possible to make the grid itself be designed in a smarter way. You're dismissing this too easily.

ADMIN
Dimo
Posted on: 04 Aug 2023 07:38

Hello Jack,

Some of our public and internal Blazor components are generic components with a @typeparam. It may be tempting to provide the @typeparam at runtime...

<TelerikGrid T="@GetModelType()">

... but it's not possible in Blazor and also not in Blazor.

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Jack
Posted on: 02 Aug 2023 15:56

It turns out that in order for Incell/Inline edit mode to work currently, I also have to set the 'FieldType' property on the <GridColumn> components I create, despite the fact that it should know this based on the 'Field' property which is bound to a property of the known type.

So this is less of an issue now than when originally written.

However, it would still be ideal for the grid to be able to be given a runtime type, not just a hard-coded type name, and be able to use AutoGenerateColumns="true", rather than have developers have to write code to loop over the properties of the type and generate GridColumn components themselves. We're having to 'reinvent the wheel'.