Basic MVC (PHP) Structure

You can really put anything in a view that you'd like, but to better adhere to the MVC way of doing things you should restrict PHP in the view to simple echos or prints (possibly really small loops as well, although even those can be pre-calculated in the controller/model). Since that is the only way to get dynamic content, it would be a little silly to say that they are not allowed.

The idea of the view is to let it have a more HTML look-and-feel, so that front-end developers or people who don't know PHP can easily be able to work with the file without getting confused.

Update

To learn more about MVC in general, you can see any of these (there's a ton of tutorials out there):

http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/

http://php-html.net/tutorials/model-view-controller-in-php/

http://www.tonymarston.net/php-mysql/model-view-controller.html

To see concrete examples of PHP using MVC, I suggest downloading some of the more prevelant frameworks (such as CodeIgniter, Symfony or Drupal) and just looking through the code. Try to figure out how it works and then recreate the functionality for a simple article-based system.

Here are few things you must consider:

• You cannot do classical MVC in PHP. Instead we have MVC-inspired patterns
• There exists 1:1 relation between view and controller instances, when implemented for web
• Model in MVC is not a class. It is a layer, that contains a lot of different classes
• View is not a dumb template, but an instance of class, which deals with presentation logic

View in Web-based MVC

As stated above, views in MVC and MVC-inspired patterns are responsible for presentation logic. That encompass things like showing error messages and pagination. To do this, each view can handle several templates.

View receives information from the model layer, and acts accordingly. The way how the information from model layer ends up in views is one of most significant differences in MVC-ish patterns:

• classical MVC pattern

  Structures from model layer send the information to view, when state of model has been altered. This is done via observer pattern.

• Model2 MVC and HMVC patterns

  View has direct access to the model layer and is able to request information from it. This is the closest to the original pattern.

• MVVM and MVP patterns

  View receives information through controller, which has in turn requested it from model layer. The further difference in patterns stems from what the do with data before passing it to view.

What you seem to have now is actually just a template. Similar to one, that is described in this article. You end up with a structure, that has no place to contain the presentation logic. In long-run this will cause the presentation logic to be pushed into controller.

So what about that "welcome" message ?

To show the welcome message, your view should request from model layer the name of current user. If the model layer returns some sort of error state, view pick the error message template and inserts into the layout.

In case if name of the user was retrieved from model layer without problems, view pick the template which would contain the greeting, sets the value in the template and renders it.

In what order parts should be loaded ?

_{The idea, that controller should initialize model and view, comes from very primitive interpretation of MVC for web. Pattern know as page controller, which tried to graft MVC directly on static web pages.}

In my opinion, this should be the order:

1. Model

   You initialize the structure, through which you will deal with model layer. It most likely would be some sort of service factory, which would let you build things like Authentication service for logins and Library service for handling documents. Things like that. I wrote a bit long'ish comment on model layer's structure earlier. You might find it useful.

2. View

   You create a view instance based on information, that you collected from routing mechanism. If you are implementing Model2 or HMVC, then your view will require an instance of Service Factory in the constructor.

   If you are implementing MVVM or MVP, then view's constructor has no special requirements.

3. Controller

   This is the last structure, which you create, because controller is responsible for sending commands to both view and model layer, which then change then change the state of both. Therefore controller should expect to receive both view and service factory in the constructor.

After basic elements of MVC have been initialized, you call a method on the controller, and render current view.

Just keep in mind that this is very simplified description.