Posts Tagged ‘PHP’

I’m a big fan of the Flight PHP micro framework, and it’s built-in views component is quite nice when you want to do stuff in a rush.

But recently I have started to use Slim more often as it has almost out of the box support for Mustache templates, whereas Flight does not.

Until now, that is. I wanted to use Mustache with an existing project I had already coded up in Flight, so I’ve now written a wrapper for it and released it on Github. It’s nothing fancy – probably less than 100 lines of code in total. But it seems to get the job done.

So if you’re looking to use Mustache templates in your Flight application, why not give it a go? If you have any improvements, you can always fork it too!

The first thing you probably think about when I mention Mustache is, “you’ve spelt moustache wrong.”

You would be right. But although the creators of such a project clearly do struggle with proper spelling even more than I do, they have never the less created something really interesting – logic-less templates.

Mustache is a templating system, similar to Smarty or Twig, that was originally written for Ruby and has since been ported to almost every other popular language under the sun (it has not been ported to any languages that exist outside our solar system, to my best knowledge).

The idea is that you separate out your logic from your template. So you would have a view class which handles the logic, and then the actual template file which has your presentation in. Why this extra layer of complexity though?

Well the problem with templating systems such as Twig is that they actually aren’t as separate as we like to think they are. You have control statements like looks and if statements, and then people started adding helpers to templating systems where you could call functions and even pass parameters! This made it a lot easier for us to write the view, but by the time you’ve added all that in, why not just place the PHP directly inside the template – it would be just as simple.

