Problem with readonlydisplay.static in forms

[mathias]

Hi, our usecase is that we want a form to look like normal text when we're just displaying values, but when the user goes into edit mode, the items becomes "form items".
This works fine with readonlydisplay set to STATIC, however there's a layout issue:

Since the formitems have no border in readonly mode, there's a visual jump when going into editmode since the border around the items become visible, adding space between the items in the form. It looks glitchy.

We've tried to work around this without much success.

One idea we had was to have the readonlydisplay set to READONLY, but setting the formitem borders to white like our background. Is this possible? I didn't find a way to change the border colors of the form in readonly mode.

Pointers would be appreciated.

[Isomorphic]

To avoid the border jump, define a transparent border or border the same as the background color, or adjust padding by the border width between the two modes.

Also, instead of using readOnly, consider just a different between focused and unfocused styling. If you switch the formItem's basic rendering on the fly, you will have a number of problems:

1. can't click in a specific spot in text to start editing there

2. drop-downs will need two clicks to open

3. can't visually tell the difference between different types of fields (eg dropdown vs normal text)

[mathias]

Hi, sorry for delay, had to update android/iphone apps...

I've been playing with this for a while, and i haven't totally made it work, so have some follow-up questions:

We're really keen to get a clean look, i.e. to have something like statictextitem look, or hide the form items borders when in 'readonly'. Then when user presses "edit", borders become visible to indicate that items can be edited.

---

None of the two approaches have been 100% so looking for some advice:

1. setting a white/invisible border when form is in readonly(false).
In the skin_settings. i can change the
$formItem_border_color: to white, but that means it's white also when editing.

Basically, i cannot find a style for when the form is in editmode(false), which i think is what i need to make it work. There is one for 'disabled' but that's different.


2. changing the statictextitem so that the form doesn't jump up and down when moving between canedit(true) and canedit(false)
I managed to add border by adding
border: 1px solid white; to the .staticTextItem. in skinStyles. However, that affects all statictextitems. Also it didn't work, since i need to manually add various paddings that the formitems have when they are editable.


So, i think that the only viable path forward is point 1 above? So my question is: Is there a way to define a specific style for the formitems when the form is in readonly mode, or do i have to do manual code to each formitem when i enter and exit editmode in the form? That's cumbersome...

[Isomorphic]

It looks as if, in trying to style the controls, you are looking solely as SASS variables. Just read the docs for FormItem styling, especially FormItemBaseStyle - the states are all distinct CSS styles, separately editable.

[mathias]

Right, found the "formitemstyling" page.

I got the height to be the same by:
1. creating a read-only style by @extend-ing the textitemstyle in the scss which applies an invisible border
2. setting the "readOnlyTextBoxStyle" to the new style and
3. setting "applyHeightToTextBox" to true in isc.FormItem.addProperties in load_skin.
Now when i switch between readonly modes the form, item heights stay similar. Great success!

---

Speaking about formitems and styling, i hope i can ask a probably pretty noobish question. When i create the formitems, i just do "new TextItem()" etc. I was trying to playing around with perhaps increasing the form widths. However:

I cannot find any "width"-related styling, neither in load_skin nor skin_styles, yet there is some default width they take, surely? I couldn't find much about form widths in those docs either.
I tried increasing the form width itself, didn't do anything. I tried increasing column widths, but that only increased the form itself again. I tried setting a formitem width to "*", but i couldn't see that improving things either.

Surely this is basic, but i would appreciate a pointer. We haven't spent much time on styling in the past (as you probably can tell).

[Isomorphic]

Width, height, positioning and clipping are not controlled via CSS, because out layout algorithms go well beyond CSS (eg adaptive width, auto-sizing, etc) - see this doc, which is linked wherever a CSS style can be specified.

You should also read the FormLayout overview, as that explains all about form item sizing, and has links to further information.

[mathias]

