[wallytax]

I know this is an old thread, but I actually have the same issue. I created a pragmatic solution by adding this line of CSS on top of the HTML file loading the application:

.formCell [readonly] { ... }

This works, except for SelectItem components, which don't seem to render the readonly="TRUE" attribute on the generated HTML. Not sure if this is intentionally, but I guess it isn't. ComboBoxItem components work correctly. I now created a subclass of SelectItem, overriding the getElementHTML() method:

getElementHTML: function () {
  const html = this.Super('getElementHTML', arguments);
  return this.canEdit ? html : html.replace('<DIV', '<DIV readonly="TRUE"');
}

Not sure if this is correct, but it's not handy because I need to add editorType: "MySelectItem" to fields that normally render as SelectItem. Can I "monkey patch" SelectItem or is this something that needs to be fixed in SmartClient's code?

[wallytax]

Any follow ups on this? I still have not a working option. Tricking it with CSS does not work on SelectItems.

.formCell [readonly] { background-color: #F0F0F0; } /* give read only fields a different look */

I don't seem to be able to distinguish between readonly mode or not (for SelectItems). I also tried the approach of setting formItem.setTextStyle() but then the whole form cell has a different background instead of just the field.

[Blama]

Hi Isomorphic,

thanks again for the information. I'll take that path then and comment it very clearly in my code.

Best regards
Blama

[Isomorphic]

Technically, your approach relies on details of the rendered DOM, which is always undocumented and unsupported.

If we find ourselves in the situation where we cannot use the DOM "readonly" attribute because it's broken in some browser, and instead have to implement our own equivalent of the native behavior without using that attribute, your CSS would no longer apply to the control we render.

This is pretty unlikely so it's a reasonable risk to take.

[Blama]

Tomorrow's build now automatically omits the spinner icons for readOnlyAppearance:"static" SpinnerItems.

I forgot: Thanks for fixing this one!

[Blama]

Ok, thank you.
I'd have to do this for every FormItem instance on readOnly/readWrite change then, correct?

Is there a reason I shouldn't use the CSS approach I showed for TextAreaItem from your point of view?

Best regards
Blama

[Isomorphic]

Right, as we covered, the framework does not provide a distinct style series for readOnly fields, in part because there is no web-wide design consensus on how a readOnly field should appear.

We're considering providing a distinct style series in the future, but for now, you would need to call setTextBoxStyle() (or modify appearance in some other way, such as setTitleStyle()) to specially style readOnly fields.

[Blama]

Hi Isomorphic

We meant that you have all the normal styling APIs available to you to style your readOnly fields, such as formItem.textBoxStyle.

As far as this approach, it seems like this would make readOnly TextItems render as disabled, preventing copy and paste, so that seems like a bad idea.

The problem here is that FormItemBaseStyle defines no suffix for readOnly / canEdit: false (which would be a major change, I suppose).
I'd always have to use

formItemInstance.setCanEdit(false);
formItemInstance.setTextBoxStyle("mystyle");

when I enter read-only mode and

formItemInstance.setCanEdit(true);
formItemInstance.setTextBoxStyle(itemDefaultStyleString);

when I enter normal mode. Usage of just dynamicForm.setCanEdit(false) is not possible as I see it.

The non-c&p-capability of all FormItems (besides TextAreaItem) you mention is true, but I did not get complaints here, so far. I got complaints for the non-scrollable TextAreaItem, which I solved.
I'll check if my elementtype[readonly="TRUE"]-CSS rule would also target TextItems and its childs and perhaps solve it that way (I am only changing the text color).
Or am I missing something regarding your formItem.textBoxStyle suggestion?

Best regards
Blama

[Isomorphic]

Tomorrow's build now automatically omits the spinner icons for readOnlyAppearance:"static" SpinnerItems.

[Isomorphic]

We meant that you have all the normal styling APIs available to you to style your readOnly fields, such as formItem.textBoxStyle.

As far as this approach, it seems like this would make readOnly TextItems render as disabled, preventing copy and paste, so that seems like a bad idea.

[Blama]

Hi Isomorphic,

I was able to solve it like this:
Java:

DynamicForm df = new DynamicForm() {
	{
		setReadOnlyDisplay(ReadOnlyDisplayAppearance.DISABLED);
	}
};
DynamicForm.setDefaultProperties(df);

TextAreaItem tai = new TextAreaItem() {
	{
		setReadOnlyDisplay(ReadOnlyDisplayAppearance.READONLY);
	}
};
TextAreaItem.setDefaultProperties(tai);

skin_styles.css:

textarea[readonly="TRUE"] {
	color: rgb(172, 168, 153);
}

This way I can scroll in readOnly TextAreaItems, while still having the appearance of disabled, like for the rest of the FormItems.
The scrolling was the most important point in this thread for me.

This seems like a little hack to me, but it should not interfere with anything, should it? If not then I'm all good.

Best regards
Blama

[Blama]

Hi Isomorphic,

not as simple as I thought. readOnly-FormItems with ReadOnlyDisplayAppearance.READONLY have no special readOnly-CSS suffix.

What do you mean by

At the moment we are leaving the decision up to the application developer, but we may provide a default appearance difference in the future, or perhaps an optional one.

?
Do I have more options than sticking with either of the default ReadOnlyDisplayAppearance?

Best regards
Blama

[Blama]

Hi Isomorphic,

thanks for explaining. You are right, there are different ways of visually marking readOnly items. I'll go for the default readOnlyAppearance:"readOnly" then and modify the text color via CSS myself. Shouldn't be too difficult.

Best regards
Blama

[Isomorphic]

One item we forgot to address - we agree spinner controls should not show up in "static" mode (you circled this with a 3) and we'll change that.

[Isomorphic]

We agree that the default appearance for canEdit:false fields (readOnlyAppearance:"readOnly") is the most usable one and that's why it's the default.

We've already covered why the other modes can't be improved (native limitations).

As far as how readOnly controls should appear: opinions vary. A drawback of making them look similar to disabled controls, or even making the color fainter in any way, is that end users will assume that means the control is disabled and will not attempt clipboard copy or scrolling.

As far as other ways of calling out readOnly fields as special, we've seen some apps with no appearance difference for readOnly fields, some using a distinct appearance for titles, some using trailing text (like our formItem.hints), some using a distinct background color for the input itself or its surrounds...

At the moment we are leaving the decision up to the application developer, but we may provide a default appearance difference in the future, or perhaps an optional one.

About the "Start as disabled" checkbox: this was an internal testing option never meant to be exposed. It won't be reintroduced because it's mysterious to a new user just arriving to browse examples.