course when you register on learnphalcon
The examples on this site are currently tested to work on Phalcon V3.4 and Phalcon Devtools V3.2 Some issues may arise when using later versions.

Please get in touch or post a comment below the post if you encounter a problem.

In the early days of the web websites consisted of relatively few pages so managing the content was a relatively straightforward task. As websites grew to dozens and even hundreds of pages this task became more challenging.

If a navbar which appeared on every page in the site needed to be updated this could mean having to update hundreds of pages which contained the navbar.

Server Side Includes and Frames were some of the approaches used in the early days to allow navigation bars (and other content which appeared on every page) to be stored in separate files and included or pulled-in to the other pages on the site. 

This allowed authors to update the content in one place and have those changes propogate through wherever that content was repeated.

This basic idea is crystalised in the DRY principle. "Don't Repeat Yourself". Wherever content is the same it should be referenced and pulled-in rather than copied. As a programmer or web-author once you get into duplication of code or content you start to create a tangled mess where it becomes hard to keep track of where everything is duplicated and errors are commonplace.

As a website grows to dozens or even hundreds of webpages it may be necessary to assign the resposibility for the management of different sections of the site to different individuals.

A typical website will have an overall navbar and possibly different sub-navbars for different sections of the site. In order to avoid having to change hundreds of pages if there is a slight change in the navbar we need to have I single location where aspects of the website which are to appear on all pages is managed.

Using this approach any changes to the navbar this need only be made in that one file and all the other pages will effectively "inherit" these changes.

Modern MVC frameworks use a View inheritance model to achieve this re-use and easy management of the site content. The basic standard inheritance model has three levels of inheritance.

At the top level the /app/views/index.phtml or /app/views/index.volt file contains content which, by default, will appear on every page. This is where you will put your main navbar. It is possible to include conditional logic in here so users may see a different version of the navbar depending on if they are logged in or what their role is.

The next level down is the layout. This will be stored in the /app/views/layouts folder. Each layout corresponds to a Controller and must be named to correspond to the controller name in order to work. For example, the CustomerController will have a corresponding layout called either /app/views/layouts/customer.phtml or /app/views/layouts/customer.volt. Any View logic or content contained in this file will be pulled in by any of the actions in the customer Controller.

At the final level is the view itself which corresponds to the action from the relevant controller. In this example where the editAction is called the user will see the view associated with the editAction( ) function (either edit.phtml or edit.volt depending on which template engine the programmer has chosen to use). The final view the user sees when accessing /views/customer/edit.phtml will also display content from /views/layout/customer.phtml and content from /views/index.phtml

It's worth noting that programmers can use either volt or phtml for any or all of the individual view files. They can mix and match. Within a given phtml or volt file the filename must have the appropriate extension and the code must be either all phtml or all volt.

The programmer can control where the code from the inherited view appears on a page relative to the other content through use of the <?php $this->getContent() ?> function. This function pulls-in content from the other views in the hierarchy. It's equivalent in volt is {{content}}

The final view associated with the action also needs <?php $this->getContent() ?> - this will pull in additional information such has flash error messages which are set in the Controller.

It's a good idea to place the content into a div container to give you more control over how it renders relative to the other content on the page.