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
ValueBoxEditorDecorator
s 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?
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).