It would be great if the controls supported arbitrary attributes. Similar to how it is done in the native form editing controls in Blazor framework.
ASP.NET Core Blazor forms and validation
"All of the input components, including EditForm, support arbitrary attributes. Any attribute that doesn't match a component parameter is added to the rendered HTML element."
Dimo,
Multiple open source blazor libraries are capable of doing this and you guys support it in your other libraries.
Data- is a common usage.HTML data-* Attribute (w3schools.com)
Yes I have only used support once because I have been very satisfied in your OTHER libraries.
I have read the other thread and my opinion is let me weigh the cost of its usage.
Hello Lou,
I agree that attribute spatting can provide flexibility in certain scenarios. I am also sorry if our components are giving you a hard time by not having this feature.
Here is a recent forum thread that describes one more point of view for our decision to not support attribute splatting. See Joana's last comment from March 3. In short, it boils down to performance, clean API and source code, and parameter conflict avoidance.
On a side note, I see that you have used our support service only once in the last 3+ years. If you ever hit a roadblock, consider checking with us - we may be able to help you.
Regards,
Dimo
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
This is the reason why i will be heavily pushing away from your tools moving forward. You do it in the jQuery and angular as well
Your opinions are really getting in the way of how we build. I dont get why you wont support this until i was told to check out your testing solution so Great will skip on that...
Mudblazor the opensource UI kit does this outta the box
Hello Josep,
Said shortly - the status of the item is "Declined" which means we will not implement arbitrary attributes (attribute splatting). You can find a legend of the statuses here: https://feedback.telerik.com/blazor/status-info
The password type of the textbox will be implemented through the other item I linked: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. I've added your Vote for it and you can click the Follow button to get email notifications.
MaxLength is a validation that is up to a form and is already available: https://docs.telerik.com/blazor-ui/common-features/input-validation. If you want to implement custom logic without a form, the TextBox events will let you receive the user input, check its length or other specifics and either alter it, or avoid setting it to the model field altogether.
Using our component in a custom (wrapping) component does not necessarily require an expression or an EditContext, it depends on the implementation. For example, exposing a Value+ValueChanged EventCallback from your custom component will let you do two-way binding directly in a form. Adding layers of wrapping will always bring some extra complexity, this would happen if you want to wrap a simple <input /> in a custom component - you'd have to take care of some plumbing.
Regards,
Marin Bratanov
Progress Telerik
Hi Marin,
they are news about this? Some comments to your last post:
"What is the goal of having arbitrary attributes rendered in the DOM?"
Self explanatory with this two samples:
I mean, how can I write an input password text box with password behavior ( save to password manager, etc ) with Telerik TextBox ?
"I could suggest you implement your own custom attribute rendering in a component for its wrapping element, and inside that element you could use our components as with a regular component"
How to add maxlenght parameter to a Telerik TextBox wrapped in a custom component?
Also, to use a TelerikTextBox inside a custom component means to deal with EditContext, I can do it via [Parameter] public Expression<Func<string>> but is weird.
Hello everyone,
The requests for this have so far centered around features in the <TelerikTextBox>. This is something we will do with dedicated parameters in the following item: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. The few requests for features on the button are available too (class, type, enabled).
For more complex components, such a feature does not make sense as it is ambiguous and undefined. At the same time, attribute splatting has a performance cost that we should not ignore.
Ultimately, this is a feature suitable for direct HTML handling, but not suitable for a component vendor like us.
With all that said, this feature is now marked as "declined" and we will not be implementing it.
Regards,
Marin Bratanov
Progress Telerik
Hi all,
As a first enhancement in this regard, our 2.8.0 release will provide Id parameters for all input type components (Textbox, NumericTexbox, DropDownList, and so on) so you can easily attach labels to them (<label for="theIdParamString">lorem ipsum</label>).
Regards,
Marin Bratanov
Progress Telerik
Hello,
If you click the Follow button at the top of the page, you will get email notifications when there is an update on this task.
Regards,
Marin Bratanov
Progress Telerik
Attribute splatting/arbitrary attributes must be implemented explicitly in a component in order to work. We don't know yet how/if this will be done in our components. The MSDN sample has very simple markup - just one tag. In our case, we have a much more complex HTML structure, and some attributes will need to go one one element, others - to another. Considering this, we will need to collect more feedback and consider this in detail before jumping to a decision.
I have just found the following feature that will ship with Preview 7: https://github.com/aspnet/AspNetCore/issues/5071 which may allow such arbitrary attributes without any need for implementation on our side. We should wait to see and evaluate its behavior when it ships, so we can determine whether it will make sense for some/all components, or we would have to implement some of those attribute explicitly. Until then, I am keeping this item on "under review" because we can't say for the time being what the approach will be. Perhaps you would be able to define those attributes immediately, or perhaps we would have to implement Parameters for them in the end.
Maybe for complex controls, such as Grid, DropDownList, arbitrary attributes are not so relevant.
In my case, I needed the "form" attribute for the submit button, which is outside the form. In the EditForm control, I can to add an arbitrary attribute "id", but in TelerikButton I could not add an arbitrary attribute "form". So, as workaround, I had to use the HTML <button> with the styles generated by TelerikButton.
Arbitrary attributes can be useful in other cases, for example, the "autofocus" attribute on editing elements. Also in the TelerikDropDownList "id" attribute would be useful so that you can use <label for>.
The components from the article map directly to one DOM element, and as such their rendering is extremely simplified. Our components, on the other hand, have a much more complex structure in the DOM and arbitrary attributes are ambiguous - some make sense for the wrapping element (like something like data-*, however bad a practice that would be in Blazor), others make sense for an actual <input> (like autocomplete, type); and yet others would probably be even more difficult to determine for more complex components.
I suspect this is the reason that, at least for the time being, such a built-in feature of a Blazor component is not really offered out of the box by the framework, but is left for custom implementation through SetParameters in each individual component: https://github.com/aspnet/Blazor/issues/735. This implies that the component needs to know how to map each arbitrary attribute to the DOM (which is, obviously, relatively easy for single-element components like the native validation components).
So, while we could theoretically rewrite our code to adopt a similar approach, how should we know where to render each attribute the developer provides - we don't have control over your application code to know what attributes may come in and what sense they make, and you don't have control over our components code to determine rendering?
That said, I think that the most important questions is - What is the goal of having arbitrary attributes rendered in the DOM? An actual component feature would require a real, targetted Parameter so it would not be arbitrary anymore. We should also consider that you are not advised to tamper with the DOM in Blazor because the framework does the DOM changes.
For the time being I could suggest you implement your own custom attribute rendering in a component for its wrapping element, and inside that element you could use our components as with a regular component. Would this let you render the desired content in the DOM and still use our tools?
All that sid, I can suggest you Follow and perhaps add your Vote for this other feature request where the common input attributes are to be exposed: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. At the moment, I can't really think of another component that needs such attributes.