Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: MVP and pureMVC differences  (Read 20423 times)
Gallo_Teo
Newbie
*
Posts: 8


View Profile Email
« on: November 06, 2008, 11:16:20 »

Hi everybody,
discussing with a friend we were talking about pureMVC. I'm using pureMVC since the le beginning of the year and he studied something about MVP smalltalk pattern. MVP pattern is used for .net application too so i decided to discover more about it

As every time i have to start with a new thing open wikipedia and i read this
http://en.wikipedia.org/wiki/Model_View_Presenter

so i thought "ok, Presenter is a new layer between controller and view... so it is the pureMVC mediator"...
i think i'm wrong because I'm reading this one http://www.wildcrest.com/Potel/Portfolio/mvp.pdf and presenter is described as controller

so please someone can explain me which are differences between the 2 patterns and why some one think MVP is so better then MVC ?


thanks
Teo


Logged
pablobandin
Newbie
*
Posts: 2


View Profile Email
« Reply #1 on: November 30, 2008, 08:28:37 »

In the MVC, the Controller has no references to the View.
In the MVP the Presenter has a reference to the view and can change it.
In PureMVC the mediator is acting like a Presenter. And the controller remains with no direct access to the view.
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #2 on: November 30, 2008, 09:35:29 »

In PureMVC the mediator is acting like a Presenter. And the controller remains with no direct access to the view.

Maybe we should call it PureMVCP ;)
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: December 01, 2008, 06:03:26 »

MVP Presenter is a code-behind class, which acts like a puppet master to a view component with no intelligence of its own. It is too 'familiar' with the view component.

Mediators are not code-behind Presenters, they are Mediators. They listen to the view component and pass its events on to the app as notifications or they take notifications that should affect thir view and pass in the data or call a method on the view component,which encapsulates its own behavior.


-=Cliff>
Logged
Gallo_Teo
Newbie
*
Posts: 8


View Profile Email
« Reply #4 on: December 01, 2008, 09:15:12 »

MVP Presenter is a code-behind class, which acts like a puppet master to a view component with no intelligence of its own. It is too 'familiar' with the view component.

-=Cliff>

Thnaks Cliff and Pablo, 
what do you mean with code behind? which are presenter's tasks? have we got advantages implementing an mvp patterns? any link is great accepted ;)

thanks for now

Teo
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: December 01, 2008, 03:35:11 »

Code behind is a way of having a component with no code in it but all in a helper class of some sort. For instance Cairngorm used to implement the ViewHelper pattern for this purpose, though I gather it has been deprecated.

In Flex you could define your MXML component with no script block or methods of its own, merely components. Then you'd have a ViewHelper that would store all the logic for manipulating that view.

For instance, if the Report view component had custom sub-component called gridView which a DataGrid called reportGrid, the ReportViewHelper would happily manipulate report.gridView.reportGrid.selectedItem.

But PureMVC doesn't advocate code-behind in Mediators, though you could certainly do it if it's your style.

Rather, the best practice is to encapsulate the behavior and composition of the view component by exposing a top-level API of properties, methods and events that hide the implementation details from the Mediator, whose primary job should be message mediation. The view component should be able to take values set by a Mediator and use them to populate controls, as well as reflect changes to controls in the top-level values, so that the Mediator doesn't need deep knowledge to access them. It should be able to manage its visual state / behavior with a minimum of input from the Mediator.

This makes the component more portable and it is easier to refactor its implementation details without breaking existing functionality.

-=Cliff>
Logged
Gallo_Teo
Newbie
*
Posts: 8


View Profile Email
« Reply #6 on: December 06, 2008, 10:46:54 »

thanks, very good example :)
Logged
shauno


Email
« Reply #7 on: February 08, 2009, 04:56:31 »

Hello Application Architects!

The differences between a Mediator and a Presenter are fairly straight forward I think: With a Presenter, the View component is completely dumb - application routing and presentation logic is managed entirely by the Presenter. With a Mediator, the View component manages its own state and presentation logic, and exposes an API to its Mediator for manipulation.

Using a Presenter generally couples the View component and Presenter, which, I assume, is why PureMVC implements Mediators - to make View components re-usable. I get that, but my question is: how re-usable can View components really be anyway?

Surely a View component that deserves a Mediator is a composite component - one built specifically for the application - made up of simple re-usable UI components? I understand the need to keep those sub-components re-usable, but I don't really see the point in trying to keep the composite View component re-usable, and therefore I don't see much harm in coupling such a component to a Presenter.

So, why Mediators?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: February 08, 2009, 09:43:28 »

how re-usable can View components really be anyway

Um, ask iLog, makers of fine graphing components for Flex. Ask anyone who makes a business of creating advanced visualization components. Its all about reusability. Don't assume that you are going to write (and therefore control the implementation of) every component your app might use. 

But one thing is for sure it will probably need to be give data to display and will possibly generate events, either on its own (such as at the end of an animation) or in response to user input (such as a click to drill into the displayed data).

If PureMVC used Presenters, then that would mean anyone wanting to use your component needs to be using PureMVC. And it would mean you have to handle things differently for third party components (which encapsulate their own behavior and logic) and your own view components (useless without their Presenters).

This also means that internally on your dev teams, you can have workaday copmponent monkeys grinding out your UI components without having any need to understand the framework.

I worked with a team at Cisco who was building an app that would have literally thousands of custom screens representing the internal configuration of all their routers. Due to the sheer volume of the components to be produced and the lack of skilled flex developers available, they had ruled out cairngorm because every developer would have to know too much about the framework and their evolving to understand how to code their components.

PureMVC addresses the common need to leverage flex or flash UI developers on the team who don't neet to know 'the big picture' or even PureMVC. You can spec and outsouce view components easier for the same reason.

Bottom line; Component developers don't need to understand the framework.

-=Cliff>
Logged
shauno


Email
« Reply #9 on: February 09, 2009, 02:07:21 »

Thanks for the answer Cliff. That makes perfect sense. Gotta love this forum!
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #10 on: February 09, 2009, 03:21:48 »

how re-usable can View components really be anyway

Bottom line; Component developers don't need to understand the framework.

-=Cliff>

I yank small components that I find useful out all the time and post them on my website for others. My projects are all PureMVC, but I can yank the components out and share them without needing the broader framework for them to function as expected.

Developing with PureMVC alongside the Flex framework allows use of custom events, binding, and all the other great stuff flex/as3 brings to the table at the component level. PureMVC is sitting on top of that gluing the whole thing together, managing the data, and facilitating communication amongst a complex set of components that are otherwise unaware of one another. The components themselves could care less WHERE the data is coming from, and aren't tied to a framework (outside of Flex itself) in any way. I think this fact is why I dig PureMVC over most of the other frameworks I have reviewed. They seem to want to get inside of your components to do their work. The mediators and proxies in PureMVC are kickass in this regard; they allow me to separate my tiers. <3
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
citizen_conn
Newbie
*
Posts: 9


View Profile Email
« Reply #11 on: March 18, 2010, 12:35:46 »

Cliff what about in the case of complex RIAs where the way in which a component is displayed (presented) can vary so much that a presenter is justified?

: Jay Fields
Since views are templates they can also contain behavior. The most common behavior you encounter in a view is formatting; however, since the view is a template you will occasionally see computations or worse. Because this logic is stored in a template it can be problematic to test. Presenters address this problem by pulling all formatting, computation, and any additional behavior into a class that can be easily tested.

This is a common problem for me especially when dealing with view components that are reusable but where their presentation is completely dynamic. Take a view component which has multiple drop downs, but depending on data from the model, certain drop downs need to be presented horizontally or maybe not presented at all.

If PureMVC used Presenters, then that would mean anyone wanting to use your component needs to be using PureMVC.

My original thought was that it seems as if though it would be a great way to add another layer between the Mediator and the components themselves, thus making the components dumber, i.e. more reusable.

However my colleague argues that this is less cohesive and that you are indeed right in the sense that if the view components relied on a presenter to be displayed properly, then without their presenter they are not as powerful and less portable to other applications.

How would one go about solving this problem in the PureMVC world? I was even dreaming of a LayoutMediator utility that would extend the Mediator and allow for multiple layouts of its view component. It could have a default layout when registered and the ability to specify different layouts for different instances.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #12 on: March 19, 2010, 10:02:53 »

How would one go about solving this problem in the PureMVC world?
Having an arbitrarily complex View Component encapsulate its behavior can lead to a cumbersome component, it is true. And its natural to want to pull some of that logic out.

One way to solve this within the realm of PureMVC is to have the View Component be a PureMVC core unto itself (be sure to use the MultiCore version of the framework). The View Component can be a Module whose view hierarchy can be as complex as an entire application if you like. You have an entire PureMVC system operating inside it, which can even use the State Machine to manage component wide state transitions and updates within the component.

And when you're done, you don't have to use pipes to talk to it or even embed it in a larger PureMVC application. It could run in any Flex or AIR environment. You can just plug the component into a Flex view hierarchy and listen for events and invoke methods if you like (i.e. using interfaces instead of pipes).

The component ends up being portable, but you are putting its brain and nervous system on the inside not the outside, keeping it portable.

It's like looking at the stars and then considering the universe of atoms inside your own big toe. There's plenty of room within you and without you. Yeah man, heavy like that.

-=Cliff>

Logged
Pages: [1]
Print