MVCP - MVC missing a layer?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

MVCP - MVC missing a layer?

Post by McGruff »

An http request could maybe be seen as having two parts.

(1) a "presentation request" - ie the page to serve up to the client (model and view)

(2) a "processing request" - any tasks which do not output anything to the browser: form processing prior to building the "success" page/form redisplay, authentication, etc (added in controller)

In addition to MV&C, I wonder if there should be an explicit "non-output-processes" layer? That feels more symmetrical, putting non-output-tasks on a par with model & view in the API. Quite often there are questions about where in the MVC model form-processing should go - maybe this would make it clearer.

Any takers for MVCP?
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Post by lazy_yogi »

the model does this

MVC:
Model : The brains of the program (all processes including "non-output-processes")
View : Takes care of displaying the output
Controller : Get the input from the user who is in control if what is entered as input
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Not quite the way I understand MVC: the controller would be the "brain" and the model simply creates a bunch of unformatted output vars.

I agree about the view though :wink:
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Post by lazy_yogi »

Hi McGruff,

the first link on google with 'MVC'
http://ootips.org/mvc-pattern.html

"""
Input --> Processing --> Output
Controller --> Model --> View
"""

I'm sure the others will produce similar results.
MVC is the pattern that is most used and well known.
In fact you use it to a large degree every day because browsers are developed with it in mind. It's a very cleverly designed seperation of the input, output, and processing.

Cheers,
Eli
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

The model and view, as I understand it, are solely concerned with (respectively) defining page content and presenting the content. The model should not carry out other tasks.

As an example, form validation or authentication don't belong in the model: they'd normally be carried out by the controller (and may determine which model will be loaded).

My point is that maybe non-output stuff like this deserves its own named layer precisely to avoid this kind of confusion.
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Post by lazy_yogi »

Ohhh .. I see what you're thinking.

The Model class can use other classes to help carry out its duties. In fact it definitely should for the sake of modularity, information hiding, and the clarity of using the simple interface of objects. But all the processing is done by the model (brains) class. This class uses other classes to simplify its tasks. It's like a manager and calls on his subordinate classes to to the actual nitty gritty work of the processing.

However. MVC is specificaly to point out that you shoud distinguish between input, output, and the processing as seperate entities.

So the Model (Brains) class can definietly use a validation class to do its processing.

Code: Select all

class brains {

    function brains() { # constructor
        $this->run()
    }

    function run() {
        while ( $stuff = getsomeinput() )
            if ($this->validate($stuff))
                $this->process($stuff)
    }
    function validate($stuff)
        $validator = new Validator();
        $validator->validate($stuff);  # all the validation work is done here and the model/brains 
        return $validator->isvalid();  # class only uses the nice inteface to the validator class

    }
    function process($stuff) {
         # do some processing
    }
}
But all the high level processing occurs in this 'model' class. whether some of the processing is to be displayed or not isn't an issue here.
That's the job of the View class.

Hope that helps clarify a bit

Oh .. and btw .. the Controller handles the uer input.
When u say controller, I thnk you actually mean Model.

Cheers,
Eli
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

lazy_yogi wrote:.. the Model (Brains) class can definietly use a validation class to do its processing.
The choice of model would depend on the results of the validation ("success" page or redisplay the form) hence this should, I think, be carried out in the controller. Same sort of deal with authentication.
However. MVC is specificaly to point out that you shoud distinguish between input, output, and the processing as seperate entities.

When u say controller, I thnk you actually mean Model.
My understanding is that controllers tee up the MVC framework, associating objects and selecting a model & view based on the http request input. Each model defines a page type, and views define how the models will be presented.

However you choose to cut the cake, my refactoring instincts start twitching when I start to think about page-building tasks and non-output processes.
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Post by lazy_yogi »

Hi McGruff,

I would generally put most of the management work in the model class and not have the input and output components do much work (other than handling the inputing and outputing tasks).

I see the output as a small job that the model gets the view class to take care of. So if the controller has to take input and process it and produce output. It processes it (a non-output task) and then does some task to display the user for the next screen,etc (an output task). Whether something is an output task or not is a minor detail. If it has to output something to the user, it sends it off to the view class after processing. Either way, it has to do the processing.

I'm comming from a general OOP take on it. I'm not trying to adapt it specifically to web based enviornment. But I think it works for that also.

Of course, there's more than one way to skin a cat. So I'm definitely not saying you're wrong.

Cheers,
Eli
IlyaNemihin
Forum Newbie
Posts: 6
Joined: Mon Jan 19, 2004 5:35 am

Re: MVCP - MVC missing a layer?

Post by IlyaNemihin »

Hi, All!
McGruff wrote:An http request could maybe be seen as having two parts.

(1) a "presentation request" - ie the page to serve up to the client (model and view)

(2) a "processing request" - any tasks which do not output anything to the browser: form processing prior to building the "success" page/form redisplay, authentication, etc (added in controller)
Take a look to my small system ElementalSiteMaker http://esitemaker.sf.net, you find out class Manager, additional to Model, Viewer and Controller, f.e. the main method of Manager class is manage (elementalSiteMaker/include/Page/Core/PageManager.php ):

Code: Select all

function manage(){
    $this->beforeManage();
    if( $this->pageController->isActionInRequest() ){
      $this->pageController->makeAction();
      $this->urlKeeper->redirect();
    }
    else{
      $this->pageViewer->showPage();
    }
  }
Regards,
Ilya
IlyaNemihin
Forum Newbie
Posts: 6
Joined: Mon Jan 19, 2004 5:35 am

Post by IlyaNemihin »

also about authentification:
in inherited class PageManagerAuth is used method beforeManage(elementalSiteMaker/include/Page/Auth/PageManagerAuth.php):

Code: Select all

class PageManagerAuth extends PageManager{
  var $user;

  function PageManagerAuth(){
    $this->PageManager();
  }

  function beforeManage(){
    $sid = $this->request->getParam( 'sid' );
    $sessionSystem = new SessionSystem();
    $uid = $sessionSystem->getSessionParam( $sid, 'uid' );

    $authSystem = new AuthSystem();
    $this->user = $authSystem->getUserByUID( $uid );
    if ( $this->user == '' ){
      echo 'error login';
      exit;
    }
    $this->pageViewer->setUserName( $this->user->getName() );
  }

} // end class
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Has also been some interesting discussion about this on http://www.sitepoint.com/forums/showthread.php?t=144960 and then some thoughts on an experimental front controller design here: http://www.sitepoint.com/forums/showthread.php?t=148280.

MVC causes a lot of confusion. I think I've also been confused at times. The key is, I think, that MVC is great for printing a page BUT an http request to a dynamic website has a lot more going on than merely printing a page.

I think a common mistake (which I've also been guilty of) is to try to fit the entire process inside MVC. However, it's maybe better to view MVC as just ONE PART of a three-stage picture that may also include pre-output processes and post-output processes (maybe even a fourth stage to interpret the request).

Sandwiched in between, we could define a layer with responsibility for selecting dynamic & static content, formatting it, and finally printing it. That (and nothing else) is perhaps the place to apply the MVC pattern.
Post Reply