MVP in terms of UI and View

[Qrunk]

What does the following mean ??

GOALS in GWT Develeopment

We need dumb Views, not dumb UIs

(What does  View mean here and whats UI in MVP ?? its confusing, , please explain with a small example, a simple one) 

• Avoid state within Views

(Which state is it talking about, please explain with a small example, a simple one)

• Swap out Views for different platforms

(What is the swapping thing here?? does he means change of different technology, say from GWT to Flex )

Please exp[lain using a simple example :)

Thanks

[Ed]

Here you find all your answers:

http://martinfowler.com/eaaDev/PassiveScreen.html

- Ed 

[Drew Spencer]

I think you'll find help on the Dumb Views thing here:  http://code.google.com/webtoolkit/articles/mvp-architecture-2.html although I don't really understand it fully myself yet. It seems to be further splitting the view into two parts to avoid the view getting too 'smart'.

[Thomas Broyer]

On Monday, January 16, 2012 8:44:22 AM UTC+1, Qrunk wrote:

What does the following mean ??

GOALS in GWT Develeopment

We need dumb Views, not dumb UIs

(What does  View mean here and whats UI in MVP ?? its confusing, , please explain with a small example, a simple one) 

A "dumb view" is a view that doesn't do too much (everything's controlled by the presenter), but that doesn't mean you UI has to be "dumb" too: you can have a very complex UI, with complex logic/behavior; the thing is: put it in the presenter, let the view be as "dumb" as possible.

 

• Avoid state within Views

(Which state is it talking about, please explain with a small example, a simple one)

See answer in another thread.

 

• Swap out Views for different platforms

(What is the swapping thing here?? does he means change of different technology, say from GWT to Flex )

E.g. use a PushButton for desktop and a plain old Button (more lightweight, because "native") for mobile. That doesn't change your presentation logic (i.e. your presenter code).

[Andrew Green]

With regard to avoiding state in views, I've more or less followed this practice, but sometimes find it useful to cache re-usable DOM/Widget elements in views. In these cases, the view knows absolutely nothing about the general application state, but may keep track of a few minimal pieces of information that it can use to determine which, if any, cached Widgets it can re-use. For example, in one view I have a CellTree that I use for navigation, and the view caches CellTrees based on their root value. The activity (presenter) for that view first asks the view if it has an appropriate tree available in its cache. A new tree is created only if an appropriate one is not available.

I think this makes sense because these Widgets are very view-specific. Caching them elsewhere would mean other parts of the app would have to understand (and become in some way coupled to) view-specific code.

El 16/01/12 14:06, Thomas Broyer escribi�:

On Monday, January 16, 2012 8:44:22 AM UTC+1, Qrunk wrote:

What does the following mean�??

GOALS in GWT Develeopment

We need dumb Views, not dumb UIs

(What does �View mean here and whats UI in MVP ?? its confusing,�, please explain with a small example, a simple one)�

A "dumb view" is a view that doesn't do too much (everything's controlled by the presenter), but that doesn't mean you UI has to be "dumb" too: you can have a very complex UI, with complex logic/behavior; the thing is: put it in the presenter, let the view be as "dumb" as possible.

�

� Avoid state within Views

(Which state is it talking about, please explain with a small example, a simple one)

See answer in another thread.

�

� Swap out Views for different platforms

(What is the swapping thing here?? does he means change of different technology, say from GWT to Flex )

E.g. use a PushButton for desktop and a plain old Button (more lightweight, because "native") for mobile. That doesn't change your presentation logic (i.e. your presenter code).

--
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/-/2NL-0Y1fGkwJ.
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.