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.