Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Gonzalo Ayuso:
Alternative way to inject providers in a Silex application
Oct 19, 2015 @ 11:18:10

Gonazalo Ayuso has shared a method he's found for injecting providers into Silex that replaces accessing the dependency injection container as an array. It instead replaces it and allows defining function parameters instead.

I normally use Silex when I need to build one Backend. It’s simple and straightforward to build one API endpoint using this micro framework. But there’s something that I don’t like it: The “array access” way to access to the dependency injection container. I need to remember what kind of object provides my service provider and also my IDE doesn’t help me with autocompletion. OK I can use PHPDoc comments or even create one class that inherits from SilexApplication and use Traits. Normally I’m lazy to do it. Because of that I’ve create this simple service provider to help me to do what I’m looking for. Let me explain it a little bit.

He includes examples of both the normal way you can access Silex's injection containers (the "array access" method) and contrasts this with his updated method, via a method parameter on the route closure. His service provider (complete code in the post and on github), when registered, looks for controller events and performs reflection on the closure to detect which objects need to be injected. The method is then called normally but with the extra attributes set, populating the parameters.

tagged: slex service provider alternative array access parameter method dependency injection

Link: http://gonzalo123.com/2015/10/19/alternative-way-to-inject-providers-in-a-silex-application/

Marc Morera:
Namespaces in Traits
Oct 16, 2015 @ 13:53:14

