PHP & Web on PHP Boy Scout

A metaphor about PSR-7 and Middleware for non-developers

Thu, 08 Oct 2015 00:00:00 +0000

Never one to shy away from coming up with a metaphor for explaining something technical I found myself having to come up with one on the spot for PSR-7 and Middleware while at the recent PHPNW15 Conference.

Normally my brain will come up with something completely inappropriate but this time round I found I quite liked the imagery that came to mind.

If you would like to find out more of the specifics about PSR-7 you can take a look at http://www.php-fig.org/psr/psr-7/ which will make a better job of explaining it than I could ever do.

Now on to the metaphor

Imagine a house on fire, a bizarre way to start I know but bear with me. The nearest well with water that can put out the fire is 500 meters away! We then have a human chain stretching between the well and the house with a bucket going back and forth between trying to put the fire out. So lets break this down, the house represents the internet, or more specifically you and your browser. The fact you are on fire means that you are desperately needing water to quench the flames. At this point you send an empty bucket which represents your “request”, along the human chain, which in itself represents the application, to the well.

At the start of the chain the bucket is pretty normal, it’s a bucket of course, its round, made of wood with a rope handle, lets say it has a small leak in it.

As it travels down the chain it’s passed from person to person, everyone in it has the opportunity to do something with the bucket, or not as the case may be and could just pass it to the next person in the chain. Others may attempt to fix the leak in the bucket, someone may choose to replace it with a metal bucket, change the handle or make it bigger. Regardless of what may be done to the bucket in essence it remains a bucket.

Inexorably the bucket will continue to move down the chain to the well. When it reaches the well it changes state because now it has been filled with water. All of the interaction with the bucket thus far, mean that what happens at the well could vary depending on the changes have been made . If its been made bigger, for example, it could be filled with significantly more water, if swapped for a metal one it could imply that the bucket descends the well to get the water quicker because its heavier. Either way it is filled with water and begins its journey back towards the house.

Again it passes through the hands of each person in the chain, but now that its state has changed it now has the opportunity to be modified again. Someone may empty some water out as there is too much in the bucket, others may say that there is not enough and send it back down the line towards the well to be refilled. Either way the bucket continues to change hands over and over until it reaches the house and the contents are thrown on the fire to complete the request for water.

During this whole time the human chain could have been in flux. Some people may have swapped places, left the chain, added to the chain, some extraordinary people may have played leapfrog in the chain and appeared to handle the bucket more than once. Regardless of these changes the chain remains and continues to pass the bucket from one person to the another as long as the requests for water keep coming.

This, in the simplest possible form, explains PSR-7 and the concept of Middleware.

The bucket remains a bucket because PSR-7 says that is what is needed to complete the request for water, it also defines how you should interact with it regardless of what modifications have been made. If the bucket cant be used according to how PSR-7 describes a bucket to be, then the middleware can’t complete the request.

Every person in the human chain can be classed as a piece of middleware all the way from the house to the well and back again. If at any point someone enters the chain that doesn’t agree that the bucket is a bucket or doesn’t know how to handle it, then the it is dropped on the ground and the request fails.

Flexbox cross browser

Fri, 16 Aug 2013 00:00:00 +0000

Despite having been around for a while and having been through a couple of revisions, its support across browsers can vary greatly. From “Candidate Recommendation” on Chrome/Opera, “legacy flexbox” on Firefox and no support at all on IE9 and earlier.

Making flexbox work consistently across browsers was a challenge for us on a recent project, but I have found a solution that seems to work quite well.

Below is an SCSS @mixin that will attempt to handle compatibility between CR and legacy cross browsers flexbox.

