The Twitter Bootstrap css library is a great starting point for putting together nice looking web apps. We’ve found it very useful for building wireframes quickly. Giving clients something they can actually use and click on in a web browser is wonderful. The bootstrap has many different UI elements that can be combined to build great looking views. Naturally, having a view helper in CakePHP to construct many of the reusable elements would be nice.

Twitter Bootstrap Helper

Thats where the Twitter Bootstrap Helper comes in. The helper is a collection of methods that build many of the reusable blocks of markup in the bootstrap.

Bootstrap Labels

The first of the reusable elements in the bootstrap are the stylized label blocks. These are small bits of text that have a colored background. The label() method takes a string message and a label type. The valid types are “warning”, “success”, “important”, “notice” (passing no type adds no extra class so the background is grey).

echo $this->TwitterBootstrap->label("Label Message", "warning");

Bootstrap Form Methods

Twitter Bootstrap comes with excellent form and input styles. The default markup that the FormHelper::input() method generates doesn’t match what the bootstrap styles need. We’ve added an input() method to build the appropriate markup. This method takes two params; the field and an array of options.

echo $this->TwitterBootstrap->input("field_name", array(
    "help_inline" => "Inline help text",
    "help_block" => "Block help text"
));

This method could optionally take a single param as an array. You can also pass in the input that will be used, if you need to set special options on the field like a class or id.

