This is perhaps the biggest thing I haven’t solved to my liking. I often need to have a non-editable layout that looks the same as the editable layout (as much as possible). I don’t want to manage two different FormLayouts. I just want to toggle editability.
Therefore, the “non-editable” version of a component like a TextField should behave more like a Label (…). I should not have to do anything to a Date field, it should not show the date selector, etc. Multi-selects should show up like a list of items, and so on.
I have yet to find a good recipe for handling these – I’ve had to resort to form field generation and table cell generation, but what about situations where this late binding is not available ?
hi,
nice idea,
I am looking for something like that also.
I want a label (or an disable text field that looks like a label) that will be changed to be a text field when user clicks on it to edit, after that it will become a text field again.
Do you have any idea on how to achieve that?
Perhaps, I am little bit late with response, but I think you can use “readOnly” attribute of any component to make it not-editable.
There is a trick you have to be aware of regarding “readOnly”. Once you set component to be readOnly, you won’t be able to change/set it’s value. So, you have to make sure to set value before setting readOnly=true.
This is something I never really understood the purpose of it. Based on the Vaadin team, setting readOnly supposed to prevent from other client to change the value. But isn’t “final” keyword in Java exactly for it?
Also, is there any other way to make TextField readOnly and then set it’s value?
I think, this is something that would be very helpful as usual flow is to created UI template with all components and then set all values. Not the other way around.
You should be able to change field to not be read-only, set its value, then set it back to read-only.
I do think there’s something odd about read-only (for the user at a browser) also keeping the server code from making changes, though. I mean, the server can do whatever it wants (including the trick above, albeit with more coding) so I’m not sure why they are protecting the developer from changing a widget’s value just because we’ve marked it as read-only for the user at the browser.
I think here is the confusion: In Swing, the read-only attribute is an attribute of the presentation layer, where read-only means that the user cannot modify the value of a JComponent through the UI, while the UI code can still freely update the value of the widget.
With Vaadin, its MVC implementation separates the data model (ObjectProperty) from its presentation (Component), and that the read-only attribute ends up being on the data model side. That prevents both the UI and back end from updating a read only attribute.
It is what it is. I wrote a utility method to to set/unset the read-only attribute to reduce code clutter
/**
* <em>Force</em> set a value into an {@link ObjectProperty} and ignore readOnly state
*/
public static <T> void setValue(ObjectProperty<T> property, T newValue) {
if (! property.isReadOnly()) {
property.setValue(newValue);
return;
}
try {
property.setReadOnly(false);
property.setValue(newValue);
}
finally {
property.setReadOnly(true);
}
}
If field is binded withs some bean, which has no properly setted setters, than field is automatically readonly. To check this behavior - comment the binding (bind method) and try if field is now writable.
Thanks Petr, this answer was helpful and it worked out well meaning my (now non-editable) UI TextField showed up the same fashion as an editable TextField but it was locked for editing its text in UI.
Strangely enough, this behavior couldn’t be gained with either adding the “readonly” attribute in the TextField’s definition in the underlying html design file as well as in programmatically setting “fooTextField.setReadOnly(true)”. The TextField remained editable, it could be entered with edit cursor and its visual content could be altered (didn’t test if changes would have been saved to linked bean field).
I wonder what may be the reason for that behavior… could it have sth to do with style sheets?
Testing on the multimodule example of Vaadin 7.6.2.
/**
* Updates de level to be edited.
*
* @param level
* level to be edited.
*/
public void setLevel(LevelVO level) {
this.level = level;
BeanFieldGroup.bindFieldsUnbuffered(level, this);
id.setReadOnly(true); // Undo bind side effect.
}