What is Wireframe?
If you've been around ProcessWire for a while, there's a good chance that you're familiar with the concept of output strategies. This refers to the way you organize your template files – the files that typically contain both markup generation and backend code (so-called business logic) for your site.
Wireframe is an output framework for ProcessWire. It provides you with a way to build ProcessWire powered sites using a model-view-controller inspired architecture, proper separation of concerns, and other software development best practices.
Wireframe is easy to get started with, yet it provides developers a solid foundation for building all types and sizes of websites.
Who is it for?
Using Wireframe is pretty easy, so technically it's a tool for anyone interested in developing a ProcessWire powered website (or web app). That being said, if you're interested in taking one of the existing site profiles, making slight modifications to the front-end, and calling it a day — well, you may be better off looking at other solutions.
On the other hand, if you're interested in building something neat yourself and applying a software development mindset to your ProcessWire based projects, you're likely going to enjoy working with Wireframe.
Show me the code!
By now you're probably itching to see some code? No worries, we're almost there.
The very last thing to mention before we get our hands dirty (figuratively speaking) is that Wireframe consists of a set of core concepts and files, all of which serve their own purpose in the greater scheme of things: the bootstrap file, controllers, layouts, views, partials, and components.
The last four, when put together, form the "View layer". There's also an object called "View", which functions as the glue — or gateway, whichever analogy makes more sense to you — between the backend (controllers and the bootstrap file) and the front-end.
The bootstrap file
The Bootstrap file is responsible for initiating the Wireframe module. Wireframe makes use of the "alternate template file" setting native to ProcessWire, and by selecting the bootstrap file as the alternate template file for your templates, you can "route" requests through this file. The bootstrap file then boots up and configures the Wireframe module.
Any variables we pass to the Wireframe::render() method from this file become available in the View laye (your layouts, view files, and partials).
/site/templates/wireframe.php
<?php namespace ProcessWire;
// init Wireframe
$wireframe = $modules->get('Wireframe');
$wireframe->init();
// render the page (the render method takes an array of optional arguments
// for use in the View)
echo $wireframe->render([
'lang' => 'en',
]);
Note: while usually you'll only have a single bootstrap file, that's not a hard rule by any means. If you want to, you can have more than one of these, each with their own settings.
Controllers
Controllers are optional components, basically something to mediate between View and model (latter of which means ProcessWire itself). In Wireframe the controllers are where your business logic lives. Controllers are PHP classes named after the templates they relate to: the controller for the home template should be called HomeController, etc.
/site/templates/controllers/HomeController.php
<?php
namespace Wireframe\Controller;
/**
* HomeController is the Controller for the home template
*/
class HomeController extends \Wireframe\Controller {
/**
* Render method is executed right before the view is rendered
*/
public function render() {
// Send a list of child pages to the View
$this->view->children = $this->page->children;
}
/**
* Public controller methods become accessible as params in the View, which
* means that you can access them from your layouts, view files, and partials.
*
* @return string
*/
public function login_status() {
// Pass user name to the view
$out = 'Not logged in';
if ($this->wire('user')->isLoggedin()) {
$out = "Logged in as " . $this->wire('user')->name;
}
return $out;
}
}
Layouts
Layout files – of which your site can have only one, none at all, or multiple – are usually where the "shared parts" of your front-end live. Wireframe promotes this pattern instead of including separate header and footer partials in all of your view files, mainly for the sake of maintainability. (Your layout and view files can make use of as many partials as you need, though.)
Oh, and that <?= $placeholders->default ?> request below? That's how you define a slot for page content. You can have multiple placeholder slots, but the "default" one is often quite enough.
/site/templates/layouts/default.php
<!doctype html>
<html lang="<?= $this->lang ?>">
<head>
<title><?= $page->title ?> | <?= $this->site_name ?></title>
</head>
<body>
<?= $placeholders->default ?>
</body>
</html>
Views
Views are template-specific and typically represent a single page when it's rendered on the site. Each template could have multiple views, which effectively allows you to render the same page in different ways depending on some sort of switch (usually implemented within the controller class for that template.)
Just for an example your home template could have a default HTML view, an RSS view, and a JSON view for some sort of API to consume. You could use URL segments to pick the appropriate view, or you could always respond AJAX requests with JSON data, etc.
/site/templates/views/home/default.php
<h1><?= $page->title ?></h1>
<div class="body">
<?= $page->body ?>
</div>
<div class="login-status">
<?= $this->login_status ?>
</div>