Completed
Last Updated: 26 Jun 2021 15:29 by ADMIN
Release 2.15.0
Arty
Created on: 03 Jul 2019 15:55
Category: TextBox
Type: Feature Request
44
Add to TelerikTextBox more parameters, such as: Type, Autocomplete, Required, ReadOnly
Type needed for Password set
28 comments
ADMIN
Marin Bratanov
Posted on: 26 Jun 2021 15:29

Hello Dale,

You can Follow the implementation of this capability here: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. The page also contains a workaround you can try. I believe you have found it already as I see your Vote there, which raises its priority for us.

Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Dale
Posted on: 26 Jun 2021 01:17
I understand the reasoning behind not having a read only attribute... The downside to using Enabled field is when disabling the textbox it also removes the ability to still copy the text from that field. Is there a better way of handling this?
ADMIN
Marin Bratanov
Posted on: 12 Apr 2021 06:20

Hi Seth,

The ability to copy from disabled inputs will be implemented through this item: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. Whether it will be a new setting, whether it will not require any configuration at all and will just "work", or it will come, after all, through a ReadOnly parameter will be decided when the appropriate research has been implemented. I have also added your Vote to it on your behalf which raises its priority.

As for reasons why a readonly HTML attribute makes no sense for Blazor - you can see what it does here: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly. Here are the behaviors that make it unsuitable for Blazor:

  • For one, it is not supported for checkboxes, radio buttons and select type elements which will create a disparity in a component suite (today's apps use at least 3 or 4 different type of selects so effectively half the editors won't have such a feature).
  • Secondly, its default UX is sub-par - there is no difference between a readonly input and a writable input, which is a disservice to the end user and makes them feel like the app is broken.
  • Thirdly, it is supposed to stop validation - this is not possible in Blazor because the framework validation works with the model field, not with the DOM element. You cannot have conditional rules there, unless you write complex custom validation attributes that take into account extra fields in the model that describe the readonly state. You can see how this can become a serious mess quickly.

Generally, a Blazor app would have its backend decoupled from the component, and if fields need to be shown to the user but not edited, there are two approaches (that can even be combined):

  • render different UI for such fields - for example, render them as text instead of as inputs based on the same flag that you would otherwise use to set readonly. A plain if-block can let you render different UI in Blazor, which can be a single line of code.
    • Using disabled inputs is a valid way to let your users know they can't edit this input for some reason. A readonly field is confusing because it looks like it is ediable but it is not.
  • avoid updating such fields in the backend - they would otherwise be part of a POST query anyway, and such queries can be forged, so a backend cannot trust user input anyway. Therefore, the backend must know about such fields and prevent them from being updated with its own safety logic.
    • a Blazor form does not submit on its own to an endpoint. It provides a pair of C# events that provide you with the model. Then, it is up to the application logic to use that data and perform the HTTP request. This means that the application can perform necessary checks, add metadata to the model or otherwise alter it before it makes a POST, based on the same flags that you would otherwise use for the UI. If you do want to make a POST, you have full control over what data you send (including metadata if you so wish), and you could have used any of the approaches above to show that to the user.

With all that said, there is one single benefit from having a readonly attribute - the ability to select and copy the contents. This can be achieved by rendering text instead of input with a simple if-block at the moment. The item linked at the top will allow it for Disabled inputs in the Telerik suite.

Regards,
Marin Bratanov
Progress Telerik

Тhe web is about to get a bit better! 

The Progress Hack-For-Good Challenge has started. Learn how to enter and make the web a worthier place: https://progress-worthyweb.devpost.com.

Seth
Posted on: 11 Apr 2021 17:49

https://stackoverflow.com/questions/3089252/what-is-the-main-difference-between-readonly-and-enabled

I completely agree with Ian. Many of us are migrating existing applications, in our case WPF, to Blazor environment and don't have the freedom to dictate control behavior based on underlying framework design patterns or concepts. Rationalizing application behavior changes to end users based on programming concepts is a no win scenario, at least for us.

