kendo-dropdownlist, kendo-switch, kendo-numerictextbox... etc. None of them have an option to make them as readonly... 馃槥
@JohannesHoppe , we met the same limitation. It would be really handy to have a read-only mode for form components.
As a possible way forward, we use this approach:
<kendo-datepicker
[(value)]="dueDate"
*ngIf="!isReadOnly">
</kendo-datepicker>
<span class="readonly" *ngIf="isReadOnly">{{dueDate | date:'shortDate'}}</span>
It just displays the selected value as a readonly text instead of rendering a Kendo UI component.
Similar solution here. I added a big overlay over the complete form. But man, this is a silly workaround - not a solution...
Hey @JohannesHoppe , @alexeikostevich
Thanks for the feedback!
All of the components mentioned above support the [disabled] property. When set to true the components become grayed-out and no longer react to user actions. Would that work for you? What would be the difference between a disabled and a read-only component?
Hello @tapopov ,
Thank you for looking at the issue!
[disabled] can be a replacement for [readonly] in some cases. However, there are some differences in the behaviour between these modes.
MDN docs for <textarea> can explain this better than me :)
disabledattribute indicates that the user cannot interact with the control.readonlyattribute indicates that the user cannot modify the value of the control. Unlike the disabled attribute, the readonly attribute does not prevent the user from clicking or selecting in the control.
The typical scenario for [readonly] is when a user cannot modify data but still need an ability to focus an input or copy its value to the clipboard.
Probably, this can be a bit challenging to add consistently to all Kendo UI inputs. It is worth noting that some native HTML elements (like select) do not support readonly.
Hi @alexeikostevich
After discussing the topic internally, we've decided that a readonly property would indeed fill some gaps and is a good thing to have. This is now on our to-do list.
Thanks again for your valuable input.
Thank you, @tapopov. I really appreciate your attention to the request.
Implemented in kendo-angular-dropdowns v1.5.0-dev.201712211359.
Great news! Thank you for working hard on new features!
This is an ongoing effort. I will post the related packages here to track their progress:
@ggkrustev , @tapopov , please, could you consider to add a special CSS class (like k-widget-readonly) for read-only components to let customize their default appearance?
Let me explain a use case in more detail. Our application heavily uses Kendo UI components for building forms. Due to complex business requirements, our forms can be fully editable, partially editable or fully read-only. For the sake of simplicity, we use the same form for all 3 representations just setting readonly input for non-editable components. Therefore, we would like to style them appropriately to make them visually read-only.
For instance, here is how ComboBox behaves in our app: https://plnkr.co/edit/0sEgRWBNAxwl0WXb0gko?p=preview
Unfortunately, there are no Kendo classes currently added by default to distinguish editable and read-only components.
Hi @alexeikostevich, thanks for the suggestion and for the detailed description of the specific business scenario.
Indeed, if the readonly component adds a specific class, then it won't be needed to be written manually. On the other hand, however, this additional class, e.g. k-state-readonly won't add anything additional in terms of styling (we don't have any plans for the time being). Basically, it will be an empty CSS class rendered at a root level, which still requires all additional styling to be added manually. That being said, I don't see any difficulty in adding this custom class manually too. As you've shown in the plunkr, it is just one line of code - [class.is-readonly]="readonly". The benefit here is that it is explicitly added.
IMHO, adding such class is not needed, nor it will be beneficial to most of the users, as they still need to apply completely custom styling to each component.
The best in this case will be to open a UserVoice discussion on the subject. Thus more people will be able to cast their vote for it and/or share additional thoughts on the subject, like whether we should add some readonly styling or not.
http://kendoui-feedback.telerik.com/forums/555517-kendo-ui-for-angular-feedback
Done in latest releases of the packages.
Thank you for the detailed reply and adding readonly for all awesome Kendo UI components, @ggkrustev !
I agree that not having a build-in k-state-readonly class is a minor issue and does not add much inconvenience and complexity :)
There are a few points why it is still could be helpful:
readonly and disabled states have very similar nature and should behave consistently. If disabled adds a class, it would be convenient to have the same behaviour as readonly.k-state-readonly would reflect a component state and add some semantics.k-*) instead of mixing with custom ones.However, frankly speaking, I've noticed that Angular Material does not add a class for the read-only state as well: https://angular-nctmuh.stackblitz.io/
Therefore, it looks like a really contentious issue :) Please, ignore if it these points do not fit the Kendo UI design.
this is kendo datepicker, i want it only in readonly.
>
@DhDhanesh, in that case set the [readonly]="true" attribute, like it is shown in our documentation.
https://www.telerik.com/kendo-angular-ui/components/dateinputs/datepicker/readonly-state/
Please note that the whole component will become readonly. If you would like to make only the input readonly but still enable data picking then this won't be possible.
Most helpful comment
This is an ongoing effort. I will post the related packages here to track their progress: