Silverstripe-framework: RFC Stop supporting multiple _Disabled / _Readonly classes

[tractorcow]

We currently support both setDisabled(true) / setReadonly(true) as well as separate class implementations for these views. This promotes inconsistent (and non-accessible) views for form fields.

I suggest to ensure that setting one (or both properties) on any form field are properly respected, and that we remove these redundant classes.

[maxime-rainville]

Off the top of my head, I would agree with @tractorcow.

However the HTML specs provides for both readonly and disabled attributes.

The main difference being that a readonly field's value will be submitted along with the rest of a form, while a disabled field's value will not.

In practice, there's no that many situations where that difference should matter. The only one I could think off is where you would like to display a value that would normally be tracked through an hidden field. e.g.: Let's say you wanted to display the ID of the record the user is editing.

[tractorcow]

However the HTML specs provides for both readonly and disabled attributes.

That's what I'm advocating for, rather than separate classes / templates to provide a different view. We should only need the html properties, not a whole new set of classes.

[maxime-rainville]

@tractorcow Cool. Sorry, I read it the wrong way around.

[tractorcow]

I just took it that you were agreeing with me. :)

[robbieaverill]

Bump this - this would also be required for PSR-2 compliance, since we use underscores in these class names as a convention.

Shall we make this RFC accepted? Myself @maxime-rainville and @tractorcow in favour of removing _Disabled and _Readonly implementations, instead using attributes (disabled/readonly) on the FormField implementation.

cc @silverstripe/core-team

[maxime-rainville]

Let it be resolved that the RFC has been accepted.

[sminnee]

Suits me. My only comment would be to deprecate, rather than delete, in 4.x for BC.

[robbieaverill]

Ok sounds good. Deprecate in 4.x and start using the correct attributes from the base FormField class to handle this behaviour - I guess we still need to use the templates from the deprecated classes until 5.x though for B/C