@mixin flex($content: flex-start, $items: stretch, $direction: row, $wrap: wrap) {
 $packLegacy: $content;
 @if $packLegacy == flex-start {
 $packLegacy: start;
 } @else if $packLegacy == flex-end {
 $packLegacy: end;
 }

 $alignLegacy: $items;
 @if $alignLegacy ==flex-start {
 $alignLegacy: start;
 } @else if $alignLegacy == flex-end {
 $alignLegacy: end;
 }

 $oritentLegacy: $direction;
 $directionLegacy: normal;
 @if $oritentLegacy == row {
 $oritentLegacy: horizontal;
 } @else if $oritentLegacy == column {
 $oritentLegacy: vertical;
 }

/** SAFARI **/
 display: -webkit-box;
 -webkit-box-orient: $oritentLegacy;
 -webkit-box-pack: $packLegacy;
 -webkit-box-align: $alignLegacy;
/** FIREFOX LEGACY **/
 display: -moz-box;
 -moz-box-orient: $oritentLegacy;
 -moz-box-direction: $directionLegacy;
 -moz-box-pack: $packLegacy;
 -moz-box-align: $alignLegacy;
/** LEGACY **/
 display: box;
 box-orient: $oritentLegacy;
 box-direction: $directionLegacy;
 box-pack: $packLegacy;
 box-align: $alignLegacy;
/** IE 10+ **/
 display: -ms-flexbox;
 -ms-flex-wrap: $wrap;
 -ms-flex-direction: $direction;
 -ms-justify-content: $content;
 -ms-align-items: $items;
/** CHROME **/
 display: -webkit-flex;
 -webkit-flex-wrap: $wrap;
 -webkit-flex-direction: $direction;
 -webkit-justify-content: $content;
 -webkit-align-items: $items;
/** NATIVE **/
 display: flex;
 flex-wrap: $wrap;
 flex-direction: $direction;
 justify-content: $content;
 align-items: $items;
} //@mixin flex

@mixin flexItem($width) {
 -webkit-box-flex: $width;
 -moz-box-flex: $width;
 box-flex: $width;
 -ms-flex: $width;
 -webkit-flex: $width;
 flex: $width;

 min-height: 0;
}

Firefox however only half supports flexbox (all revisions) and to get around this I would recommend using Modernizr as this will add the class “no-flexbox” to the tag. This provides us with a simple work around that allows non flexbox supporting browsers render correctly by using specifically crafted and targeted CSS for non-flexbox browsers

I found that IE9 support could be implemented using the flexie javascript plugin. In IE8 Modernizr will add the class “no-flexboxlegacy” which can again allow you to create targeted CSS that wont affect your Flexbox layout.

For a great overview of the “CR” of flexbox, CSS Tricks has an amazingly comprehensive coverage of the functionality here http://css-tricks.com/snippets/css/a-guide-to-flexbox/

Creating Custom Routes in Silverstripe 3.1

Wed, 31 Jul 2013 00:00:00 +0000

We wanted to create a Route to our custom Products Controller in our products module for SilverStripe 3.1, such as: “http://www.examplesite.com/products/”

However looking at the Controller Documentation it was not clear how to create a route without an Action being supplied. In our example above the action is not specified, as we just want to use ‘view’.

Solution:

Create a /_config/routes.yml file containing the following:

---
Name: productsroutes
After: 'framework/routes#coreroutes'
---
Director:
 rules:
 'product': 'Product_Controller'
---

The above will redirect any Url that starts with “/product” to our Product_Controller. Note that everything after the rule, so after “/product”, is used in the next bit for matching.

Now we need to add private static $url_handers to Product_Controller to match our path, so in this example we need to match “$Slug!” which will match “”. Note the ! means the slug is required. Of course we want to direct this to a specific action, in this case “view”, this gives us:

private static $url_handlers = array(
 '$Slug!' => 'view',
);

Now just add “view” to the $allow_actions and add the “view” function. This gives the final Product_Controller as follows:

class Product_Controller extends Page_Controller
{
 private static $url_handlers = array(
 '$Slug!' => 'view',
 );

 private static $allowed_actions = array('view');

 public function view(SS_HTTPRequest $request)
 {
 // Your action code goes here
 return $this->render();
 }
}

Handy note:

You can put ?debug_request=1 on the end of your URL to see how it determines which Controller to use.

Disabling Cache in Silverstripe 3.1

Wed, 31 Jul 2013 00:00:00 +0000

While working with Silverstripe we found ourselves having to run “?flush=1” a lot to clear the Cache. To switch it off, while you work, add the following to your mysite/_config.php:

