FormItem with custom template can be still solved generically

[Matt]

Hi,
I am reacting to the need for unbind two system solutions for Template RenderFragment of FomItem. If I use standard FormItem, I am getting everything solved - styles, messages, label, ... However just because I need TextArea instead of standard input, the very first thing I am loosing is for in label, because for unknown reason your components have given ID and it cannot be read for that for attribute of label. After losing that standard behaviour, I am also losing error propagating and validations. I am supposed to manually retrieve error messages with TelerikValidationMessage, however for some unknown reason you've enforced Expression for FieldIdentifier and hide the possibility to set FieldIdentifier manually. So I had to derive my custom component, hide your For parameter and set it to "() => default" so it would not trigger null check exception.

Now, why all this. Because I've successfully cloned original Model with all properties and attributes with custom Assembly. I am also able to omit or include ValidationAttribute attributes - thus enabling or disabling validations. And for those templates, I've made RenderFragment<EditModel<TValue>> extension of your Template (I hate Blazor for inability to extend parameters - I had to create a new one - BindTemplate), so I was also able to cover that original model with BindValue property, which has all attributes included and it is also properly notifying EditContext if wrapped value changed - to original FieldIdentifier. So now I can have BindTemplate with not only correct typed binding for any two way binding with property, but also GetValidationMessage ony my EditModel Context, so everything within that template without need to manually do that work. It is up to you, if you want to include my project or create some other form type for that. However, it would be nice, since My system is much more robust and provides binded way for message and its property to be used within the template:

 

<AnetFormItem EditModel="() => this.Is.Your.Previous.For.Attribute">
<BindTemplate Context="model">
<TelerikTextArea @bind-value="model.BindValue">
@model.GetValidationMessage()/* No For here, it is already binded within Context model */
</BindTemplate>
</AnetFormItem>

It seems more logical to me - to derive that BindValue directly form For expression instead making programmer to bind whatever and then figure out the correct MemberExpression for the message. You could also provide RenderFragment for lable on that model and much more - that is meaning of this post ... It is also only logical as this is similar for Grid cell template ...

[Dimo]

Hello Matt,

• There is no need for a FormItem Template to use a TextArea.
• Even if you use a FormItem Template, you can still mimic the built-in label rendering and also the validation styling.
• Even if you decide to use custom label rendering, you can set the TextArea component's Id parameter to your own arbitrary value.

Regards,
Dimo
Progress Telerik

[Matt]

So, I've just figured out that yes, ID does work - however, only for the first time. That means it is no picking changes on redraw. It must be solid constant before Razor page Build. Now I am going yet again emphasise what did my solution achieved. First of all - it combined easily validation Expression with its value binding, making it actually a form item template for a single form item. Automatic binding with label is also another big benefit. I really do not want to fill my Razor page by 20 ID constants just to satisfy your label FOR when I can create that model which has binding already generically done. Since it is binding done on custom Type, I can also choose if I want validation attributes at all. I do not understand your comment at all. My model is providing this for FormItem:

Binding label
Binding value
Binding validation (include/exclude all validation attributes thus triggering/hiding validation)
Binding validation message (retrieved by For expression already used for Binding value)
Binding any other custom data

So answering that by logic that I can solve each issue individually without that model is like saying that I can write in Assembly since it is possible and therefore there is no reason for creating more complex and easier solution ... Automatic binding with Expression (For attribute) label does mean also solving Display attribute while your current solution disregard Display attribute and require another place for translation definition ...