Editor Frame work and MVP

[Qrunk]

Hi ,

Just a general question, is it true that Editor Framework breaks MVP paradigm?? If yes please explain how ? Can we use it while using MVP Design pattern ??

Thanks in advance

[Cristian Rinaldi]

According to a report by Martin Fowler, MVP has been withdrawn as a pattern

in July 2006, and has been divided into two variants: Passive View and

Supervising Controller.

Passive View: In this pattern, the view update is exclusively managed by

the presenter to reflect the changes in the model. The view never

interacts with the model. As we can see, this definition of the behavior is

not different from what was explained in the previous paragraphs. This

involves the benefits already stated, such as centering tests in the

controller (presenter), given that the view is a light component with

almost null logic content.

Supervising Controller: Many frameworks allow for the possibility of

making a mapping between the view and the model, called data

binding (Framework Editor). This is a very efficient approach which makes it possible to

relate the model’s elements with the view’s elements through some sort

of declarative form. However, there are complex relations that require a

more complicated logic for the view.

In this pattern, the view interacts directly with the model to make a simple

data binding, which is declaratively defined without intervention of the

presenter. The presenter updates the model and handles the view state

only if the logic is complex and it cannot be expressed declaratively.

You can see this: http://martinfowler.com/eaaDev/uiArchs.html

Regars!!!

A.U.S Cristian Rinaldi Teléfono Móvil: (0342) 155 238 083 www.logikas.com Lisandro de la Torre 2643 Of 5 - 3000 - Santa Fe Teléfono Fijo: (0342) 483 5138

2012/1/19 Qrunk <kapil...@gmail.com>

Hi ,

Just a general question, is it true that Editor Framework breaks MVP paradigm?? If yes please explain how ? Can we use it while using MVP Design pattern ??

Thanks in advance

--
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/-/7gKJQmkbyKkJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

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)