In this post to his site Marc Morera talks about traits, namespaces and how they fit together (or don't).

Some projects using PHP 5.4 are actually using Traits. If you don’t know yet what a trait is, there are some interesting links for you. [...] This post is about the usage of "use statements" in Traits.

He starts with an overall picture of what he's trying to accomplish in a contribution to an open source project (with a word of caution). He talks about how you can make traits and classes more "friendly" with a refactoring example of his initial code snippet. In the end, though, he recommends basically avoiding namespaces if possible in traits, reducing headaches that could be caused either by conflicts or missing dependencies.

tagged: traits namespace difficulty dependency interaction

Link: http://mmoreram.com/blog/2015/10/16/namespaces-in-traits/

SitePoint PHP Blog:
Can PuliPHP Re-Revolutionize PHP Package Development?
Oct 08, 2015 @ 11:17:56

In this recent post to the SitePoint PHP blog Nicola Pietroluongo looks at a newer tool in the PHP ecosystem that builds on to of the already widely popular Composer to expand packages outside of just the PHP code - Puli.

Puli is a new toolkit built on top of [Composer](https://getcomposer.org) that helps to manage and exchange resources like configuration files, images, CSS files, translation catalogs, and others. These are, you’ll agree, often difficult to maintain and share across projects.

The article starts with a brief overview of how it works and where it connects in with Composer, pulling in other dependencies as defined in a puli.json file. It then walks you through the creation of a simple package - installing the Puli CLI tool, building out the project file/folder structure and mapping resources/assets into the bundle. Finally they show how to install a demo package they've created, how the project maps in to the application and the pieces that make it up. The post ends with a look at the "resource discovery" feature Puli also includes making it easier to pull in configuration options without having to manually define them.

tagged: puli package development tutorial bundle asset dependency

Link: http://www.sitepoint.com/can-puliphp-re-revolutionize-php-package-development/

Shameer C:
Slim 3: Replacing Pimple with Aura.Di
Sep 28, 2015 @ 12:12:25

In a post to his site today Shameer C shows you how to replace Pimple in Slim 3 as an application's dependency injection container. He replaces it with the Aura.Di container, a relatively easy replacement thanks to the container interoperability efforts.

Slim framework is my go-to micro framework for all small projects because of it's simplicity and easiness to use. The new version of this cool framework is just around the corner and they have released RC-1 a few days back. [...] Slim 3 has a default DI Container that extends Pimple. [...] Though Slim uses Pimple by default, we can replace it with any DI container that implements Container Interoperability interface, which is a really great feature. The only caveat is Slim sets some of it's required services from the default container. So we should do it by ourself when we use a different library.

He starts by talking a bit about the Aura.Di container and how it's different than what Pimple has to offer. He then links to a small library that makes the bridge between Slim 3 and Aura.Di and sets up the services Slim needs to operate correctly. He then steps through the code needed to integrate this into a simple Slim application based on this skeleton. Most of the work is done in the dependencies.php file where Slim's needs are set up, configured and injected into the container.

tagged: auradi dependency injection container slim3 pimple replace tutorial

Link: http://blog.shameerc.com/2015/09/slim-3-replacing-pimple-with-auradi

Dependencies in Disguise
Sep 28, 2015 @ 08:48:27

On the PHP.cc's site has an article that looks at dependencies in disguise based on a "workshop" one of their members, Stefan Priebsch, gave at the recent Bulgaria PHP Conference.

Yesterday I gave a presentation at the [Bulgaria PHP Conference](https://thephp.cc/dates/2015/09/bulgaria-php-conference) (a great event, by the way). Following an [ad-hoc workshop](https://twitter.com/s_bergmann/status/647732967087939584) that I gave as part of the hallway track and an entertaining hackathon, I decided it was too late to join the party and went back to the hotel with some other speakers. Checking out how the day was reflected in social media, I contributed a few more tweets to a [conversation](https://twitter.com/tim_bezhashvyly/status/647861115721003008) that had started earlier in the day ([here](https://thephp.cc/dates/2015/09/bulgaria-php-conference/solid-mvc) are the slides of my talk that people are referring to). I am writing this to clarify my point, and help everybody to understand better.

He talks about dependency injection as a best practice that's followed in libraries all over the PHP ecosystem, making it easier to work with objects and their needs. Sometimes this means using a dependency injection container and others it's just constructor/method injection. He talks about how these objects are build in factory methods and recommends making one factory but points out that this only really works when all the objects you need are known up front. However, he gives several (code) examples of places where this could be difficult and how some are using service locators to solve the problem. He points out, however, that this then expands the API of the application out way too far, opening it up to objects all across the application when there may be no need. This is where the hidden dependencies can come in, things masked behind the use of a single service locator. He recommends solving the issue with more customized locators, as in his example of routing locator used to handle dependencies for a POST HTTP request.

tagged: dependency disguise injection service locator bestpractice solid development

Link: https://thephp.cc/news/2015/09/dependencies-in-disguise

Matthew Weier O'Phinney:
Fixing Version Issues When Running Composer from a Branch
Sep 11, 2015 @ 10:55:04

Matthew Weier O'Phinney has posted an article to his site showing you how to fix version issues in branches when using Composer packages and libraries in your applications.

For the Zend Framework component repositories, we occasionally need to backport changes to the 2.4 LTS releases. This requires checking out a branch based off the last LTS tag, applying patches (often with edits to translate PHP 5.5 syntax to PHP 5.3), and running tests against PHP 5.3 and 5.4.

Of course, to run the tests, you need the correct set of dependencies installed. If you have any component dependencies, that means running a composer update to ensure that you get the 2.4 versions of those components. And that's where my story begins.

He talks about some of the issues he's come across when testing components and Composer, not understanding that the environment has changed, does not load the correct versions of the necessary libraries. He first tried to fix the dependencies himself, adjusting the version numbers required but with no luck. Finally he stumbled across something on the Composer site that helped: the ability to define a "root version" environment variable that made it adhere to the versions he needed.

tagged: composer dependency branch issue incompatible environment variable

Link: https://mwop.net/blog/2015-09-09-composer-root.html

Frank de Jonge:
Packages vs. Components: The Dependency Problem.
Jun 26, 2015 @ 11:12:18

In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.

The PHP landscape has fully transitioned into its Package Age™ [...] However, due to PHP's nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.

In his Guzzle example he describes the main problem - when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.

tagged: package component dependency problem conflict versions guzzle eventdispatcher

Link: http://blog.frankdejonge.nl/packages-vs-components/

Joe Ferguson:
How I use Laravel Homestead everyday
Jun 25, 2015 @ 09:21:28

Joe Ferguson has a new post to his site sharing a bit about how he uses Homestead (the Laravel project's virtual machine offering) in his every day development.

I feel like I’ve been talking about homestead a lot lately. I feel like Vagrant is such an important part of a developer’s workflow. If you are still using MAMP, WAMP, or installing Virtual Machines manually you are wasting so much of your own time (and your clients money) by not using prebuilt development environments. [...] I prefer to have my open source projects contain a Vagrant environment so that any potential contributor can easily clone my repository and run “vagrant up”. [...] The recent changes to Homestead have brought the option to use Homestead exactly as I do, without having to use my own packages or copy and paste files.

He walks you through the simple process of getting a project set up with this Homestead-per-project configuration:

  • Starting a new Project
  • Adding Homestead as a dependency
  • Make the Homestead configuration for this project

Now when a "vagrant up" is run from the project, Vagrant understands to create a Homestead virtual machine instance, import the base box and configure it to be a locally hosted web server for your application. He also includes instructions for using it with non-Laravel applications and how to share the environment.

tagged: laravel homestead everyday tutorial project dependency vagrant

Link: http://www.joeferguson.me/how-i-use-laravel-homestead-everyday/

Dependency Injection tutorial
May 06, 2015 @ 11:16:25

If you've heard the term "dependency injection" but are still a little fuzzy on the concept, you should check out this new post to the MyBuilder.com site introducing you to some of the basic concepts and using it in some PHP-based examples. They focus on the use of a dependency injection container in this tutorial (versus something like constructor or setter injection).

A lot has been written about dependency injection or DI (for short) in PHP, but it's a bit difficult to find a tutorial showing how a DI container actually works. The objective of this post is to show the internals and concepts of a DI container.

They start with a brief look at what a dependency injection container is and how it's different from a service locator or regular autoloading. They mention some of the benefits it provides and get into the simple example. They start with a class that creates a hard dependency in the constructor and show how to refactor that out to constructor injection. They then take the next step and replace the constructor injection with a DI container injection and how its internals are set up to provide new instances of requested objects (via a services definition).

tagged: dependency injection di container tutorial introduction

Link: http://tech.mybuilder.com/dependency-injection-tutorial/

Made With Love Blog:
Tilde and caret version constraints in Composer
Apr 13, 2015 @ 12:56:22

The Made With Love blog has posted a great introduction to version handling in Composer today. They focus in on two characters that can be confusing if you're not exactly sure what they mean - the carat (^) and tilde (~).

A dependency that uses semantic versioning allows you to predict wether it is still going to work or not when you upgrade it to a new version. Basically when the x in a x.y.z version number changes, you might need to do some changes to be able to work with this new version without problems. [...] Depending on your dependency manager you can define version constraints using wildcards (*), comparators like <=, logical operators (, often means AND and | means OR), etc. [...] There are also some syntactic sugar operators like ~ (tilde) and ^ (caret)

They include some examples of both characters in use defining the required install versions, showing how one allows for approximate matches and the version ranges they apply to.

tagged: composer dependency version constraint tilde carat

Link: http://blog.madewithlove.be/post/tilde-and-caret-constraints/