The EditorDriver binds your model to "editors"; it has to know those editors, all of them, at compile-time.
There are different ways to use it: 1. "hide" it as an implementation detail in your view; this means the view is not as "dumb" as it could be (it would expose edit() and flush() methods) 2. expose all the editors from your view, so you can create the EditorDriver using the view interface (not widgets, only LeafValueEditor<String> and the like; this means you have to create interfaces for all your "complex editors", as Editor<ModelObject> is not enough: the EditorDriver wouldn't now that there's a LeafValueEditor<String> for the "foo" property of ModelObject, for instance) 3. create the driver in the view (so it can deal with the widgets, and the presenter doesn't have to know which property is edited, and more importantly in which way it is edited –there are cases where you need 2 editors for the same property for instance–) and give it to the presenter (as an EditorDriver<ModelObject, ?>, the presenter doesn't need to know the second type argument) so it can call edit(), flush(), setConstraintViolations(), etc. In the first and second case, we can say it doesn't "break MVP", but it changes the way the presenter deals with the view, and/or the responsibilities of each tier (one could say the first case "breaks MVP", because it gives the view too much responsibility and too much knowledge of the model) In the third case (this is the one I'm using, FWIW), having an object shared between the view and the presenter blurs the line between them and their responsibilities. Moreover, that object dealing directly with the model (update the view from the model values, and then update the model from the view) could be seen as a kind of presenter, which means your view knows the "internals" of its presenter (it creates the EditorDriver), and your presenter deals with the view (partly) through another object. Finally, there are things you can do from within an Editor (EditorDelegate#setDirty, EditorDelegate#reportError, switching to a read-only state when the RequestContext is 'null' (when implementing HasRequestContext and using the RequestFactoryEditorDriver), etc.) which blurs the line even more: your view (because most of these things will be done in widgets implementing Editor) "does" things that are more the responsibility of the presenter. You could probably abstractize those things using some kind of MVP at the Editor level, but that would complicate your code for a very small added-value (IMO) and wouldn't actually change much things "conceptually speaking". Final word: you're thinking too much, try to be more pragmatic (it's not easy, I know it so well, but it really pays off) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/4PmTe5nYVZUJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
