Interview With PPI – The PHP Meta-Framework

A Small Intro..

PPI Framework - The PHP Meta Framework
The PHP Meta Framework

If you are pretty much hooked to The PHP World and like to keep abreast with PHP frameworks, you have surely heard of The PHP Meta Framework called as The PPI Framework. It is said to be moulded by “taking the good bits from Symfony 2, ZendFramework 2 & Doctrine 2“. PPI is creating quite some buzz around the PHP sphere recently; even The Symfony Super-man, Fabien Potencier, himself mentioned PPI in one of his article. That said, it sure promises some good things with a different approach. To have an idea about all these and to feed the curious minds (like myself) , I had a PPI chat with its creator: Paul Dragoonis.

Who Is The PPI Guy – Paul Dragoonis?

Paul Dragoonis - Creator Of PPI & CTO at BestBuys.com
Paul Dragoonis – Creator Of PPI & CTO at BestBuys.com

Last time I did a thorough PHP Interview with [Paul @dr4goonis], so you can read his whole bio and PHP advice here: PHP Interview With Paul Dragoonis CTO At BestBuys.com – Expand Your Connections Via Twitter, IRC & Google Plus

PPI Framework – The Interview!

>> What does PPI mean?

PPI doesn’t stand for anything, it’s short, easy to say, type and remember. It’s very close to the ‘PHP’ acronym which is intentional.

>> When did the project start?

The project started in 2005. A friend and I started the project as an improved version of CodeIgniter, being simple with a stronger OOP model. A few months into the project my friend decided to abandon the project to pursue other things, from then on I made the project my own. Early 2012 I was decided to revamp the project and create PPI2 which is the meta-framework it is today.

>> What is PPI about and what does it try to solve

PPI2 is a cutting edge PHP meta-framework, some of its design goals are:

  • To harness the capabilities of larger more complex frameworks and convey them in a more productive and approachable manner.
  • Not to re-invent the wheel! Choose the best component for the job from an existing library and make it easily accessible for the developer by minimising the learning curve of using such powerful components.
  • To give developers coming from frameworks such as CodeIgniter and CakePHP a platform to step up to, the opportunity to use much more powerful components and community-driven tools while retaining the simplistic routes of the frameworks they’ve came from.

What does PPI solve?

It solves the problem of vendor lock-in by decoupling the framework base from the components used. This means you’re not committed to using components from a single vendor and you can mix-and-match them by choosing the best one for the job. An example of this is if you’re in a ZendFramework application but want to use the Symfony templating component you’re going to have a hard time achieving this, also, if you’re in a CodeIgniter application but want to use the powerful symfony2 routing component then you’re going to find this difficult too or you’ll spend a mass amount of time understanding the complexities of these components. PPI has already done the legwork for you and by simply just choosing the symfony templating component then PPI will fill in the gaps for you. PPI2 gives you an open stack base where you can choose which component best suits your application with no complicated integration or configuration process.

What is vendor-lock-in?

This is the problem incurred by tying your web application’s framework to the same library that’s producing the components you’re relying on. By nature the frameworks are built around, and to work with, the components themselves which means trying to have the framework or the building-blocks of your application with with components from another vendor is a nightmare. As a result 90% of the time you’re going to stick with the components in your framework’s application because using a different vendor is going to be really difficult to achieve and because of this your development stack is limited.

>> What is a PHP Meta-Framework and is it so much used as compared to Micro or Full-Stack frameworks?

At first I hadn’t heard of a meta-framework. When I explained to someone what PPI does, which is take components from other frameworks to have them working together, their response was “ah very cool! so it’s a meta-framework then?”. After doing some research it seems that was the name for what I had created.

I don’t believe there are any popular php meta-frameworks out there, everyone seems to make their own frameworks around their own components, whereas PPI wants to re-use existing code from popular libraries and tools built by the rest of the community.

>> What has prompted you to start PPI and not using an existing framework

As PPI is 8 years old I’m not starting another framework, I am only continuing a framework that has existed alongside the other frameworks, albeit with less exposure over the years since the goal wasn’t to be the biggest or most popular framework but just a solution toolkit to what was currently in the php eco-system. At the time of creation there were no decent PHP frameworks to pick from so there wasn’t anything to use instead.

>> what was your motivation, inspire us with the flame that ignited your passion to come up with it.

My passion has always lied in problem solving, rather than programming specifically. I seen programming as a tool to solve my problems on the computer. My goal with PPI is to analyse the pro’s and con’s of the leading products and come with something new that attempts to solve those problems by taking the pros from each level of the stack and throw away the cons. After years of analysis I felt the time was right to begin working on PPI2 in early 2012.

