Views

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.

What is a View?

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.

An Example

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:

http://example-domain.com/post/view/slug/this-is-my-post-slug

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.

Similarly, $this->themeAssetRoot on line 7 creates a dynamic link to your theme's /www directory, which is appropriate for loading static assets like images, Javascript files and stylesheets. If the application's /www directory is writeable by the web server, it will dynamically create a symlink to the theme's asset directory which will result in a substantial speed increase for loading static assets, as they will then be served by the web server directly rather than through PHP.

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.

Partials

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.

Changing Which View Template is Used

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.

  • On line 6, the view file is changed to /views/post/a_different_view.php. 3
  • On line 9, the layout file is changed to /layouts/another_layout_template.php.
  • On line 13, no view file is used at all. Rather, the string specified is echoed out directly. (On line 13, a header is set so that the browser interprets the JSON string correctly. This isn't strictly required but is recommended. Calling $this->render() directly from within a controller action will automatically prevent a view template and layout from running, and can only be called once per action.

Layouts

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.

Other Template Engines

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.