In my last post I talked about the Concrete5 CMS. In this post I want to introduce you to the Concrete5 MVC (Model View Controller) model of coding that it adopts.
It took me a while to grasp this concept, but now I think I get it so here it is:
The Model is the code that interfaces to the database for a group of functionality e.g. it responds to requests for data or stores data in the database.
The Controller is code that runs every time a particular page is accessed on the site. But it doesn’t render anything directly to the browser window. In particular, it processes POST data sent from forms.
The View is the code that renders the inner content of a web page. So it contains HTML and PHP snippets to insert dynamic data. The template in the theme actually inserts the view in a particular spot.
As you may see, this makes it easy to separate out the functionality of your code so that complex web applications become simplified.
So every page in your web application may have a model, view and controller PHP file. These are placed in similar directory positions to how the actual web page in the site map is positioned. So the Concrete5 script looks for your MVC files in the appropriate locations when loading a page. But they don’t have to exist.
Where you want to re-use functionality on multiple pages, you should create a block. This encapsulates the MVC scripts and even database table definitions and allows for the block to be dropped into pages in content placeholders.
But wait, there is more …
Helpers are pieces of code that help you simplify your other code by encapsulating functions such as say a password generator. So these helpers can be used site-wide.
Tools I think are for where there is no other logical place for a functional code module to reside.
Files are any files that may be uploaded or deposited to deploy.
Now I am diverging away from the original topic of Concrete5 MVC, but I hope I helped you understand it a little better. And I must say that the developer Docs are great, so do study them well.