Templates which "Pull" model data

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

blueyon
Forum Commoner
Posts: 76
Joined: Tue Oct 30, 2007 9:53 am

Re: Templates which "Pull" model data

Post by blueyon »

Chris Corbyn wrote:IMHO, "template" is not separate from the view. It's part of the view (and in some cases the only "part" of the view).

I tend to (when I'm using my own framework-ish code) use a "View" class which "loads" a template. The View class is nothing more than a container for data (i.e. "pushed" into it from the controller in my case), and a collection of View helpers (*sigh* using Mixins).

I was sort of doing it that way aswell but, Its like you said in the post though that you have to change the contoller to alter the view.

I noticed a post in the sitepoint forums that every one was saying they use objects in there views and it was ok to do this. Having the view have access to everything the cotnroller has saves a lot of coding time.

I might be wrong!
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Templates which "Pull" model data

Post by Jenk »

Templates are the View. "View" handles with presentation and presentation only. Anything else is either domain, or controller.

Templates are not the only implementation of "View" before any get confused.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Templates which "Pull" model data

Post by Christopher »

blueyon wrote:A brief list of all the frameworks using the render method in a controller.

Zend
Symphony
Akelos
I think ruby on rails.
First of all, that does not mean they are right! ;) But really, I think you are misunderstanding what the render() method does in many of those frameworks. It is really a helper that runs the View based on some conventions. It does not combine the Controller and View. It is a helper for the 1:1 case.
blueyon wrote:The only way I can think of to have a render method in the page controller is to have the controller have a view combined. THis method does not cause bloat.
Something is only bloat if you personally don't use it. ;)
blueyon wrote:It seems like there is an extra layer being added when you are doing it arborints way. You now have Model-View-Controller-Template.

1. In arborints examples it means you are attaching all the different components of the page on every single controller.
2. Its no longer leaving it upto the view to decided which sub controllers are begin used.
3. The sub parts of the page might have there own functionality such as a search box so a controller should be required.
4. You are turning the view layer into a controller by adding functionality before displaying things.
I am not sure what example, but attaching everything in the Controller is one way to do it. But certainly sometimes you might want to attach sub-Views to the View. Having the View attach a sub-Controller is trickier because the interfaces of Controllers and Views are different. But if you combine the Controller and View (which you are doing) then attaching a sub-Controller is really attaching a sub-View.

And finally, the whole point of the View is "adding functionality before displaying things". The View is display logic. It can be only a template, but it can also be loaded with code and functionality. Views are not dumb -- they really everything but the request handing, program flow code, domain model code or data layer access code.
blueyon wrote:I noticed a post in the sitepoint forums that every one was saying they use objects in there views and it was ok to do this. Having the view have access to everything the cotnroller has saves a lot of coding time.