>> How is the actual team inside PPI structured? (Or is it currently a one-man show?)

We have Vitor who is our hardcore framework guy, we have Alfredo who’s our website guy and myself which leads both areas. We have had many contributors that come and go like many open source projects but the 3 of us are what you could call “team members”. We are actively looking for keen developers who enjoy problem solving and want to help grow a generic vendor-agnostic platform for PHP.

>> Is PPI backed by any commercial entity? (I mean for example, Symfony Labs is behind Symfony, Zend Inc is behind ZF..etc)

PPI is a community driven project and as such isn’t backed by any commercial entity, it’s built by the community for the community. I use my own business Dragoonis Digital Ltd, which builds PPI apps for clients, to provide a good model for open sourcing code back into the PPI eco-system.

>> Why should someone choose PPI instead of, let’s say, symfony or zend framework or Laravel – How would you convince them to use PPI

You can’t really convince someone to use your tool over X or Y because everyone will make their own mind up. The main reason I see people using PPI over an existing vendor frameworks is that they want to be able to choose a vendor component to suit their app now and then swap that for another vendor’s component as the project’s requirements grow larger. For example PPI’s decoupled nature means you can upgrade your routing component easily without the rest of your application even knowing which vendor it’s powered by since PPI handles that for you.

>> As far as building up a framework, could you share how to approach this kind of development – what does a PHP programmer need to invest time in, what he needs to learn and be equipped with to be able to conceive a framework.

You need to learn your target audience, what makes them tick, what they like or dislike. You need to get feedback from people on the same topics and identify trends and patterns and act upon those.

>> Building a framework entails a lot of decision at different level also, could you share what are some of those decisions and the factors affecting those decisions

If you break backward compatibility you piss a lot of people off, that’s probably the most important thing to take away from this. The decisions you have to make are more about what the consequences are of this change and what impact will it have to developers, negative or positive, you have to be empathetic since changes you make are affecting real people’s lives in their working job.

When showing someone your project or idea, don’t ask them what they like about it, find out what they don’t like, ask multiple people the same questions and see what they say. If you know what your audience doesn’t like, you can come back to them with improvements, however, if you only ask what they like about the project, you really aren’t making much room for improvement. Be sure to pay close attention to the the parts they’re confused about, this means you will need to amend your documentation to remove that confusion.

Longevity is the keyword here. You also have to think about maintainability of features and long-term lifecycle of this feature, will it be a hit years down the line? It’s these sort of things you think about rather than if it’s cool to have at the time.

>> The challenges you faced during the creation of your framework

For me the number one issue was motivation, and to motivate myself to write documentation and keep it maintained. Nobody likes doing it but it’s one of these things you’ve just got to get your head down and do it.

>> The good moments of your journey so far and any bad moments of it?

The good moments would be getting featured on blogs by @fabpot and @evandotpro who represent Symfony and Zend. We also got featured by Smashing Magazine and have been mentioned at over a dozen developer conferences all over the world.

The bad moments are too long to list here, remember: success is about 99% failure.

>> Could you tell us what are some of the best practices you believe in and would strongly preach to anyone

  • Listen to feedback, don’t oppose it, I consider this the number one best practice
  • Document your code properly with PHPDOC
  • Make use of API generation tools to help outsiders understand your system.
  • Use composer to re-use existing community driven libraries.
  • Use a proper IDE to accelerate your coding time and highlight bugs in real-time.
  • Pick one coding standard to follow such as PSR1.
  • Make your code compatible with other libraries such as PSR0.
  • Host your repo on github so the community can review your code and provide patches/enhancements.
  • Make a composer package out of it in the end so it can be easily part of someone’s project.

>> If Anyone needs help concerning PPI, where can they get help or hang out?

  1. You can follow us on twitter at @ppi_framework where you can ask questons
  2. You can join our Google Plus community
  3. You can hang out in our IRC channel on irc://irc.freenode.net/ppi or use the embedded IRC page on our website.

All of which you can receive help from or hang out at.

Now Do Your Part!

1) LIKE 7PHP dot COM on FaceBook – if you appreciate what I do

2) Help diffuse this interview to the PHP ecosystem – Share, tweet and spread the word to your audience ==> That would be a FREE way to thank me 😉

3) Make a comment below using the comment form – I’m sure you can at least say 1 word about this interview

{I’m thankful to your response(s)!}




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.