Mustache does a way with all that. In Mustache there are two main types of tags you can have – variables and sections. A variable is a straight replacement in double brackets {{like this}}. Sections contain one extra character so you might have a {{#section}} that wraps this text{{/section}}. A section can then be repeated zero or more times depending on whether you pass it a false value, a true value or an array.

There are a few other tags but this for the most part is everything! You don’t have the complicated control statements, the helper functions or other such syntax to deal with – inside a section which repeats from an array for example, you just call the key name, without having to specify the array variable every time. See the example below.

In Twig, you would do this...

{% for item in list %}
{{item.name}}
{% endfor %}

In Mustache, you just do this...

{{#list}}
{{name}}
{{/list}}

You can argue that there is added complexity in having to create an accompanying view class – and you would be right. But this is optional, and only required if you need to do view-time processing – passing an associative array, just like you would with Twig, works fine too!

I highly recommend giving Mustache a go, I was skeptical at first but once you dive in it really produces some beautifully clean code.

Slim is a PHP micro framework, similar to Flight, Silex and Limonade, not to be confused by the Ruby templating system of the same name. It claims to contain “everything you need and nothing you don’t.”

If functions like you would expect a micro framework to work. Here is the standard example.

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

My favourite part of Slim, however, is actually the Slim Extras bundle which doesn’t ship with it, but can easily be downloaded and dropped in. This adds easy integration for lots of different templating languages – notably Smarty, Twig and Mustache.

So, for example, if you wanted to integrate Twig, just grab the Extras bundle, the Twig bundle, include the relevant file and change your initialisation statement to the following.

$app = new Slim(array("view" => "TwigView"));

That’s all – now you’re away and can call the render method with a filename and data array to render a template using Twig.

Symfony2 has a very nice Validator component for data validation. As with most of the components, it can be used outside of the framework, but unfortunately, the documentation on how to do this is rather lacking. Indeed, even using it within Symfony but outside the controller can be difficult and this is made especially difficult if you’re using Propel because you can’t use annotations.

However, it can be done, and this tutorial will show you how.

When using the validation component somewhere other than in a Symfony2 controller (be that in an entirely different project, or just in a custom class inside the framework), the problem is that you don’t have access to the service container. So we need to create the object for ourselves.

Lets start by importing the namespace into our class.

use Symfony\Component\Validator as Validator;

This will give us quick and easy access to the Validator classes. Now we can use the ValidatorFactory to generate a validation object.

$factory = Validator\ValidatorFactory::buildDefault();
$validator = $factory->getValidator();

This is good. It means we now have a validation object that we can run against annotated classes. But what if we are using Propel and need to specify our validation rules in a YAML file?

$yamlFile = "../src/Acme/DemoBundle/Resources/config/validation.yml";
$factory = Validator\ValidatorFactory::buildDefault(array($yamlFile), false);
$validator = $factory->getValidator();

Now we can use the rules we specified in the YAML file to validate our Propel classes.

$violations = $validator->validate($model);

Splendid, we’re done. One further trick I’ll throw in with this post – what happens when you need to validate multiple objects and give a combined list of errors back? Because the list we get back is a custom object, we can’t just array_merge the two $violations list. But luckily, there is a function in the object to do this.

$violations = new Validator\ConstraintViolationList;
$firstViolations = $validator->validate($firstModel);
$secondViolations = $validator->validate($secondModel);

if ( count($firstViolations) > 0 ) {
	$violations->addAll($frstViolations);
}

if ( count($secondViolations) > 0 ) {
	$violations->addAll($secondViolations);
}

That will return you a single ConstraintViolationList that you can iterate through, containing errors from both models.

I’ve recently written about Flight and Silex, so continuing the PHP micro framework theme, this post is looking at Limonade.

I had heard mixed reviews about it before I first began exploring the framework, and that pretty much sums up how I feel about it too. It does what it needs to, but there is nothing spectacular about it and given the choice, I would rather work with something like Flight.

It offers similar functionality, with an integrated views system, though without the object orientation you would expect, which makes it more similar to Sinatra. It also has a good range of hooks to allow you to extend functions by inserting code before and after.

Documentation for Limonade is a little hit and miss. There is quite a lot of it but it isn’t very well organised. If something isn’t in the main readme, you often have to go hunting around the examples folder until you find what you want. In its defence though, there is a lot of ground covered in the readme.

You can download it and have a play around from the Limonade website.

Recently I wrote about the Flight PHP micro-framework. One of the challenges I ran into when launching one of our sites in it was that we had some database information that needed to be pulled out in the layout.

It was the same information on every page so it didn’t make sense to pass it in as a variable as this would have meant using the same code on every route to do the same thing. Instead, it was simpler to create a view helper which would pull out the information needed.

class Helper {

	public static function menuTags () {
		$tagModel = Flight::tagModel();
		return $tagModel->findDistinct();
	}

}

Nothing fancy here, just a static method on a class which hooks into one of the model classes I has already registered with Flight and returns the result. I then just needed to reference this from the layout view.

<?php foreach (Helper::menuTags() as $tag) { ?>
<?=htmlspecialchars($tag["tag"])?>
<?php } ?>

Now it appears on every page without me having to pass it in as a variable.

Flight is another micro framework written in PHP and bills itself as being extensively extensible.

Like other such frameworks, you begin (and arguably end) by creating a series of routes and adding closures to those routes that present the actions and outputs of said route. The quintessential example being as follows.

Flight::route('/hello', function(){
	echo 'Hello, World!';
});

The routing works really well using the simple format that allows you to name and route and add a regular expression match in one simple statement.

Flight::route('/article/@id:[0-9]+'

You don’t have to use closures either – any callable object can be used, so you can write a separate function and call it from multiple routes – useful if you have multiple, entirely separate patterns to match where it doesn’t make sense to do it all in one regular expression.

Flight has a simple built-in views system which allows you to render a view (which just uses PHP files to keep things simple) and pass an associative array of variables in which then translate to variables which you can use in the view. Layouts are also supported.

Its real power though is in how you can extend it. You can easily write your own classes and call them into your Flight methods using its register function.

Flight::register('db', 'Database');
$db = Flight::db();

This doesn’t just apply to new classes – you have override the Flight classes with your own if you wish to as well. Flight goes far deeper though, allowing you to do what it describes as filtering, a system which allows you to insert hooks before and after functions.

Flight is a great little framework, and one to rival Silex.

The Symfony2 framework comes with a really nice validation library and on top of the built in constraints that you can use you also have the ability to add your own custom constraints to perform any other validation checks you need to do.

The Cookbook has an article on how to create such a custom constraint, but unfortunately, as has happened a few times with the Symfony2 documentation, it misses out some fundamental and sometimes rather obscure step in order to get it working.

The problem is, it doesn’t tell you where to put the files. That leaves two options – either you have somewhere they need to be in order for Symfony to find them, or you need to fell Symfony where they are.

After hours of digging around, we eventually found the answer – in your validation.yml file you need to register the namespace and then reference that name when you call the validation rules.

Start by registering the namespace at the top of your validation.yml file.

namespaces:
  myValidator: Acme\ExampleBundle\Validator\

Lets say you have added a custom validation constraint called Postcode. When you want to invoke that from your validation rules, you need to reference the namespace you have just created.

postcode:
    - myValidator:Postcode: ~

You can then use this namespace with your custom validation rules, place them in the appropriate directory (in this case src/ExampleBundle/Validator, but you can store them somewhere else if you change the namespace – remember that Symfony2 will extract the path from the namespace).

Last month, I went to a talk by Richard McIntyre on “The Future of PHP”.

Turns out, it’s JavaScript.

More and more these days, web applications are being developed with fat front end clients loaded with JavaScript, and the server-side processing is primarily used for data processing and APIs. So we’re seeing a shift from PHP being used as a somewhat front-end technology to merely (I say merely, there is a lot of work to do it) delivering the content in a format the JavaScript front end can consume.

Perhaps this is why we’ve seen a rise in the number of microframeworks, such as Silex, that I recently blogged about.

I think the overriding message I took away from the talk though is that they’re inventing development platforms faster than I can learn them! I’ve already got a large list of technologies and libraries I need to review and I think I came away from this talk with another half a dozen!

Really enjoyed the talk though, and if you’re interested in PHP and in the Leeds area you should definitely check out the Leeds PHP User Group who host such events on a monthly basis.

Silex is a PHP microframework based on Symfony2 components.

With the shift in recent years to leveraging more JavaScript and front-end code in fat clients, a lot of server-side processing has been reduced to simple data relay and APIs. As a result, there have been a number of microframeworks arisen, which allow you to serve out content in a really simple and easy way.

One of the most popular is Sinatra, a micro-framework for Ruby, which is what we built Village Chief on. Indeed, Silex is inspired by Sinatra, but is PHP-based and uses some of the great components that can be found in the Symfony2 framework.

As you would expect from a microframework, it’s really easy to get started.

<?php
require_once __DIR__.'/../vendor/autoload.php';

$app = new Silex\Application();

$app->get('/hello/{name}', function ($name) use ($app) {
    return 'Hello '.$app->escape($name);
});

$app->run();

It relies heavily on Composer, a PHP dependency manager. This is a bit of a pain if you’re not already using Composer as it means you have to have yet another piece of software on your computer, but unfortunately, you’re somewhat railroaded into it as there is virtually no documentation on how to install things like Twig without it. Luckily, once you have it, it does make things easy and pain-free, so it’s probably worth going through the initial setup.

Once you’re up and running, it’s a snap to add content. We recently re-launched Maze Finance and the entire process of getting Silex up and running and migrating our existing website into it took less than two hours!