SS_Cache::set_cache_lifetime('default', -1, 100);

Set up SilverStripe 3.1 using only Git (No Composer)

Mon, 29 Jul 2013 00:00:00 +0000

We recently tried to use composer to set up SilverStripe 3.1, but ended up with a dependency nightmare. In order to work around this we decided to make use of Git submodules.

First set up your Git repository and run:

git init

Next set up a site directory for the code inside your Git repository. Then navigate to SilverStripe Installer in your browser and Download a copy. Extract files, and copy contents to site folder. Now we need to add the CMS and Framework. Navigate in a browser to the Git Hub repositories for CMS and Framework. Now copy the HTTPS clone URL for each project and run the following, to add these as Git sub modules.

git submodule add https://github.com/silverstripe/silverstripe-framework.git site/framework
git submodule add https://github.com/silverstripe/silverstripe-cms.git <path-to-site>site/cms

Now delete mysite/_config.php and load the site. Follow the normal install instructions displayed and you will have a running version of SilverStripe 3.1

Enabling MYSQL_CLIENT_INTERACTIVE with Doctrine 2 on Rackspace Cloud Database

Fri, 26 Jul 2013 00:00:00 +0000

We recently ran into problem using Doctrine 2 connecting to a Rackspace Cloud Database using the MySqli Driver.

Problem:

We have a long running PHP script that can sometimes run for hours at a time whilst processing information. This script requires a connection to a database, but has long periods of inactivity where there is no actual interaction with MySQL. By default MySQL uses the “wait_timeout” setting which states, how long an inactive connection can exist before it is killed. This is normally fine with web pages requests, as it is usually a short lived request. Unfortunately you do not have the ability to alter this setting when using Rackspaces Cloud Database.

Solution:

When using the MySQLi extension you can create a connection in “interactive mode” by passing the “MYSQLI_CLIENT_INTERACTIVE” flag, which will then use the “interactive_timeout” setting. On Rackspace this is set to 8 hours!

Annoyingly Doctrine does not allow you to pass any flags to the MySQLi Connection. So we overrode Doctrine\DBAL\Driver\Connection with our own Driver which then allows us to pass a “flags” parameter through.

Feel free to look at some of the other helpful features in we have added to Doctrine 2 here: ZucchiDoctrine

Installing PECL extensions for Zend Server 6

Mon, 13 May 2013 00:00:00 +0000

Recently we have revisited using Zend Server for some of our projects and decided to give the new version 6 a chance to prove itself.

Overall its a big improvement over version 5. There are still some things that are extremely annoying but we have decided that we can overlook them.

However there is one thing that we couldn’t do without. By default you will find that a number of PECL extensions will not install out of the box (at least this is what we experience using the Debian based install).

To fix this you will need to make sure you install the additional packages in ubuntu

php-5.4-source-zend-server or php-5.3-source-zend-server depending on the php version you are using
autoconf
build-essential

Once this is done you should now be able to install extensions from PECL without too much hassle.

Introducing ZuQ - A Simple ZeroMQ Queuing Daemon

Tue, 19 Mar 2013 00:00:00 +0000

We recently had the need to create a queuing system to replace an implementation of RabbitMQ that was being used on a previous project. The reasoning behind this is that the requirements of the project required a very custom implementation of a queuing system that would drastically alter in architecture as the project grew and RabbitMQ just wasn’t going to fit the bill. However to start with we required something super simple and efficient that could be expanded and developed as required. After a little investigation and a lot of recommendation from others we decided to use ZeroMQ as our transport layer for that very reason, as we could build something which could span across multiple servers and was fast.

The diagram above helps describe our basic queuing system. We have a queue daemon that is continuously listening for connections and two clients, one that populates the queue and the other that retrieves from the queue.

The Clients

Each client is written in PHP and uses a 0mq socket to communicate with a service, in this case our queue service. We used a SOCKET_REQ type of socket in order to have a request/response communication with our queue service.