echo $this->TwitterBootstrap->input(array(
    "field" => "field_name",
    "input" => $this->Form->text("field_name", array("class" => "field-class"),
    "help_inline" => "Inline help text",
    "help_block" => "Block help text"
));

The Twitter Bootstrap styles has some awesome button styles. Use the button() method to display submit buttons for the form. These take all the same options as the FormHelper::button(), as well as the “style” and “size” options.

echo $this->TwitterBootstrap->button(
    "Button Text",
    array("style" => "primary", "size" => "large")
);

Bootstrap Links

The same styles that can be applied to buttons can also be applied to links. The button_link() method takes the same parameters as the HtmlHelper::link() method, and allows for the same extra options from the button() method (”style” and “size”)

echo $this->TwitterBootstrap->button_link(
    "Link Text",
    "/path",
    array("style" => "info", "size" => "small")
);

To go along with the button_link() method, there is also a button_form() method that uses FormHelper::postLink() to build the link. Now you can build links that use other HTTP methods other than GET (think a red delete button).

echo $this->TwitterBootstrap->button_form(
    "Delete",
    "/path/delete/id",
    array("style" => "danger", "size" => "small"),
    "Are you sure?"
);

Bootstrap Alerts

The bootstrap styles have great alert styles. They work great as replacements for the SessionHelper::flash(). The alert() method takes a sting of content and an array of options. Optionally you can pass in a “style” option to change the colors of the alert, and also a “closable” option to have the close link render as well.

echo $this->TwitterBootstrap->alert(
    "Alert message.",
    array("style" => "success", "closable" => true)
);

There is also a flash() method that will use the alert() method to render the content of the flash method in the session. This will render the “flash” key by default (which uses the “warning” style).

echo $this->TwitterBootstrap->flash();

A style that we’ve started using is to set the flash message in the controller with the 4th param being the style you’d like the flash to have.

$this->Session->setFlash(__("Flash message."), null, array(), "success");

A convenient method for rendering all the flash methods that have content is flashes(). This will loop through the valid styles (success, warning, error, info), flash, and optionally auth (if “auth” option is passed with value of true), and call the flash method for each of these keys. If there is any content for those keys in the session.

echo $this->TwitterBootstrap->flashes();

Add this one method call to your layout file and then you can set the type of flash to show from the controller. If there are errors, call setFlash() with the key “error”, and if a save was successful, use the “success” key.

The other type of alert in the Twitter Bootstrap is the block alerts. The block() method takes a content string which can (and should) contain markup. The second param is an array of links. Use the button_link() or button_form() methods to fill the block actions container. The last param is an array of options, and the valid options are “style” and “closable”.

echo $this->TwitterBootstrap->block(
    "Content for block message.",
    array(
        $this->TwitterBootstrap->button_link("Action in block", "/path"),
        $this->TwitterBootstrap->button_link("Another action", "/another/path")
    ),
    array(
        "style" => "success",
        "closable" => true
    )
);

That covers the basic usage of the Twitter Bootstrap CakePHP Helper. Using these methods means you’ll not have to remember all the specific class names to achieve certain styles when using Twitter Bootstrap.

Twitter Bootstrap 2 has released, and we are working on upgrading the Twitter Bootstrap CakePHP Helper to be both backwards compatible with the version that uses Bootstrap 1.4, as well as expose new methods for the newer features. Be on the lookout for another post detailing the specifics of the Twitter Bootstrap CakePHP Helper 2.

Joey Trapp
Project Manager / Web Developer
@joeytrapp
https://github.com/joeytrapp 

The metadata plugin simplifies the setting of HTML page meta data. Web site meta tags are often the same for every page, but a few could vary between requests. The purpose of the metadata plugin is to eliminate view or layout logic for setting meta tags data. It is also meant to encapsulate the static meta tag content from controller logic, while still allowing for tags to be overwritten conditionally in the controller.

There is a simple way to use this plugin without much maintenance for the duration of the project. After including the plugin, simply include the component.

public $components = array(‘Metadata.Metadata’);

The meta tags data can be completely encapsulated from the controller logic by including a metadata.php file in app/config/. This file will automatically get included and meta tags can be created from the data contained. In the metadata file, site global, controller global and action specific properties can be set (in the case of the PagesController, the page file can be set instead of actions).

// app/config/metadata.php

$metadata = array(
	‘_all’ => array(
		‘description’ => ‘Site wide description’
	),
	‘pages’ => array(
		‘_all’ => array(
			‘description’ => ‘All pages_controller pages description’
		),
		‘home’ => array(
			‘description’ => ‘Home page description’
		)
	),
	‘controller_name’ => array(
		‘_all’ => array(
			‘description’ => ‘All controller_name actions description’
		),
		‘action’ => array(
			‘description’ => ‘controller_name/action description’
		)
	)
);

By having all of the meta data in the a config, the data can be semi dynamic for different pages without having to build controller setting logic or have any additional logic in the view. In some cases, though, it will be necessary to set a meta tag data from within the controller. The Metadata component exposes a method for setting meta tag data manually. Any data set this way will overwrite data that for the same key that might already exist.

$this->Metadata->metadata(‘description’, ‘Manually set description’);

or

$this->Metadata->metadata(‘description’, array(
‘content’ => ‘Manually set description’,
‘http-equiv’ => ‘content-type’
));

Note: Metadata can be set as an array like the second example above, even in the metadata.php, as long as a content key exists in the array. All additional keys will be passed as attributes in the helper.

So far, so good. We can now get rid of all the logic in the controllers regarding metadata. We can also get rid of any sets in the view that set data for the layout to render. All the metadata information is set in the metadata file, or overwritten in special cases in the controller. But how is all of this metadata rendered? Short answer:

<?php echo $this->MetaData->meta(); ?>

The Metadata plugin comes with a Helper also named Metadata. The helper is automatically added to the controllers $helpers property. While adding the helper, the component also passes along all of the metadata keys that have been added up to that point (this happens in the Metadata component beforeRender()).

By not specifying any parameters, the helper’s metadata() method will loop through all data passed in from the controller, and render the data using Html->meta(). The metadata method can also take parameters and pass them along to the Html->meta() method if you’d like to stick to a single method for handling meta tags data.

Another method exposed by the metadata helper is the title() method. If at any point, metadata is set with the key “title”, that data is set aside in the helper. To render the title, use the title() method. The first two parameters are a default title, and a boolean merge option. If a default title is passed and merge is set to true, the return will be the combination of the title set in metadata and the passed in default title (an example would be a site wide title and a post, newsletter, etc title contained in the data layer).

The Metadata plugin is meant to be an alternative to having to manage metadata database tables. In many sites, a full model/behavior solution may be too much. This plugin was the solution that best fit one of our projects, and we hope it comes in handy for some of you.

Then code can be downloaded or cloned from here: https://github.com/joeytrapp/metadata