Page 1 of 1
MVCP - MVC missing a layer?
Posted: Sun Dec 28, 2003 7:43 pm
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?
Posted: Mon Dec 29, 2003 2:53 am
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
Posted: Mon Dec 29, 2003 3:10 am
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

Posted: Mon Dec 29, 2003 4:02 am
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
Posted: Mon Dec 29, 2003 4:50 am
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.
Posted: Mon Dec 29, 2003 7:24 am
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
Posted: Mon Dec 29, 2003 11:35 am
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.
Posted: Tue Dec 30, 2003 7:26 am
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
Re: MVCP - MVC missing a layer?
Posted: Mon Jan 19, 2004 5:43 am
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
Posted: Mon Jan 19, 2004 5:48 am
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
Posted: Wed Jan 21, 2004 9:04 pm
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.