function client_socket(\ZMQContext $context)
{
 // SOCKET_REQ used to create a client that sends requests to and receive from a service
 $client = new \ZMQSocket($context,\ZMQ::SOCKET_REQ);
 $client->connect("tcp://localhost:5555");
 // SOCKOPT_LINGER = 0 Configure socket to not wait at close time
 $client->setSockOpt(\ZMQ::SOCKOPT_LINGER, 0);
 return $client;
}

public function injectIntoQueue()
{
 $context = new \ZMQContext();
  $client = $this->client_socket($context);
  $msg = "This is a message";
  $retries_left = 3;
  $read = $write = array();
  while ($retries_left) {
    // We send a request, then we wait to get a reply
        $client->send($msg);
        $expect_reply = true;
        while ($expect_reply) {
        // Poll socket for a reply, with timeout
            $poll = new \ZMQPoll();
            $poll->add($client, \ZMQ::POLL_IN);
            $events = $poll->poll($read, $write, 2500);
            // If we got a reply, process it
            if ($events > 0) {
            // We got a reply from the server, must match sequence
                $reply = $client->recv();
                if (intval($reply) == $msg) {
                $retries_left = 0;
                    $expect_reply = false;
                }
             } elseif (--$retries_left == 0) {
            break;
             } else {
               // Old socket will be confused; close it and open a new one
                $client = $this->client_socket($context);
                // Send request again, on new socket
                $client->send($msg);
 }
 }
 }
}

You can see from the code above, have a 3 strike rule. The reasoning behind this is that if the client fails to connect to the queue service more than 3 times, we can stop trying to inject into the queue and move on to the next item. As we ultimately intend to adapt the lazy pirate pattern we have made it so that if the socket times out, we can then create a new socket and retry. Without this, as the architecture becomes more complicated we may then end up in a situation where we might have errors, thus the recommend solution is to create a new socket. Once the client has sent its message to the queue, we poll for a response (i.e. which is the message we sent returned back). Once we have a response that is valid, meaning that the queue has been populated, we can stop polling until the next message.

The Frontend Client

protected function getFromQueue()
{
 $context = new \ZMQContext();
 $worker = new \ZMQSocket($context, \ZMQ::SOCKET_REQ);
 $read = $write = array();
 // Set random identity to make tracing easier
 $worker->connect("tcp://localhost:5556");
 // Tell queue we're ready for work
 $worker->send("ready");
 $reply = $worker->recv();
 return $reply;
}

Our Frontend Client is much simpler as it is part of a process that is being continually updated, therefore it doesn’t need the same connection retries are the Backend Client. We simply send “ready” to the queue system and if the queue is populated it will return us the first item.

The Queuing Service

This is a continuously running executable created using c++.

zmq::context_t context(1);
zmq::socket_t frontend (context, ZMQ_ROUTER);
zmq::socket_t backend (context, ZMQ_ROUTER);
backend.bind("tcp://*:5555");
frontend.bind("tcp://*:5556");

We create two sockets of type ZMQ_ROUTER which is an advanced pattern used for extending request/reply sockets. This means when we improve our queuing system we will be able to route packets to specific recipients using an address in the message.

After creating our sockets, we initialise them

// Initialize poll set
zmq::pollitem_t items [] = {
 { frontend, 0, ZMQ_POLLIN, 0 },
 { backend, 0, ZMQ_POLLIN, 0 }
};

//poll the sockets - this seems to poll both sockets at the same time
zmq::poll (items, 2, -1);

Backend Handler

If we get a message from the backend, we check the contents to see if it contains purge at which point we empty the queue, otherwise we push the msg contents onto the queue. Finally we send the message back to the backend to show that the message has been received.

//receive msg from client
if (items [1].revents & ZMQ_POLLIN) {
 //get message from client
 zmq::message_t message(0);
 string client_addr = s_recv (backend);
 string empty = s_recv (backend);
 assert (empty.size() == 0);
 string msg = s_recv (backend);

 //allow the backend to purge the queue
 if(msg == "purge") {
 while (!queue.empty()) queue.pop();
 } else {
 queue.push(msg);
 }

 //send response back to the backend
 s_sendmore (backend, client_addr);
 s_sendmore (backend, "");
 s_send (backend, msg);
}

