Views in Sodapop consist of two different components: the view class (a subclass of Sodapop_View_Abstract) and a template file. If layouts are being utilized, there will also be a layout template file.
Back in the bad old days of PHP development, it was common to mix business logic and markup within the same script file. Often, developers would include() some common files near the top of the script, process form inputs, write a bunch of SQL code, and iterate over result sets to create the HTML for the page. This made for a sloppy separation of concerns and difficult debugging and maintenance. Figuring out why an application behaved as it did required digging through all of this mixed code.
Views clean this up considerably by placing the business logic in the Model layer and Controller layer. 1 The view is left to deal only with generating HTML, JS, and CSS. The use of template files and locally-scoped variables completes the separation by removing any markup from PHP code.
Using the default routing behavior, the controller would be defined in a file in the /controllers directory, named based on the desired URL structure. In this example, the path would be something like:
The Controller: /controllers/PostController.php
The Layout: /layouts/layout.php
The View: /views/post/view.php
In the example, variables are assigned to the View on line 9 of the controller file. Within both the layout and view templates, the variables can then be accessed from the $this object, as seen on line 3 of the layout and lines 2, 3 and 7 on the view template.
Also worth noting is the reference to $this->baseUrl on line 2 of the view template. This is a special property of the view which points to the root directory of the application from the perspective of the web server, and should be used when building links to other pages on the site.
Even if you do not intend to use themes, it is highly recommended that you use $this->themeAssetRoot when building links to static assets for maximum future flexibility.
Sometimes it is helpful to be able to add a chunk of HTML to different pages on a site, or several times on the same page, without needing to retype it each time. For this, Sodapop supports partials.
The partial template is called like any other view, and has the same context and variables as the view template it appears in. The convention is to begin the view name with an underscore but it isn't strictly required.
Sodapop defaults to using a view template named after the action in a directory based on the name of the controller. 2 It is possible to change this from within the controller through changing some properties of the controller.
The above example shows three different things. It's unlikely that each of these will be done within a single controller action, but they are presented here for brevity.
Layouts are turned on by default, but can be disabled with a sodapop.json configuration setting.
As layouts are used for all actions within a controller, it is often helpful to assign variables to them within the preDispatch() controller method rather than doing it in each action. More information about how Sodapop handles requests is available in the Controllers documentation.
By default Sodapop uses a subclass of Sodapop_View_Abstract called Sodapop_View_Simple, which provides a very simple, PHP standard experience. It is possible to define other subclasses that use different templating engines and use them through setting the appropriate sodapop.json configuration setting.