I might be wrong!
Not at all. As I have said, combining the Controller and View into a Presentation object is a very reasonable thing to do for many "pages" in PHP. And remember, even though code is combined does not mean the programmer is not enforcing clean dependencies. They are just not as clear and not enforced against scheduling demands. ;)
(#10850)
blueyon
Forum Commoner
Posts: 76
Joined: Tue Oct 30, 2007 9:53 am

Re: Templates which "Pull" model data

Post by blueyon »

arborint wrote:First of all, that does not mean they are right! But really, I think you are misunderstanding what the render() method does in many of those frameworks. It is really a helper that runs the View based on some conventions. It does not combine the Controller and View. It is a helper for the 1:1 case.
I know most of the frameworks are static method non OOP messes. I agree with you that teh render method is just a helper method to call code that is needed to render the view.

The render could be:

Code: Select all

 
function render($template) {
$view = new View($template, $this->data);
 
return $view->render();
}
 
Also I know I have said "1:1 = controller:view", but this is probably not the case if I use the controller methods. I can have index, insert, update, delete etc.. with there own views and all calling there render function at the end.
arborint wrote:I am not sure what example, but attaching everything in the Controller is one way to do it.
This is the example you posted in the my composite view thread:

Code: Select all

 
<?php 
class ControllerDefault extends Action { 
var $id = 'content'; 
 
function execute($registry) { 
$view = new ViewDefault(); 
$view->set('title', 'Default'); 
$view->set('menu', new MenuView() ); 
$view->set('content', new HomeView() ); 
 
$response = $registry->get('response'); 
$response->setBody($view->render() ); 
} 
} 
 
class MainView extends View { 
var $parent = 'layout'; 
 
function render() { 
$template = new Template('main.php'); 
$template->set('title', $this->data['title'] ); 
$template->set('menu', $this->data['menu']->render() ); 
$template->set('content', $this->data['content']->render() ); 
return $template->render(); 
} 
} 
 
Well say for example I have a controller with multiple methods index, insert, update, delete etc..

So to have the full display I need to add this code in every method on ever controller?

Code: Select all

 
$view = new ViewDefault(); 
$view->set('title', 'Default'); 
$view->set('menu', new MenuView() ); 
$view->set('content', new HomeView() ); 
 
This is going to be a pain to add. It also means if I want to replace one partial view with another I need to edit all my controllers.
arborint wrote:And finally, the whole point of the View is "adding functionality before displaying things". The View is display logic. It can be only a template, but it can also be loaded with code and functionality. Views are not dumb -- they really everything but the request handing, program flow code, domain model code or data layer access code.
From the composite view thread by you:
arborint wrote:There is nothing in the MVC pattern that says that the View cannot access the database.
I'm assuming you where you say "domain model code or data layer access code" from the secound paragraph up that you include the database in this description.

The way you have set the view up is just another layer. I don't think anywhere in any of the MVC articles, examples or other frameworks does a view class update a database or have functionality.

I just don't agree that the view should be another layer of code and not the actual view e.g HTML.

I don't agree that the view should be able to call controllers. Controllers should only be able to call other sub controllers.

I don't mind putting objects in views if it speeds up development which I think we both agree on.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Templates which "Pull" model data

Post by Christopher »

First of all in the example you show, I would probably pull the attaching of sub-Views into the View rather than having it done in the Controller. But again, there are cases where you might want to do it either way.
blueyon wrote:
arborint wrote:There is nothing in the MVC pattern that says that the View cannot access the database.
I'm assuming you where you say "domain model code or data layer access code" from the secound paragraph up that you include the database in this description.

The way you have set the view up is just another layer. I don't think anywhere in any of the MVC articles, examples or other frameworks does a view class update a database or have functionality.
In context, what I meant in that quote is that there is no reason that the View can get data directly from the Model. It is the difference between the Controller or the View doing "$data = $model->find($id)". The Controller can either give the View $data or $id. There are circumstances where each is a better choice. (Check Fowler for the rare edge cases where the Model needs to be dependent on the View or Controller)
blueyon wrote:I just don't agree that the view should be another layer of code and not the actual view e.g HTML.
The View can be the actual template, or it can be HTML generation code, or it can be either of those plus display logic. For example, if you have an area on the screen that displays whether a user is logged-in or not -- is that logic to check the user's login status in the Controller or View?
blueyon wrote:I don't agree that the view should be able to call controllers. Controllers should only be able to call other sub controllers.
I thought is was you with "Its no longer leaving it upto the view to decided which sub controllers are begin used" that suggested that Views call sub-Controllers above. I just said it is possible but problematic. I think it is cleaner for Controllers to dispatch sub-Controllers and Views to attach sub-Views.
blueyon wrote:I don't mind putting objects in views if it speeds up development which I think we both agree on.
Yes! :)

All I am really saying is that there are multiple ways you need to wire up MVC depending on the circumstances, so you want flexibility. That means having Controller::render() for 1:1, plus the ability to include any logic and attach any kind of hierarchy to the View, plus the ability of using a Response object to aggregate and lazy render, etc. etc. You need several strategies to handle all the various use cases.
(#10850)
Post Reply