Frontend Handler

If we get the “ready” message from the frontend client, we pop a message off the queue and return it to the frontend client. If the queue is empty we send an “empty” message back instead.

// Handle activity on frontend
if (items [0].revents & ZMQ_POLLIN) {
 //get message from worker
 zmq::message_t message(0);
 string worker_addr = s_recv (frontend);
 string empty = s_recv (frontend);
 assert (empty.size() == 0);}
 string msg = s_recv (frontend); string queueMsg;
 if(msg == "ready") {
 if(queue.size() > 0) {
 queueMsg = queue.front();
 queue.pop();
 } else {
 queueMsg = "empty";
 }
 }
 //send reply to worker with contents of queue
 s_sendmore (frontend, worker_addr);
 s_sendmore (frontend, "");
 s_send (frontend, queueMsg);
}

That is our complete queuing system using ZeroMQ with PHP and C++.

Summary

Using the above has allowed us to create a very simple in memory queue daemon that we can use to quickly pass data from one system to a another. On the whole it works well and we are looking to expand on it in the near future to increase both its functionality and scalability.

You can find the queueing daemon (christened as “ZuQ”) on github @ https://github.com/zucchi/ZuQ

Docblock, Oh Docblock, wherefore art thou Docblock (hint: Zend Optimizer Plus lost them)

Fri, 01 Mar 2013 00:00:00 +0000

tl;dr> I make a terrible assumption about Zend Optimizer+ and am corrected by Dominic in the comments;

Terrible post title I know but its the best I could come up with.

I’ve just come up for air after spending the majority of the day debugging some issues on our current development sandbox.

Now our sandbox tends to be quite bleeding edge in some circumstances and as such we run a fair few bits of unstable code. On the sandbox in question we have been running PHP 5.4.11 and unfortunately we have struggled to get APC working with it just the way we need it to. The lack of APC tends to make this sandbox quite slow.