I realize the reference I posted is for WinForm behavior, but it is a common pattern in web applications as well.

Perhaps you can post your reference for best practices and we can avoid much of this back and forth and/or waiting for functionality that may not ever be implemented.

Regards.

 

ADMIN
Marin Bratanov
Posted on: 11 Apr 2021 10:44

Hello Ian,

You can Follow the ability to copy from disabled inputs here: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. I've added your Vote to it to raise its priority.

Azure's settings are not a Blazor app, and a Blazor app does not rely on POST requests from a <form>. Thus, readonly for inputs there does not tie well with the framework concepts. If that turns out to be the way to allow copying, it might get added for that reason, but that will be subject to research on that particular feature. It is imperative for our components to follow the best practices for the framework and readonly is not part of that.

Regards,
Marin Bratanov
Progress Telerik

Тhe web is about to get a bit better! 

The Progress Hack-For-Good Challenge has started. Learn how to enter and make the web a worthier place: https://progress-worthyweb.devpost.com.

Ian
Posted on: 11 Apr 2021 09:59

Hi Marin, 

I'm afraid I can't agree with you there. UX design is subjective and if a layout works well for users then it will, by definition, be good design.

Readonly is used in many situations, including providing users with a field which can be copied. Microsoft uses this a lot in Azure where the system generates information - API keys, URIs - and you need to be able to copy them. 

Best,
Ian

ADMIN
Marin Bratanov
Posted on: 08 Apr 2021 13:20

Hi Ian,

The HTML tag has the need for such an attribute, but a Blazor component does not. A Blazor form is not supposed to do a POST on its own in the first place, this should go through a service and the service should decide what to send, where to send it and how to send it.

Thus, the Enabled parameter of the Telerik Blazor Textbox serves the purpose of letting it show a value to the user, but not letting them edit it. It even showcases that the input is disabled, which is not something the readonly attribute does - and thus the Telerik component improves the UX immensely over the standard readonly attribute.

Thus, I cannot agree that a Readonly attribute is an enhancement - it has bad UX by default, and it is not used by Blazor. At the same time, we have an alternative that serves the Blazor purpose and provides a better UX - the Enabled parameter.

Regards,
Marin Bratanov
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.

Ian
Posted on: 08 Apr 2021 13:13

I understand the example below, however it's very kludgy to have to do that when a single boolean value would suffice. I'm in the process of testing Telerik Blazor as the competing product I currently use has a lot of these kinds of workarounds. 

There is a very good reason that an HTML input tag has the readonly attribute, which has been explained by Smiljan.

