prevent calendar showing if readonly attribute is present on the input

[b1ade68]

Prerequisites

• [X] I have searched for duplicate or closed feature requests.
• [X] I have read the contributing guidelines.

Proposal

Software prevents opening the calendar if disabled attribute is present on the input. Why not also for readonly?

It is a simple change (perhaps). in tempus-dominus.ts we can change the function _toggleClickEvent :

private _toggleClickEvent = () => {
    if ((this.optionsStore.element as any)?.disabled || this.optionsStore.input?.disabled || this.optionsStore.input?.readOnly) return
    this.toggle();
  };

Motivation and context

Readonly input shuld not be changed.

[Eonasdan]

In other versions, this has been a bit of a back and forth with users. In some cases, people want it to behave as you have suggested, in other cases people want to disable the input field so that their end users are forced to use the picker and not manually typing.

[Antal1609]

Can confirm. We force users to use the picker by setting the input to readonly.

[vt-cloud]

I agree with @Antal1609 we also use the readonly attribute to force users to enter a date via the picker.

Ultimately the textbox is still readonly to the user, as it can only be updated via code.

A big advantage of this method is that the styling of the textbox remains unchanged for readonly elements in many UI frameworks so the user is still invited to click the box, whereas disabled elements look different.

[axunonb]

@Antal1609 comments on a use case, where the value of the the element should be editable (with the widget) and submitted to the server. But what if submitting is required, but editing not wanted. Currently, this is a pain to implement, if the date element is editable with the keyboard and the widget. As per definition readonly is meant to make an element not mutable by the user (no matter how). So I think the default behavior should be that readonly target elements are not editable. Enable overriding readonly with a corresponding setting or parameter is still appreciated.

[itajackass]

Any update to restore "readonly" to its "meaning"?

[vt-cloud]

Please see this announcement: #2694

From the sample code provided in issue #2912 I personally feel that the control is behaving as expected. I would suggest that if the readonly attribute on a text box affected separate and distinct elements outside of that textbox it could lead to confusion and unexpected behaviour.

Whilst there are probably many methods to achieve the functionality that you describe in issue #2912, I have found that instead of using data attributes, attaching a 'click' event handler to the 'button' and triggering display (or not) of the widget based on the status of the readonly attribute of the text input to be the simplest.

[weha]

@vt-cloud I mean, why was ignoreReadonly parameter removed? That way both sides can benefit.

I can't use disable because it removes the input value from the serializeObject so I have to use readonly to have it in there but the user may not change it themselves depending on what they are entering.

Sad about the announcement, I searched a long time for a viable library and implemented in early October... just my luck Guess I'll have to find another way.

[vt-cloud]

@vt-cloud I mean, why was ignoreReadonly parameter removed?

I have no idea, I'm not the developer. However there are at least half a dozen ways to achieve what you need and they can all be implemented with a line or two of script, here are a few suggestions:

1. As already mentioned; attach an event handler to the relevant elements that will allow/prevent display of the datepicker depending on whether the readonly attribute is present.
2. Store the date value in a hidden form element and update it when the datepicker updates, this way the date will always be serialised.
3. Just before serialising the form, enable the control(s) then disable again after saving the serialised form into a parameter.
4. Manually read the value of the datepicker on submission and add it to the serialised form object if not already present.

Options 1 and 2 are what I use depending on the situation and take just a moment to implement. Option 3 is a bit of a 'hack' in my opinion, but happens so fast that it is usually seamless and I have seen it used fairly often over the years.

I personally use two or three date picker libraries and this is still the most reliable/versatile. All the others have issues that their developers do not seem to want to fix, such as incorrect paging when the month has < 30 days or awful display of the time picker component.

[weha]

@vt-cloud well I did a hacky thing now by removing the element and adding it again without the picker as I don't see how to use option 1, which takes my preference. Nor how change / destroy an existing instance of TD, which is also an option for me. If you would be so kind to share your option one? I suppose you have to use show.td but I don't know how to stop it,

I'm no expert in javascript or typescript or whatever it is these days :)

Thank you!