We recently saw that Zend have open-sourced their OptimizerPlus extension (https://github.com/zend-dev/ZendOptimizerPlus) and that it was compatible with 5.4…. Fantastic, or so we thought.

So I added the new OptimiserPlus to the sandbox and everything was going swimmingly. That was until we had to run one of the utility scripts that we use to rebuild some of our data structures. These scripts make use of different parts of both Zend Framework and Doctrine which tend to rely on some heavy DocBlock annotations.

Now having used both APC and Zend Server knowing that they done affect this kind of functionality I had expected that OptimizerPlus would be fine…. Wrongo. It took me a good few hours of head scratching trying to figure out what had happened.

It turns out that OptimizerPlus suffers from the same flaws that eAccellerator does and strips Docblocks when caching the bytecode. This results in Reflection returning false when you call methods such as `getDocComment()`.

All in all its not the end of the world I just disable OptimizerPlus and have to wait till I can get APC working. Not my ideal scenario but I can live with it.

Something that does concern me is that there is currently an RFC that has gone to vote (https://wiki.php.net/rfc/optimizerplus) about integrating OptimizerPlus into the PHP 5.5 distribution. While this is great I do worry how many other things may break and will they be picked up and fixed for the 5.5 release.

Update: Since writing this post the RFC has finished being voted upon and has been approved. You can expect to see Optimizer Plus appearing bundled with PHP soon.

Update (15th Mar 13): Thanks to Dominics’ comment I now know that you can tell Optimizer+ to retain your Docblocks by setting your config using

zend_optimizerplus.save_comments (default "1")
	If disabled, all PHPDoc comments are dropped from the code to reduce the
	size of the optimized code. Disabling "Doc Comments" may break some
	existing applications and frameworks (e.g. Doctrine, ZF2, PHPUnit)

zend_optimizerplus.load_comments (default "1")
	If disabled, PHPDoc comments are not loaded from SHM, so "Doc Comments"
	may be always stored (save_comments=1), but not loaded by applications
	that don't need them anyway.

That’ll teach me to write a blog post without investigating more first.

Debug PHP CLI on Remote Server with Xdebug and PHPStorm

Wed, 06 Feb 2013 00:00:00 +0000

This was a head scratcher when I ran into this yesterday and I thought I would share my solution to the following scenario:

I need to debug PHP Command Line script, located on Remote LAMP Virtual WebServer running in Virtual Box with a Shared Folder, using local PHPStorm 5.0.

The solution:

You first must set PHPStorm to use remote file paths. To set these go to the following:

PHPStorm -> Peferences -> PHP -> Servers

This gives the following display:

Replace the Name, Host and Absolute path on the server, to match your own settings. Note keep the Name and Host the same for ease.

Next add some breakpoints in PHPStorm and set it to listen for any debug connections using the listener icon:

Now login to your Remote Server via SSH etc.

You now need to change settings for Xdebug in either xdebug.ini or php.ini depending on how you installed it. You also need to know the IP of the local machine. This can permanently set in the Network Setting of your VM in Virtual Box, so you will never have to change it. In my example the local machine running PHPStorm is:

192.168.56.1

Now edit the ini file that contains your Xdebug settings and set the following:

xdebug.remote_host = 192.168.56.1
xdebug.remote_connect_back = 0
xdebug.remote_port = 9000
xdebug.remote_handler = dbgp
xdebug.remote_mode = req
xdebug.remote_enable = 1
xdebug.idekey = phpstorm1

Be aware you might have to change the remote_host and the idekey based on your own environment. To better understand what each option does, see Xdebug Settings

Finally, when running the script you must set the following variables:

PHP_IDE_CONFIG="serverName=dev.example.com"

PHP_IDE_CONFIG will tell PHPStorm how to map the Remote File Paths to what it sees Locally. Again replace the URL with the Name/Host you set in PHPStorm. Note: You can export this, if your system is only running one site; mine is not.

You can run this inline with your script:

PHP_IDE_CONFIG="serverName=dev.example.com" ./testscript.sh

This should send you to PHPStorm where you earlier placed breakpoints.

Happy Debugging!

Registering custom view helpers in ZF2

Wed, 18 Jul 2012 00:00:00 +0000

If you want to register custom view helpers with a module you can do so by using the service location built into the Skeleton Application and creating a module config that looks something like.

return array(
 'view_helpers' => array(
 'invokables' => array(
 // generic view helpers
 'truncate' => 'Zucchi\View\Helper\Truncate',

 // form based view helpers
 'bootstrapForm' => 'Zucchi\Form\View\Helper\BootstrapForm',
 'bootstrapRow' => 'Zucchi\Form\View\Helper\BootstrapRow',
 'bootstrapCollection' => 'Zucchi\Form\View\Helper\BootstrapCollection',
 ),
 ),
);

Bootstrapping ZF2 Forms

Tue, 17 Jul 2012 00:00:00 +0000

So…

With the release of beta 5 for Zend Framework 2 I thought it time for me to tidy up and fix a few modules I created back at beta 3.

Now I’m a big fan of Twitter Bootstrap CSS framework as I’m sure a lot of other people are as well. Seeing that the Zend Skeleton Application comes with bootstrap already included it was easy enough to set up my forms using the old ZF Forms found in ZF1.

However a brand spanking new Forms component has been rolled out with ZF2. The long and the short of this new component meant that I had the opportunity to hand roll a new way of making my forms work with Twitter Bootstrap.

So, a little tinkering, a quick pull request to ZF2 to allow the definition of arbitrary options and I came up with some useful View Helpers that can be dropped into a project and used.

You can find them at https://github.com/zucchi/Zucchi.

So how to use them. Lets start by creating a new form (we’ll keep it simple for now)

class MyForm extends Form
{
 public function __construct()
 {
 parent::__construct('myform');
 $this->add(array(
 'name' => 'price',
 'attributes' => array(
 'type' => 'text',
 'required' => 'required',
 'placeholder' => '0.99',
 ),
 'options' => array(
 'label'
 'bootstrap' => array(
 'help' => array(
 'style' => 'block'
 'content' => 'The price you wish to use'
 ),
 'prepend' => array('$'),
 'append' => array('¢'),
 ),
 ),
 );

 $actions = new Collection('actions');
 $actions->setAttribute('class', 'form-actions');

 $actions->add(array(
 'name' => 'submit',
 'attributes' => array(
 'type' => 'submit',
 'value' => 'Save',
 'class' => 'btn btn-primary'
 ),
 'options' => array(
 'bootstrap' => array(
 'style' => 'inline',
 ),
 ),
 ));

 $actions->add(array(
 'name' => 'reset',
 'attributes' => array(
 'type' => 'reset',
 'value' => 'reset',
 'class' => 'btn'
 ),
 'options' => array(
 'bootstrap' => array(
 'style' => 'inline',
 ),
 ),
 ));
 $this->add($actions);
 }
}

You’ll notice that I have highlighted some lines. Thanks to the ability to set arbitrary options we can define a “bootstrap” option which we can then use to allow us to pass data into our new bootstrap view helpers. You can also see that I have added a save and reset button to a collection. I’ll explain that later.

So what next… Rather than go into the mechanics of how to work with forms I’ll refer you to the ZF documentation and this excellent blog post

We then pick up by looking at your view, and the helpers I have created.

BootstrapForm($form, $formStyle)

One of the few things I miss from the ZF1 implementation of Forms is the self rendering aspect! So what did I decide to do? That’s right I created a view helper to render everything in one command.

The $this->bootstrapForm() takes two parameters. The first is quite obviously the form. The second is the style of form. This is directly related to the form types that can be found http://twitter.github.com/bootstrap/base-css.html#forms. You can use any of ‘vertical’, ‘inline’, ‘search’ & ‘horizontal’. If you dont specify a formStyle then it will default to ‘vertical’

Caveat: This helper will then iterate through all of the associated elements and render them first. Only after the direct elements have been generated will it then move onto Collections or Fieldsets (as soon as I work out how I’ll fix this).

BootstrapRow($element, $formStyle)

This is a straightforward modification of the FormRow helper that come bundled with the new component.

We have a few differences now though. We have a second parameter as with the BootstrapForm view helper and the output is generated using sprintf and a set of templates that mimic the structures of the different form styles from bootstrap.

This helper can be used by itself to generate an element row and is used by the BootstrapForm helper

We can also now take advantage of the “bootstrap” options we set earlier.

Bootstrap Options

style

The style of form element to use regardless of what style may be passed into the view helper (you can see an example of this in the buttons from the MyForm example above)

help

This works in the same way as “description” did from ZF1 but allows you to define it either as a string or an array with the keys “style” for either ‘inline’ or ‘block’ and “Content” which should be self explainatory

prepend

Takes advantage of Bootstraps ability to prepend blocks to an input field. This can be defined as a single string, or an array of strings to allow you to add multiple blocks should you want to

prepend

Takes advantage of Bootstraps ability to append blocks to an input field. This can be defined as a single string, or an array of strings to allow you to add multiple blocks should you want to

These options get evaluated and spat out from the new renderBootstrapOptions() method as part of the “render”.

BootstrapCollection($element, $style, $wrap)

Again this is a direct rip off of the FormCollection helper found in the ZF2 Form component witha few modifications. The main difference is that is makes use of the BootstrapRow helper and has methods and properties to allow the setting of the form style to use.

You can see from the MyForm example above that we set a Collection called ‘actions’. This is a pretty standard way of grouping elements together. You can also see that we set a class for the Collection which may look familiar to those that have used Twitter Bootstrap for a while.

What our helper will then do is wrap the buttons in a div with the appropriate class attached. If you were to define a label for the Collection/Fieldset You would then also find that the fieldset and legend tags are also spat out with our <div class="form-actions"> sandwiched between them and the elements.

Result

So what we now get when we use MyForm with out helpers.

$this->bootstrapForm($form, 'horizontal');

Should now look something like this

How you can use it

As of right now you can get the library from its repo on github @ https://github.com/zucchi/Zucchi and can be found on packagist for use with composer

Edit: The bootstrap stuff has moved to a new location as a separate ZF2 module. you can find it @ https://github.com/zucchi/ZucchiBootstrap or @ packagist for use with composer