I'm building a small PHP MVC, and I've hit a wall with a small area of the coding. I think I need "partial views", but I might be able to achieve something with the existing code.
My controller in it's simplest form currently:
Instantiates an object
Checks if a POST variable isset
Displays view 1 or displays view 2 as necessary
The view(s) currently:
Displays HTML markup
Use and echos the models get functions such as getUserInfo()
Everything is working great, however the code is now getting fairly large in both the controllers and views, and I've reached a situation where I need to include "modules" or sub views inside the main views (1 and 2).
For example if view2 is loaded, then I need to display (as part of the view2) another view, say a 3 part sign up registration form. This registration form comes with it's own controller file too.
I can do something like this, which will work and give you some idea of what I am trying to do, but I acknowledge this breaks MVC design patterns.
View
<div id="mydiv">Some content</div>
<div id="mysignup"> <?php include('controller_signup.php'); ?></div>
<div id="content"> The views main page content </div>
The view is then pulled in from the controller, in the right place.
As mentioned, I think I need to use partial views, however most of the info I've found is for ASP, and I'm slightly lost!
I would have thought this is a fairly common problem, so I assume there is an obvious solution!
Thanks!
The root of you problem is fact that you do not have views. What you call a "view" is a actually a template. This in turn forces the presentation logic in the controller.
In proper MVC views are instances, which contain all of presentation logic. They acquire information from model layer and then, based in data, choose how to display this information. Each view manipulates multiple templates.
Also, it seems that your controller has gained extra responsibilities. It is supposed to change the state of model layer and current view, instead of rendering templates.
Can't say I agree with tereško. Having the presentation logic in a separate view class might seem more proper, however it does add another layer of complexity. In many cases, this additional layer is not necessary - often a view can directly render whatever model or data you inject. So you end up with empty View classes that only pass the model from the controller to the template.
I'd say, Keep It Simple, you can do pretty complex (and maintainable) websites with simple MVC, without introducing the notion of templates.
To handle subviews, you can simply have the main view inject data into the subviews, this should be transparent to the controller (who just provide the main data without caring how it should be rendered). So in practice, you could have something like this:
Controller:
public function someAction() {
// ...
$view = new View('name');
$view->data = $someList;
}
View:
<?php foreach ($someList as $item): ?>
<?php echo (new View('subview', $item))->render();
<?php endforeach; ?>
Related
i know that this question already has been asked. But i still dont understand it.
Right now im trying to understand how to make use of the MVC Modell.
But i dont get how to integrate everything and right now I am hesitating to use a framework before i really get it.
What I try to achieve:
I want to have a header, a footer and a menu which remain the same all the time.
Like this:
HEADER
MENU
{CONTENT}
FOOTER
So my thinking is:
My Controller gets some Information, lets say its a User-ID.
Controller calls a method from the Model:
Get all DATA from USER with ID: 1
Then the controller passes the DATA into a view, lets say a list.
So where to go from here?
Should the controller pass this view into another view?
Like:
$site = new View(); <br>
$site->wholeSite($content);
and then site is something like:
HEADER
MENU
{$content}
FOOTER
Please excuse my simple approach, im just trying to get the basic idea behind it and i already read the first 20 pages of googling it.
Just cant get my head around it.....
It would be really nice if you would explain it for an Beginner :)
Thanks in advance!
you can call multiple views from the control like:
$this->load->view('header',$data);
$this->load->view('menu',$data);
$this->load->view('content',$data);
$this->load->view('footer',$data);
If you have a nested div then you can use regular include function like from a particular view file.
include('footer.php');
According to the path of the view file. The data also gets transferred from parent view to the included file.
Generally MVC apps have a universal layout view which contains the header, footer and menus. Sometimes data required for that is handled outside the controller, in say your init script or bootstrap.
An MVC purist might pass all data the layout requires from the controller, but that can be repetitive, although setting the data in an abstract controller construct might alleviate that.
On the question of views and sub-views there are generally two solutions:
A.) You have one principle view which all required data is passed to. In that view sub-views (partials) are called, and data is passed down into them.
B.) You instantiate all your views in the controller, passing all the data they need directly into the view, you would then pass views as parameters into other views.
Both methods have their pros and cons. I find the first option leads to less Fat Controllers, so I usually go with that.
I'd recommend you learn an existing MVC framework ( CodeIgniter, now defunct is basic enough to make it a good entry point), as that will show you how things are done.
OK I now basics of the MVC concept, and I know there are similar questions asked but still didn't find clear answer on this. Reading about MVC I found some contradictory examples, so I wanted to find out which concept is better.
Should I use my controller to load data from the model and than pass that data to the view or should I let the view to load data from the model and use controller just to select the appropriate view.
The more natural(right) way to me is that controller should load the model, but than again if I have require the same content that has 2 different views, for example:
view displays simple article text
view displays same article text but also displays box with article author info.
The thing that confuses me is I have single request, show me article with ID 33. In the first case everything is clear, but now my second view renders using different template that shows additional data (about the author), so should I let the view to request data from the model (about author) or that entire logic should be done by controller?
It's confusing because now the controller should request appropriate data from the model based on template the view should render.
Hope I make sense :)
Short answer: Pass the model to the controller and the view.
Long answer: In MVC, the controller does not "load data from the model then pass that data to the view". The view has a direct relationship with the model and requests data from it. See: How is MVC supposed to work in CodeIgniter and http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller : "A view requests from the model the information that it needs to generate an output representation."
As such, to enable loose coupling, initiate the model view and controller completely independently and pass them in to eachother.
This allows the strict separation of concerns MVC advocates and allows you to reuse any component with any other as nothing is hardcoded.
Something like:
$model = new Model;
$controller = new Controller($model);
$view = new View($model, $controller);
echo $view->output();
The controller should not select the view, nor should it select the model. By putting this responsibility in the controller, the controller is not reusable with other views or models.
Edit: I've updated this to answer tresko's comment about why the view needs to know about its controller.
The view needs the controller in order to avoid hardcoding controllers into views. This is so that a view knows which controller it's paired with in the current context and can post back to it.
Events (user actions) are fired in the view and need to be handled by controllers.
There are 3 ways of doing it:
1) Hardcode the view:controller relationship, on the web this is achieved by using <a href="/some/hardcoded/route"; or <a href="' . $this->router->create('someController, 'action') . '>' This removes the possibility to use the view with any other controller which isn't desirable.
2) Pass the controller to the view and let the view know which controller its events will be fired to. On the web, using this approach the view will also need a Router which will convert a controller action into a route. e.g. <a href="' . $this->router->getRoute($this->controller, 'action') . '>'
3) Pass the view to the controller and have the controller set actions on the view: (controller code) $this->view->setEvent('buttonClick', $this->router->getRoute($this, 'action'))... (view code) <a href="' . $this->getEvent('buttonClick') . '>'
Of these,
1) Is the least desirable as it heavily impacts flexibility. The view can only ever call actions on a very specific controller.
2) is the least amount of work for the developer but each controller needs a specific interface.
3) This offers the most technical flexibility but there's more work for the developer and the controller needs to know a lot about its view, beyond the API it must know what events are available in the view. If a view is updated and has a new action, each controller will need to be updated to account for it. This applies to 2) as well, but because 2 can easily be handled using interfaces it's far easier to track down every class which uses it.
In my opinion, 2 and 3 are both good approaches but 2 is superior because it allows for a much more robust system and allows the most re-use, the downside is that controllers must implement a specific interface. 3 allows the controller to have any interface but it must know quite a lot about its view.
CakePHP and other popular frameworks tend to hardcode the relationship (e.g. http://book.cakephp.org/2.0/en/views.html ) here in their example, echo $this->Html->link('edit', array( 'action' => 'edit', $post['Post']['id'])); ?> the link can only go to the "Edit" controller. This severely impacts reuse.
My suggestion is that the logic for combining data sources with views should happen entirely in the controller. Views should not be bound to specific data sources.
For example, if you had a view that used the Smarty syntax (or similar) with named placeholders, then you could use any data source, text, model, etc to provide information to render into the template. If the view is tied to a model, you'd need to modify the model and view with an awareness of the impact on the other.
Tight coupling like that leads to more problems by accidentally overlooking something than looser coupling, which gives you fewer chances of breaking something by accident.
EXAMPLE:
class Page_Controller extends Controller {
// __construct/__destruct/__callStatic/__call/etc, whatever you need in your implementation
// -------------------------------------------------------
// Adjust to suit your situation for passing data
// This controller doesn't care where objSource comes from
// -------------------------------------------------------
private function pageSpecificImplementation($objSource = null){
// using a factory class - but assume a view is created in whatever way works for you
// the key thing here is that the view could be anything that can be returned as a string - but use whatever works for you
$tplMain = make::view( 'template-url-or-path' )->assign(array(
'placeholder1' => $objSource->value1,
'placeholder2' => $objSource->value2
));
$tplSub = make::view( 'template-url-or-path' )->assign( $objSource );
$tplMain->assign('sub',$tplSub->render())->render();
// $tpl is some form of html? csv?, who knows - not relevant at THIS stage
// okay - now I know what I want to do!
// decide what to do with it here - output headers for html
// save to a file
// output and cache the output, whatever works for you here
// output to pdf?
// send as an email?
output::html( $tplMain, $cacheable, $cachetime... );
// output::email( $tplMain, $extra_params );
// output::pdf( $tplMain, $extra_params );
}
}
Here, you're using a view, without tightly coupling it to the output. Your controller can modify the output based on whatever business rules are in play when it's run, but the data source is not tied to the view and the output isn't tied to the view.
I'd suggest 'some' implementation that separates in a way that follows similar principles. YMMV depending on what you're doing and how you want to implement it, but try to keep each element separated in MVC.
In some implementations you'll see the logic for 'replacing' things in views done without mentioning 'what' view. This is commonly done in Smarty. The view can then be determined by the Controller's flow. Data can be pulled from multiple models or other sources, which may, or may not, affect which View is appropriate.
So, you should definitely separate loading of data from the view. Keep it in the controller, which is where decisions should be made. Views shouldn't connect with models unless you have a specific use case in mind, such as a theme model with a tightly coupled theme view where there's no additional business logic involved (unlikely but possible?).
Where should a breadcrumbs path be declared (in other words, in which letter of MVC)? So far I've been declaring it in Controllers, but I've recently started to work with CakePHP, where it is all made in Views and it surprised me.
I'm going to throw an answer out here, because there's a lot of confusion about what should and shouldn't be done with breadcrumbs.
The Model
The Model is a layer that contains your business logic consisting of domain objects, data mappers and services. You can read more about the model here.
The Controller
Remember: fat model, skinny controllers. Your controller / method is accessed from your routing mechanism. Once you're in the controller, you want to get your model object, perform whatever logic is required in the model, have the result of this returned to a variable in your controller, and then you use this to display data in your view.
The Breadcrumbs
That being said, your breadcrumbs need different parts to work. Let's think about this:
They need the current page
They need a list of pages
They (may) need a custom "class=current" added
Breaking those down:
In my framework, the current controller is also the page name (login controller maps to /login). So, we already have the current page.
The list of pages.
If your parent/child relationship of the pages are tied directly to the datamodel, then in your controller you pull the list of pages from the model. So use the model if the breadcrumbs can be automatically generated.
If the framework you're using allows breadcrumbs created entirely by user choice, then you are just choosing what to put in the breadcrumbs manually. Either way, you state your breadcrumbs in the controller, and if you need to get them from somewhere, use the model.
Finally, the "class=current". Although you shouldn't really contain significant 'logic' in your view, small things like loops or if statements are pretty standard. Here, you would check your breadcrumbs for the title equalling the current controller name (passed through as a variable to the view), and add a class=current if found.
Code Example
Note: untested
/**
* So we're in the home controller, and index action
*
* #route localhost/home or localhost/home/index
* (depending on .htaccess, routing mechanism etc)
*/
class Home extends Controller
{
public function index()
{
// Get current class name, so we have the current page
$class = __CLASS__;
// Let's say the page heirachy is tied to the model, so get pages for current method, or however you want to implement it
$pages = $model->getPages($class);
// So the TEMPLATE handles the breadcrumbs creation, and the controller passes it the data that it needs, retrieved from the model
// (new Template) is PHP 5.4's constructor dereferencing, also included is some lovely method chaining
// setBreadcrumbs() would assign variables to the view
// Render would do just that
(new Template)->setBreadcrumbs($currentPage, $pages)->render();
}
}
And now, the view... note, I use PHP 5.4, so I can use short echos...
<body>
<?php foreach($breadcrumbs as $b) { ?>
<li <?=($b['current'])?'class="current"':''?>>
<a href="<?=$b['page']['url']?>">
<?=$b['page']['title']?>
</a>
</li>
<?php } ?>
</body>
And that's how I would do it. Some of this is down to personal preference, but I hope this shows one way of doing it and is at least a little useful.
I actually came across this answer googling "php mvc breadcrumbs", and writing out my brain has really helped me to figure this out too. So thanks!
Whenever you see words "logic" and "view" together you should start worrying. My vote is for Controller because breadcrumbs is typical example of application-level logic, so putting it to the view violates MVC in my opinion.
Breadcrumbs should be in the controller. I use CodeIgniter and do something like
$data['breadcrumb'][0] = array("title" => "Home", "alt" => "Home Page", "path" => "home/");
$data['breadcrumb'][1] = array("title" => "About", "alt" => "About Me", "path" => "home/about");
And then in the view loop through and display them as a list.
<ul class="breadcrumbs">
foreach($breadcrumb as $b)
{
?>
<li><?php echo $b['title']; ?></li>
<?php
}
</ul>
You can then also declare simple things like classes, current pages, etc. The only downside is you have to set the breadcrumbs in every page.
ALL logic should be in the controller. Access databases through the models, perform logic in the controller, and pass it to the view.
Simple stuff like
<?php echo ($loggedin)?"Logged in as" . $user->firstname:"Not logged in";?>
can be in the view. But you shouldn't be setting up complex flow patterns. Leave that to the controller. Views are cheap. You can have a half dozen slightly different views and no one will care. It's not like static HTML where you would have to maintain a half dozen pages.
Include common things in the views (like headers, footers, script files, javascript files, etc) and then let them be.
IMO, the breadcrumb relates to the set of controller actions taken to get to the current page or the action's place in the hierarchy of the site, depending on your interpretation. From that perspective, the controller seems the natural place to construct the data for it, though the rendering should occur in the view. In order for it to be completely generated in the view, you would need to either expose details about what controller action is being invoked by the view or have a fixed view-per-action model so that the breadcrumb for each could be precalculated. Moving the logic for computing the breadcrumb to the view itself seems to violate the separation of concerns in MVC and may preclude reusing views for different actions, which would violate DRY>
In my opinion, generating data for the breadcrumb is a cross-cutting concern in the controller, i.e., you have some shared code that runs regardless of the action that uses the url to construct the breadcrumb data. There is also some shared view code that takes the controller-supplied data and renders it consistent with the design.
Note that I'm speaking from a purely architectural perspective. I'm not familiar enough with CakePHP (or other PHP frameworks, for that matter) to even judge whether your observation about it is correct. From a pattern perspective, putting it in the controller seems like the right thing to do. In a given implementation, though, it might make sense to violate the pattern.
$this->Html->addCrumb('Home', '/pages/home');
$this->Html->addCrumb('Contacts', '/pages/contacts');
echo $this->Html->getCrumbs('»', 'StartText');
if I have a page on my site where i have to show 4 or 5 snippets (news feeds, event feed etc), all relating to different data (in different models and db tables), then what is a sensible way to handle the generation of the snippet content and layout? i could use a single snippet controller which contains static functions which each return a view populated with the relevant data. But each function in this snippet controller will be interacting with different data/models, so i'm not sure how OOP this is. Or, I could just add a static function to each of the controllers which are dealing with each associated set of data - e.g in a News_Controller, as well as functions to show all news items, individual news items etc, i could add a static function to generate the news feed by simply returning the view I need. I think this approach might work, as i don't want to instantiate an object for these simple snippets, so having static functions in the relevant controllers makes a bit of sense. Bit of a stream of consciousness here, but am i making any sense?!
Many frameworks have some notion of "partials", which are typically used for this kind of thing.
Since these partials are generally read-only, and are often displayed on every page (or some well-defined set of pages), you can approach them without thinking in terms of controllers like you would for a page.
In other words -- remember that it's fine if your view/layout code talks directly to your models, as long as it's only interrogating them.
I do things like this all the time:
layout.php:
<div id="newsWidget">
<?PHP $news = Model_News::latest(); ?>
<?PHP foreach($news as $newsitem): ?>
<!-- output some news headlines -->
<?PHP endforeach; ?>
</div>
Model_News::latest() might implement some caching, etc, since this is layout code and I probably don't want to hit the db on every request.
No controller-bloat necessary!
You may want to look into Hierarchical Model-View-Controller (HMVC). It's especially suited to making pages with snippets. I believe Kohana implements it.
Basically, you have multiple Model-View-Controller triads each responsible for each snippet. So you could have a controller to access the News database and load a variety of small views for different types of news displays.
You can architect your MVC pattern to provide a mechanism for allowing data that has been set to be returned as an array. For instance, normally a web request to /news/feed/ would result in pertinent data being set and subsequently passed to a view. In addition to web requests, the system should also allow a controller to make such a request, i.e., $vars = $this->call('/news/feed/'); The system will recognize the internal request and return the set vars rather than invoking a view.
This allows you to keep your controllers and models cohesive.
I'm about to do a PHP website using the MVC pattern. I am not using a framework as the site is fairly simple and I feel that this will give me a good opportunity to learn about the pattern directly. I have a couple questions.
Question 1: How should I organize my views? I'm thinking of having a Page view which will have the header and footer, and which will allow for a Content view to be nested between them.
Question 2: If I have 5 Content pages, should I make 5 different views that can be used as the content that is nested within the Page view? Or, should I make them all extend an abstract view called AbstractContent?
Question 3: What about controllers? I think there should be one main controller at least. But then where does the request go from there? To another controller? Or should I just call the Page view and leave it at that? I thought that controllers were supposed to handle input, possibly modify a model, and select a view. But what if one of the views nested within the view that a controller calls requires additional input to be parsed?
Question 4: Are controllers allowed to pass parameters into the view? Or should the controller simply modify the model, which will then affect the view? Or is the model only for DB access and other such things?
1 - This is a matter of preference. The simplest way would be to have a separate header and footer file. Then you could do something like this in your page controller
$title="Page Title";
$var1 = 'var1';
$var2 = 'var2';
$var3 = array("asdf","adsfasdf","234");
include(HEADER); //$title is in header
include(DIR_VIEWS . 'page.php'); //$var1/2/3 are in page.php
include(FOOTER);
// variable were created before pages were included so they will be set in the templates
If you were to go the nested route you would have to start fiddling with str_replace and that starts heading towards a template engine, out of scope for this answer.
2 - No need to make views objects. A "view" can just be a file on your filesytem that contains the html for that view. Like my example above. These pages can contain basic php to loop/echo variables as well.
3 - You are describing a front controller (sometimes called dispatcher or router). This is really the way to go. There are a couple methods for creating a front controller.
You can have an array of urls that point to controllers.
$routes = array (
'~^/home/$~' => 'home.php',
'~^/contact/$~' => 'contact.php',
'~^/blog/.*?$~' => 'blog.php'
);
or you can use the first "directory" in the url as the controller name and load that file form your controller directory.
4 - The entire point of the controller is to get info from the model and pass the data to the view.
Edited for comment
If you want a bunch of views to have a sidebar you just include that view in the other view. For example:
<div id="content">
<p>lorem ispum stuff</p>
</div>
<?php include(DIR_VIEWS . 'sidebar.php');
Just make sure that in controllers that "control" pages with sidebars you include some code for sidebar functions:
if ( $_GET['keywords'] ) {
$sidebar_search_results = get_search_results($_GET['keywords']);
}
// this code should be in a file that you include
$sidebar_search_results could be an array of results that your sidebar view parses and displays.
Think about what ways you'd want your HTTP responses to look like: full pages with/without nav, stripped pages for printing, JSON & XML responses, an index/sitemap. After you feel the site is forming, add more and more shortcuts for getting your response out there with as little code as possible.
If the page layout is similar, I would use the same view and load content into it from a model (possibly a database).
Check out the Front Controller pattern: you should always be able to intersect the request in a single point of entry. I would put something hierarchally in front of your controllers and then have one controller per "main page" (forum, blog, news). This is sufficient to control, but you'd have to decide what chunks are large/small enough for you.
Controllers are responsible for everything that gets passed into the views. Controllers should fetch data & settings & what-not from models and pass on to the views.
Question 1:
This is indeed a way to do this, and one which I allways use.
Question 2:
Just keep views as simple as possible. I tend to create just 5 separate views (plain php files).
Question 3:
In the normal mvc pattern, there is one front controller (which OS just a bootstrap file, the index.php) which executes one controller.
In HMVC, controllers can send additional request to other controllers.
Question 4:
The normal MVC pattern applies on normal apps, where views are persistent, and can observe the models. With web applications this is not possible, because every request everything is reloaded. So the most used pattern is to let the controller pass the parameters to the view.