I am evaluating Wiki Engines and Wiki Farms prior to choosing one for my own personal use and for various public uses. To get additional input from experienced wiki users, and help others, I am putting the review on this wiki.
* Squeak Smalltalk does not yet support Model View Presenter * Model View Presenter was a good change to Model View Controller
An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two. -- Connelly Barnes
In **MVP**, the Presenter contains the UI business logic for the View. All invocations from the View delegate directly to the Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed. stackoverflow 
## Two primary variations
**Passive View**: The View is as dumb as possible and contains almost zero logic. A Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead, the View exposes setter properties that the Presenter uses to set the data. All state is managed in the Presenter and not the View. * Pro: maximum testability surface; clean separation of the View and Model * Con: more work (for example all the setter properties) as you are doing all the data binding yourself.
**Supervising Controller**: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case, it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc. * Pro: by leveraging data binding the amount of code is reduced. * Con: there's a less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.