Page 1 of 1

MVC: Is this the View or a Command/Action?

Posted: Tue Jun 20, 2006 1:17 pm
by Nathaniel
Hi guys,

I have a Front Controller for my Help Desk solution.

Code: Select all

/* ...snip... */
//only two modes right now, so not worth anything besides an if-else
if ( $request->getTopicNicename() !== null )
{
	$view =& new Help_TopicView(
		 new Help_TopicRetriever($request->getTopicNicename())
	);
}
else
{
	$view =& new Help_SearchResultsView( new Help_SearchResultsModel($request->getSearchQuery()) );
}
				
$response = new Response;
$response->setHeaders( $view->getHeaders() );
$response->setContent( $view->render() );
$response->send();
exit;
?>
Anyway, take the Help_SearchResultsView for example. Basically, it does this:

Code: Select all

if ONE_SEARCH_RESULT
     //redirect to result
else
     //display whatever results came from the model, even if zero, using XSL file
So... I'm not sure if what I'm calling a view is really like a Command/Action, and that the View is just the Redirect header or the XSL file, or if the view should be responsible for determining whether or not to redirect or give the XSL file. My gut tells me that my Help_SearchRequestView is actually a Command, although maybe it's more of a "View Wrapper" thing to hide the actual view implementation.

Any thoughts?

- Nathaniel

Posted: Tue Jun 20, 2006 2:12 pm
by Christopher
I'd say that Help_SearchResultsView is a View, but the redirect puts it on the fence. Is a redirect program flow or HTTP output? A little of both me thinks.

This code looks like a Page Controller with two views to me. I would like to see you inject the response into the view to make it less procedural.

Posted: Tue Jun 20, 2006 2:46 pm
by infolock
Simply Put (straight ouf my book)

"The Model is the representation of the application's problem domain, the thing that is there to work with. A word processor would model a document; a mapping application would model points on a grid, contour lines, and so on.

The View is the part of the program that presents things to the user- input forms, pictures, text, or widgets. The View need not be graphical. In a voice-driven program, for example, the spoken prompts are the View.

The golden rule of MVC is that the View and the Model shouldn't talk to each other. Taken at face value, that might sound like a pretty dysfunctional program, but this is where the Controller comes in. When the user presses a button or fills in a form, the View tells the Controller. The Controller then manipulates the Model and decides whether the changes in the Model require an update of the View. If so, it tells the View how to change itself."

Posted: Tue Jun 20, 2006 3:01 pm
by Nathaniel
Hmm, a page controller, ok. And I'm now injecting the response. It does seem nicer that way.

I see how the redirect is really both program flow and HTTP output. Since Something has to send the redirect through the Response object, though, I think the Something is the View.

Posted: Tue Jun 20, 2006 10:57 pm
by Christopher
The other alternative is to allow the Response to have one or more Views as children. This would be a composite/component relationship where you attach Views to the Response. It's not that hard to do as long as the Views are polymorphic, so give each a render() method and attach as the sub-View's renderer and off you go.

Posted: Tue Jun 20, 2006 11:02 pm
by Christopher
infolock wrote:The golden rule of MVC is that the View and the Model shouldn't talk to each other. Taken at face value, that might sound like a pretty dysfunctional program, but this is where the Controller comes in. When the user presses a button or fills in a form, the View tells the Controller. The Controller then manipulates the Model and decides whether the changes in the Model require an update of the View. If so, it tells the View how to change itself."
I think you have the View and Controller mixed a little. Typically the Controller starts things by inspecting the Request. The Controller then selects the appropriate Model and View, and connects them. The Model then talks to the View providing the data to build the presentation. The Model is usually completely independent of the View and Controller.

Part of the strangeness of MVC is that it conceptually is two separations -- not three.

Posted: Wed Jun 21, 2006 11:49 am
by infolock
arborint wrote:
infolock wrote:The golden rule of MVC is that the View and the Model shouldn't talk to each other. Taken at face value, that might sound like a pretty dysfunctional program, but this is where the Controller comes in. When the user presses a button or fills in a form, the View tells the Controller. The Controller then manipulates the Model and decides whether the changes in the Model require an update of the View. If so, it tells the View how to change itself."
I think you have the View and Controller mixed a little. Typically the Controller starts things by inspecting the Request. The Controller then selects the appropriate Model and View, and connects them. The Model then talks to the View providing the data to build the presentation. The Model is usually completely independent of the View and Controller.

Part of the strangeness of MVC is that it conceptually is two separations -- not three.

I don't think I'm mixing it up at all. There may be other descriptive materials on MVC, but the one I know is the one I've displayed here.

I don't really know how you are getting there are only 2 seperations.. If there were only 2, it would be called MV, not MVC first of all.

Second, the Model can't be completely independent; otherwise it will never be updated or altered for data changes..

Posted: Wed Jun 21, 2006 11:53 am
by Maugrim_The_Reaper
Just a curious question, if the Model and View don't talk, where does the updated View data come from?

Posted: Wed Jun 21, 2006 3:24 pm
by Christopher
infolock wrote:I don't think I'm mixing it up at all. There may be other descriptive materials on MVC, but the one I know is the one I've displayed here.
I'd be interested to know the source because some aspects do not seem to be correct. Perhaps it is out of context and explained further elsewhere.
infolock wrote:I don't really know how you are getting there are only 2 seperations.. If there were only 2, it would be called MV, not MVC first of all.
There are two separations because the V and C are in a separate layer than the M. The V and C are together the Presentation layer. The Model is in the Domain/Data layer.

Code: Select all

View -> Controller
(Presentation layer)
         |
         V
       Model
From my reading, the separation between the Model and the Presentation is considered much more important than the View-Controller separation. In my experience the View-Controller separation is malleable and the interesting one to design/code.
infolock wrote:Second, the Model can't be completely independent; otherwise it will never be updated or altered for data changes..
Whether the Model can be updated has nothing to do with whether there are any dependencies. Receiving data is not a dependency. A dependency would mean that you could not use the Model object without providing it with a View object -- the opposite should usually be true.

Posted: Wed Jun 21, 2006 3:34 pm
by infolock
i dunno. i just think we're both on the same page, just are knowledged via different sources. Mine comes from Ajax in Action and other disuccions on google

Posted: Wed Jun 21, 2006 5:28 pm
by Christopher
infolock wrote:i dunno. i just think we're both on the same page, just are knowledged via different sources. Mine comes from Ajax in Action and other disuccions on google
That's what I thought. I know we have discussed MVC and Ajax ("Ajax in Action" is a great book!). Ajax puts a different and interesting spin on MVC. Do you have an example of a Ajax/Javascript Controller that fetches Models and Views via PHP? That might be an interesting new thread.

Posted: Wed Jun 21, 2006 6:23 pm
by Nathaniel
arborint wrote:The other alternative is to allow the Response to have one or more Views as children. This would be a composite/component relationship where you attach Views to the Response. It's not that hard to do as long as the Views are polymorphic, so give each a render() method and attach as the sub-View's renderer and off you go.
Now that's very interesting. That would basically transfer decision of which View to use to the Response object instead of the Controller...

I like giving the View the Response, however, because the Response needs two things: View headers and View content, whereas the View only needs one parameter, the Response, to successfully send off the response. It's like $view->dispatch ( new Response) instead of $response->setHeaders($view->getHeaders()); $response->setContent($view->render()); $response->send();.