CCAPS

=How To Get Started with PHP CCAPS=

CCAPS, or Carefully-Controlled Alternative PHP Syntax, is a web template system alternative to template engines such as Smarty and CakePHP. CCAPS, pronounced Cee-Caps, is what PHP web developers can use to separate XHTML source from programming logic, yet glue the two together nicely without introducing spaghetti code.

Preference
Many developers prefer it to engines such as Smarty because:


 * it is thinner in architecture and therefore runs faster
 * uses concepts most PHP developers already know
 * PHP is already a great templating engine
 * PHP already provides conditional and control flow features
 * requires no extra installation step
 * guarantees you that it won't break on your server because it includes no extra libraries -- no function add-ons to ensure you have installed
 * it is more adaptable

Guidelines
PHP already has an Alternative PHP Syntax, but what CCAPS does are the following guidelines:


 * The template pages end in the file extension ".php" unless other arrangements make it possible to load these into one's editor with proper colored formatting of source, and unless Apache directives permit certain other file extensions to be processed like PHP pages.


 * Templates go into a folder called "views" and has Apache access controls so that the pages can be included, but not viewed directly by end users.


 * All template file names must begin with a lowercase "v" for "View". In an MVC framework, a template is a view. For instance, a file could be named vLogin.php. The "v" helps one delineate easier in a text editor between the view and the page controller, which might be called, for instance, Login.php.


 * In order to get PHP values into the XHTML, PHP constant variables are used. PHP constant variables are only included in the XHTML in uppercase so as to make them easy to spot in the usually lowercase XHTML source.


 * The PHP constant variables are included as <?= MYVAR ?> so as to use the fewest keystrokes possible, rather than . If this requires alteration in Apache settings, or in how the PHP is compiled of configured, then this is accommodated.


 * As a ground rule, only three (3) if/then conditions are permitted in a given XHTML page. If more are necessary, then it is strongly recommended that these be moved into separate smaller view files, or that the XHTML be composed inside the calling page's programming logic via a function or object method, and then passed down into the XHTML template as a single variable. This keeps the source clean and makes it easier to edit.


 * Nested if/then conditions are strongly discouraged and, if necessary, one should make XHTML inside the calling PHP page (the page controller) and pass to the view for insertion.


 * If/then conditions are only permitted using alternative syntax style without the curly braces, such as:

<? if (TAB == 'main'): ?> <? else: ?> <? endif; ?>


 * No loops are permitted whatsoever. Instead, this functionality must be created in the calling page's programming logic, usually through a contained function or object method, and then inserted as a single, capitalized variable in the XHTML source of this page template.


 * No other conditional logic is permitted besides if/then, such as select/case logic. Instead, this logic must be implemented in the calling page.


 * The templates should include a header or footer in a separate file. This file is usually capitalized such as vHEADER1.php, vFOOTER2.php so as to make it more easily found in the templates folder.


 * For pages that require a sidebar, this is probably more suited to being composed as a smaller view file and included as such.


 * Often it is suitable for a class of static methods be composed in PHP to address this template, such as...

View::Assign('MYVAR','This is my test'); View::Display('vMain.php');

...whereas the Display method automatically assumes vMain.php is in a subfolder called "views".


 * Another guideline is a word of caution. Since we use constants, you will need to watch out for PHP's little-known feature where if you try to display a constant that is not defined, it displays the variable name instead, which may be completely unexpected and erratic. So, if you only do a View::Assign on a variable with an if/then condition, and not provide that same View::Assign to make an empty value pre-defined constant, then PHP will automatically display that constant as its own variable name. Therefore, watch out for...

 <?= ERRORMSG ?>

...which would cause the word 'ERRORMSG' to appear on the page. The fix is this:

 <?= ERRORMSG ?>

Installation
Most PHP installations already support CCAPS and do not require additional libraries to be installed.

Sample View Class
A sample View class could look like the following.

<?php class View { const ENCODE_DEFAULT = 0; const ENCODE_HTML = 1; const ENCODE_URL = 2; function Assign($sVarName, $sVal, $nType = self::ENCODE_DEFAULT) { switch ($nType) { case self::ENCODE_HTML: // show the html $sVal = htmlentities($sVal); break; case self::ENCODE_URL: // prepare for urls $sVal = urlencode($sVal); break; default: // 0, default, as is, unaltered break; }    $sVarName = strtoupper($sVarName); define($sVarName, $sVal); } function Display($sTemplateFile) { $sScriptName = $_SERVER['SCRIPT_NAME']; $sBaseName = basename($sScriptName); define('U',str_replace($sBaseName,'',$sScriptName)); $sPath = dirname(__FILE__); $sPath = str_replace('classes','',$sPath); require_once($sPath . 'views/' . $sTemplateFile); } }

So, as an example, you could have a test.php which looks like:

 Test <?= TEST ?>

Notice how we use TEST instead of $TEST. This is because it's a constant. This not only discourages abuses that could lead to spaghetti code, but also runs a lot faster than if we used a global variable array technique in our View class to load and unload variables as they are passed from one PHP page to another.