Question

GWT’s Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.

However I am not entirely sure what the best practice is for doing inline edits.

Let’s assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.

The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.

In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.

When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).

When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.

I am not sure if this is the best approach. If not what’s the recommended approach for doing inline edits? What’s the best way to do unit-testing on the Editors?

Answer 1

If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.

What we did in our app, where we couldn’t afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we’re in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver’s display() method was used, so we’re in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).