Rob Allen continues his series of posts covering the use of PHP on the OpenWhisk platform. In his latest post he shows how to usr Fractal as the view layer for your application (as installed via Composer). Fractal is a project from the PHP League that "provides a presentation and transformation layer for complex data output, the like found in RESTful APIs, and works really well with JSON."

When writing an API, it’s common to produce an output that conforms to a known media type such as JSON API or HAL, etc. I’m a strong believer that even though I’m writing an API, my application has a view layer. It’s not the same as building an HTML page, but you still need to separate out the code that creates the structured output from your model layer. For a couple of APIs that I’ve written recently, I’ve used Fractal for this.

He starts with some example code showing how to use Fractal to transform data that's come from his datasource. This includes both the script to use the Manager and the class defining the "transformer" for the todo data. He then moves this over and integrates it with an OpenWhisk application, making use of the dependency injection container to create transformer and manager instances. His final example shows this setup in action as the result of a call to fetch all current todo items.

In a new post to his site Alex Bilbie has started the search for a new maintainer for the league/oauth2-server package citing the lack of time on his part to give the project the time it needs to flourish.

A little over five years ago I pushed the league/oauth2-server. The project has been downloaded over 2.5 million times, has more than 3000 Github stars and has been contributed to by 77 awesome people across some 2000 commits.

Last year when I became self-employed I had intentions that I’d have more time to dedicate towards open source projects but reality worked out slightly differently and I’ve had one of the busiest (and best) years of my life.

He also points out that, besides the lack of time to work on the project, he also doesn't actively use the project himself and wants to find a maintainer that "is/are really impassioned by the project, want to advance the project (for example implement OpenID support) and are willing to devote time to answering support requests and review pull requests."

If this interests you and you'd like to see the project move forward, the post includes his contact information for you to reach out.

Colin O'Dell has a post to his site talking about how he used the Blackfire.io service to optimize league/commonmark, a library that's a part of The PHP League making it easier to work with Markdown content in PHP.

As you may know, I am the author and maintainer of the PHP League's CommonMark Markdown parser. [...] This last goal [of being well-written and super-extensible so that others can add their own functionality] is perhaps the most challenging, especially from a performance perspective. Other popular Markdown parsers are built using single classes with massive regex functions.

He shares some brief benchmarks of parsing the same document with four different parsers, including an older version of CommomMark (coming in last, unfortunately). With the goal of optimization in mind, he tried out the Blackfire.io service to locate the bottlenecks in his library. Based on the results from the tests he found two optimizations that could be made relatively easily: switching from single-character parsing to regex and more correctly replacing newlines with breaks where needed.

In part one of a new series on the SitePoint PHP blog Bruno Skvorc looks at the right way to start a PHP package using a set of guidelines that have evolved recently in well-structured, well-tested PHP packages.

In recent years, good standards for PHP package design have popped up, in no small part due to Composer, Packagist, The League and, most recently, The Checklist. Putting all these in a practical list we can follow here, but avoiding any tight coupling with The League (since our package won’t be submitted there – it’s specifically made for a third party API provider and as such very limited in context).

The list of rules includes topics like having a license selected, using PSR-4 autoloading and having in-depth code comments. Bruno uses these as a foundation and starts in on the creation of a package. He uses the PHP League skeleton structure to create the files and folders for a basic package. From there he updates the contents with details for his Diffbot example and installing other needed software libraries. The rest of the post is broken up into the two remaining steps and examples under each: sticking with the PSR-2 guidelines and planning for the structure of the package.