I understand the need to avoid cluttering up the API surface, but there is also the need to avoid having to build custom components (I've made a ReadOnlyTextbox) with all the maintenance overheads that will accrue. This is, IMHO, a case where we are talking about a genuine enhancement and not a piece of bloat.

ADMIN
Marin Bratanov
Posted on: 08 Apr 2021 13:05

Hi Ian, Smiljan,

Setting the Enabled parameter of the Telerik textbox to true disables it so the user can't edit it. It also adds a grey-out effect, you can see this in its live demo.. If you want to make it stronger, you can add some CSS rules in your app to do so.

Here are a few examples of CSS rules to tackle the appearance:

 

<style>
    .k-textbox.k-state-disabled {
        background: lightgrey; /*make background darker gray to more clearly stand out as not editable*/
        opacity: 1;
    }

        .k-textbox.k-state-disabled.no-grey{
            background: white; /*or make background white like in the regular input so it is totally unclear it is not editable*/
        }
</style>

<TelerikTextBox Value="Enabled"></TelerikTextBox>
<br /><br />
<TelerikTextBox Enabled="false" Value="Disabled"></TelerikTextBox>
<br /><br />
<TelerikTextBox Enabled="false" Class="no-grey" Value="Disabled NoGrey"></TelerikTextBox>
<br /><br />
<input type="text" value="Readonly" readonly="readonly" />

 

And here is what that results in:

A "real" readonly HTML attribute does not make sense for Blazor because Blazor forms do not make a POST request by default. To send data to a service, you would handle the OnSubmit and/or OnValidSubmit event the form exposes, and send the model you get to your data service. For some cases, that service might serialize it and send it over the wire in and HTTP request (maybe to a REST api), but this is not something that is the duty of the form. Thus, the readonly attribute is not relevant to a Blazor component.

The Telerik suite of components comes with all necessary inputs, so there is no reason to mix in the standard inputs with the Telerik ones - you can use just the Telerik ones to create your forms. Our Form component can even automatically generate them for you.

Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Smiljan
Posted on: 08 Apr 2021 10:28

Hi,

I also agree that it would be really helpful if Read-only atrribute would be added.
To have some common layout expireience in form I use TextBox for all fields (read-only and input).
I currently have to use native Blazor input with readonly attribute.

The problem TelerikTextBox with readonly would solve:

- one would have same look of components (not to mix some Telerik and some native components)

- only Telerik components could be used

- if you use disabled then value is not posted in submit

- no other workarounds would be needed (just simple 'readonly' in TelerikTextBox) - simple and clean code

BR, Smiljan

Ian
Posted on: 08 Apr 2021 10:00
Regarding the ReadOnly request, it is often the case that you have a property which is read only. Typically in a sale you add an option via a checkbox and you want to see its price. When the option is not selected the price field should be disabled (greyed out), but when enabled it should be read only.
Patrick
Posted on: 31 Aug 2020 16:00
Works great, thank you.
ADMIN
Marin Bratanov
Posted on: 31 Aug 2020 15:32

Hello Patrick,

You can choose which event to bind to. With the standard HTML elements, that's the onchange event, whlie we use oninput, so you can do the same to get events on every keystroke.

Here's a basic example:

<input type="search" value="@theSearchText" @oninput="@InputHandler" />

@code{
    string theSearchText { get; set; }

    async Task InputHandler(ChangeEventArgs e)
    {
        theSearchText = e.Value.ToString();
        Console.WriteLine(theSearchText);
    }
}

 

Regards,
Marin Bratanov
Progress Telerik

Five days of Blazor, Angular, React, and Xamarin experts live-coding on twitch.tv/CodeItLive , special prizes and more, for FREE?! Register now for DevReach 2.0(20).

Patrick
Posted on: 31 Aug 2020 13:14

I want the cross icon functionality that you get with search, that's it. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search#Differences_between_search_and_text_types

I'm fine with using a normal input in place of the component, but how do I match the behavior of ValueChanged?

<TelerikTextBox ValueChanged="@(async (string s) => await QuickSearchHandler(s))" Id="pet-search" Class="form-control py-2 border-top-0 border-left-0 border-right-0 border rounded-0" Placeholder="Search by Name or Owner"></TelerikTextBox>

ADMIN
Marin Bratanov
Posted on: 31 Aug 2020 09:33

Hi Patrick,

The <TelerikTextBox> component will use an <input type="text" />. You can alter things like its autocomplete and inputtype parameters that match to the corresponding HTML attributes: https://demos.telerik.com/blazor-ui/textbox/customization. An <input type="search"> does not offer extra functionality or attributes, yet if the type attribute is important to you, you can use your own HTML element and style it through our themes: https://docs.telerik.com/blazor-ui/themes/form-elements#inputs.

 

Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Patrick
Posted on: 30 Aug 2020 23:51
Is there an update regarding the Type attribute? I am currently in need of being able to set my TelerikTextBox to a search type.
ADMIN
Marin Bratanov
Posted on: 27 Jul 2020 07:08

Hi Seth,

You can use the Enabled parameter to denote that a field cannot be edited to the user. Or, you can wrap it in an if-else block to show the values as text when they should not be editable, and only render a textbox when they should be.

If you are using a grid to insert/edit records, see here on changing the Editable parameter of a column based on a condition (such as edit or insert is being made).

 

Regards,
Marin Bratanov
Progress Telerik

Seth
Posted on: 26 Jul 2020 14:30

Hi Marin,

The most common scenario within our application is when an existing document is displayed on the page, it's primary key fields are ReadOnly. When the user is creating the document using perhaps a <New> action, the same fields are not read only as the user may want to enter / override the application assigned value. An example might be a sales order, where on new, the application assigns an order number that can be edited by the user. If the order is retrieved for editing, the order number cannot be modified but we'd like appearance to remain constant.

Our Blazor application is a rewrite of a WPF application and we'd like to adopt as many UI behaviors as possible, mainly to make it easier for our fairly large base of existing users. In our WPF app, the opacity of read only values is the same as editable values.  I acknowledge your recommendation regarding user experience.

Cheers,

Seth

ADMIN
Marin Bratanov
Posted on: 26 Jul 2020 08:21

Hi Seth,

Could you explain a Blazor scenario that requires ReadOnly and cannot be solved with Editable and/or an if-block around the textbox? We haven't been able to come up with a meaningful scenario for such a parameter and decided to leave it out to avoid clutter.

As for styling - I would recommend that you keep disabled inputs visually distinct from enabled inputs for your users so that they have a better experience.

Nevertheless, you could inspect the component and alter some CSS rules by following this blog post. Here's a sample I made for you that removes the two key settings that make up the disabled appearance.

<style>
    .k-textbox.k-state-disabled{
        filter: initial;
        opacity: 1;
    }
</style>

<TelerikTextBox @bind-Value="@EnabledTbValue" />
<br />
<br />
<TelerikTextBox @bind-Value="@DisabledTbValue" Enabled="false" />

@code{
    string EnabledTbValue { get; set; } = "first";
    string DisabledTbValue { get; set; } = "second";
}

Regards,
Marin Bratanov
Progress Telerik

Seth
Posted on: 24 Jul 2020 21:33
ReadOnly doesn't appear to be added, and I saw your reasoning. Is there a way to style the text when textbox is not enabled to match enabled textbox style?
Gilles
Posted on: 20 Mar 2020 15:00
I would say also Tooltip to be able to define the Tooltip text that would be displayed using a TelerikTooltip
ADMIN
Marin Bratanov
Posted on: 12 Feb 2020 10:29

An inputmode parameter would also be helpful. Just leaving this here for posterity in relation to this thread https://www.telerik.com/forums/support-for-inputmode-or-pattern

--Marin

ADMIN
Marin Bratanov
Posted on: 10 Feb 2020 11:31

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

 UI for Blazor
ADMIN
Marin Bratanov
Posted on: 13 Oct 2019 13:11

Hi Robert,

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

 UI for Blazor
Robert
Posted on: 13 Oct 2019 12:33
Any update on this?
ADMIN
Marin Bratanov
Posted on: 04 Oct 2019 06:35

A quick update - you can try getting a Telerik-like appearance for standard textboxes by adding the k-textbox class to them, something like this:

            <TelerikTextBox Label="Username:" />
            <br />
            <br />
            <input type="password" placeholder="Password:" class="k-textbox" />

 

Regards,
Marin Bratanov
Progress Telerik

 UI for Blazor
ADMIN
Marin Bratanov
Posted on: 04 Jul 2019 11:05
Hi again, Arty, you may want to also follow the development on this one: https://feedback.telerik.com/blazor/1416978-support-arbitrary-attributes.

Depending on what the framework starts doing, we may no longer have to implement parameters for DOM attributes. We will see, and until then I can't say what will happen with the current ones you requested.

--Marin

ADMIN
Marin Bratanov
Posted on: 04 Jul 2019 05:16
Hi Arty,

For the time being you can use Enabled instead of ReadOnly. For the others - I agree they would certainly be nice features.


Regards,
Marin Bratanov
Progress Telerik UI for Blazor