OK, so i 'm a little bit stuck here. As i have written in my other post, we're looking to increase the height/size of our form items to make them more spacious. You gave me tips on Canvas.resizecontrols to great success. However, this causes the readonly-formitems to not center their contents vertically.

Let me reiterate what i'm after: I want a formitem to go between 'readonly' and 'editable' in such a way that the borders are not visible when in readonly mode, but visible when editing.

The problem is that, depending on what i do, either the heights are different in the two modes, or the text isn't vertically centered in readonly-mode.

This is my setup:

1. load_skin.js:

isc.FormItem.addProperties({
    applyHeightToTextBox: true,
    readOnlyTextBoxStyle: "formReadOnly",

2. _userStyles.scss

.formReadOnly {
  @extend .textItemLite;
  border: 1px solid #ddddff;
}

3. Java code:

Canvas.resizeControls(15);
and in my form:
setReadOnlyDisplay(ReadOnlyDisplayAppearance.STATIC);

I've set the height larger, and the "invisible" border in my "readonly" style to a color so that you can see better. It is normally white.


So, my problem is that with "applyHeightToTextBox" set, the form items retain the same height, but the text is aligned at the top when in read only mode:
(readonly to the left, editable to the right as you can see)



- Now, If i set it to applyHeightToTextBox to false, the height that i set by calling resizeCanvas is ignored in readonly-mode



-And finally, if i change readOnlyDisplay to READ_ONLY, of course, the text boxes are the same, and the text is centered, but i cannot make the text box invisible, since there is no specific basestyle variant for "readonly".



So, i'm not sure what i can do here.
Is it a bug that the read-only-display STATIC ignores the resizecanvas? One could hope :) If not, i am hoping there's something i can do to sort this out, so pointers are appreciated.

[Isomorphic]

Hi Matthias,

By "resizeCanvas" did you mean resizeControls?

As far as going down this path, we previously gave a much, much better approach:

Also, instead of using readOnly, consider just a different between focused and unfocused styling. If you switch the formItem's basic rendering on the fly, you will have a number of problems:

1. can't click in a specific spot in text to start editing there

2. drop-downs will need two clicks to open

3. can't visually tell the difference between different types of fields (eg dropdown vs normal text)

To add to the above:

4. your approach would be much slower than the recommended approach

5. you will have some issues around tab navigation and accessibility (long story)

It looks like you're going to need a lot of help with CSS in order to take the approach you've decided on, which seems in all ways inferior - could you explain why you're still considering it?

[mathias]

yes i meant resizeControls.

I will answer your question in the end first. In all your examples in the showcase, your forms in a perpetual editable state. We don't want to have it this way, we want it to be clear to the user when they enters/exits an editable mode on the component. Either clicking on it or an edit button. We think it's less confusing and looks better.

This is a common solution. Jira does this, StackOverflow, Bitbucket etc. Look at Google and Apples own apps on Android/IOS. Edit buttons galore, where the forms/lists have clear transitions between view/edit, exactly like we're after. It's not an alien usecase. You have edit-buttons in these forums.

We have done this since day one with smartGWT over 10 years ago, we just want it to look better when we decided to stick with you guys and try and redo the web (which is proving harder by the day).

---

Now for your point-arguments. So, lets say we have an "edit" button where we among other things call setCanEdit(true) on the form (which is how we do it)

1. if you click edit first you can, but it is not a big deal for our app.
2. True, again not a big deal for our app.
3. True, but it does not matter when not editing. Again same in all the sites i mention above.

In summary, those three points are to us easily counterpointed by the value of clarity in going between editmodes.

4. we have had no problems with performance for 10 years and i doubt it matters at all to us.
5. No issues for us. we will only use this in forms and also again, 10 years without issues.

---

As for "a lot of help with CSS".
The only thing not working is that the text is not centered for form fields, or that the rows in the form jump up and down when switching setcanedit on the form.


I have a short example below, where the only thing i do is setting up a form with readOnlyDisplay(STATIC) and switching between form.setcanedit(true) and false. I haven't added any "readOnlyTextBoxStyle" or anything. The form rows jump up and down whether or not i set ApplyHeightToTextBox or not. This is out-of-the-box.


Wouldn't you agree that the form should not jump up and down? In your doc, the "setApplyToTextBox" is marked as an "advanced feature", but "setReadOnlyDisplay" is not.

(again, what i have done myself in trying to make the bloody form not jump around was adding a readonlydisplay style, but i then had to set the "apply height to text box" to true, which makes the text attach to the top)

I have made 2 videos of the test-case below to display the effect, with and without "applyHeightToTextBox" set. Feel free to examine.

without "applyHeightToTextBox":
https://drive.google.com/file/d/11eQ...ew?usp=sharing

with "applyHeightToTextBox":
https://drive.google.com/file/d/1zy9...ew?usp=sharing

    public void onModuleLoad() {
        Canvas.resizeControls(20);
        Layout layout = new VLayout();
        layout.setMembersMargin(10);

        DynamicForm form = new DynamicForm();
        //form.setReadOnlyTextBoxStyle("banana");
        form.setNumCols(4);
        form.setFixedColWidths(true);
        form.setWrapItemTitles(false);
        form.setReadOnlyDisplay(ReadOnlyDisplayAppearance.STATIC);
        DataSource ds = new DataSource();
        TextItem test1 = new TextItem("test1", "Text field");
        //test1.setApplyHeightToTextBox(true);
        test1.setValue("Luke Skywalker");
        TextItem test2 = new TextItem("test2", "Text2 field");
        test2.setValue("Han Solo");
        test2.setCanEdit(true);
        TextItem test3 = new TextItem("test3", "Text3 field");
        test3.setValue("Obi-Wan Kenobi");
        form.setFields(test1, test2, test3);
        form.setCanEdit(false);

        Button edit = new Button("Toggle canEdit");
        edit.addClickHandler(clickEvent -> form.setCanEdit(!form.getCanEdit()));

        layout.addMember(form);
        layout.addMember(edit);
        RootPanel.get().add(layout);
    }

[Isomorphic]

If you really want an "Edit" button, even though that's more steps for the user, that's fine - but it does mean that it's time to fire up your DOM inspector and start adjusting borders and padding everywhere, because having the readOnly rendering be a pixel-perfect zero-shift match for the live control is not something we claim that the product does, and, again, not always desirable: it's frequently useful for the read-only rendering to be more compact.

We're simply trying to point out there's a big shortcut available, via using the focused state: it will be much less work, and is more immediate for the user.

Just understand, as you go down this path, that if you struggle with CSS, we can't help, because that's not a bug!

[mathias]

Hey, thanks for quick response. I want to point out that i'm not "struggling with css" in my case above. I am using methods calls out of the box. I get it, you're not fans of edit buttons. But OK, then we know what to expect.

[Isomorphic]

The point is not that an "Edit" button is inherently bad. The point is that there is another approach which is equivalent (or arguably better) and that one happens to be easier to implement.

[mathias]

Well, i guess we have to agree to disagree on the virtues of edit buttons. Hate on them all you like, and you make some good points for sure, but they are very common.

[Isomorphic]

Yes, once again (or once again again), Edit buttons are fine.

We don't hate them.

We are telling you: you can get the equivalent functionality to an Edit button, in some ways better, and it would take less effort than it would take to build with an Edit button.

This doesn't mean we hate Edit buttons.

It means you happen to be in a position to build equivalent functionality faster, with a different approach.

We would like to stop replying now, if you could just please stop (inaccurately) saying that we are hating on Edit buttons. Thanks.

[mathias]

Hey, i apologize, i actually misread your post. I read it as "the point is that edit buttons ARE inherently bad"... :) my mistake, have a nice day.