I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
Not in GWT, no.
There's one Presenter (or Controller) for the whole app.
And then there's an MVP triad for every view.
The app controller would then for instance listen to navigation events and be responsible for displaying the view matching the nav
event.
It would do that by creating a presenter and view instance, passing the view to
the presenter, e.g.
var p:HomePresenter = new HomePresenter(new HomeView());
// you could store "p" for later use, so to only create the presenter
(+view) once
The presenter's constructor argument is an interface:
public function HomePresenter(view:IHomeView) {}
By using a presenter and view interface, you're able to have very dumb views, swap them out, as long as they implement the required
interface.
This also allows for easier unit testing, in GWT even without the view
implementations at all.
=================================================================
@Ross:
I also loathe Interfaces.
the only time i use interfaces is to allow objects with two different class
lineages to be used interchangeably.
That's the whole point of the view interface and why I brought it up, as you can then swap views and your presenter is none the
wiser.
I admit, interfaces aren't used very often in Actionscript, in Java however, 99% of the time you're programming against interfaces
or abstract classes.
==================================================================
Anyway.. hope I'm not confusing people who are just getting into the whole
design pattern thing too much.
If you like reading, google:
mvc vs mvp vs mvvm
MVVM: http://en.wikipedia.org/wiki/Model_View_ViewModel
Martin Fowler on PresentationModel:
http://martinfowler.com/eaaDev/PresentationModel.html
regards,
Muzak
----- Original Message -----
From: "Paul Andrews" <p...@ipauland.com>
To: "Flash Coders List" <flashcoders@chattyfig.figleaf.com>
Sent: Monday, March 05, 2012 5:00 PM
Subject: Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional views being added or removed, requires that the controller
be changed too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than a
Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
================================
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
================================
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only its
interface.
regards,
Muzak
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
