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.

The SitePoint PHP blog has a tutorial posted by author Younes Rafie covering the use of the Fractal library from The PHP League to create "pretty" JSON API output.

If you’ve built an API before, I’ll bet you’re used to dumping data directly as a response. It may not be harmful if done right, but there are practical alternatives that can help solve this small problem.

One of the available solutions is Fractal. It allows us to create a new transformation layer for our models before returning them as a response. It’s very flexible and easy to integrate into any application or framework.

They use a Laravel application as the base, creating a simple database of user information and relating users to roles. The tutorial then starts in on using Fractal, building out "transformers" for the data. These transformers take in the data/object and, inside of a "transform" method, modify the output and return a "prettier" version. They show it in use in a controller, outputting a collection of user data, only returning the name and email values. The tutorial also covers a few other Fractal-related topics including pagination, including sub-resources and eager loading.

On the Symfony Finland blog there's a tutorial posted showing how to translate Drupal 8 configurations into ones for eZ Platform using a bit of code inside a Symfony command.

Bolt CMS, Drupal 8 and eZ Platform all content management systems that use Symfony in one form or another. All of them use YAML to store configurations of content types and other system properties. This is great as it makes transferring between different formats quite straightforward.

This could be done by hand, but ideally configurations can be converted programatically. In this article we'll take a look at how to transfer content types from Drupal 8 to eZ Platform using a standard Symfony Command.

He starts with some background about the two configuration types (Drupal 8 and eZ Platform) before getting to the actual code to make the transformation. The code translates the Drupal 8 configurations over to the Kaliop Migrations format that can then be used in various environments. They include an example of the resulting configuration structure and, finally, the code to make the translation (allowing for multiple object types too).

On the SitePoint PHP blog they've posted a tutorial showing you how to work with transducers in PHP. Transducers are pieces of functionality that allow you to transform data in a reusable way.

Have you heard of functional programming, high order functions, etc. before? Probably, right? However, when you hear “transducers”, do you know what those are? [...] A reducing function is just the kind of function you’d pass to reduce – it takes a result so far and a new input and returns the next result-so-far. A transducer is a function that takes one reducing function and returns another.

Transducers were first introduced into Clojure by Rich Hickey, and ported to PHP by Michael Dowling. Transducers are a powerful way to build algorithmic transformations that you can reuse in many contexts. In this article, we’re going to take a look at how they could be useful through a set of practical examples.

They help you get the mtdowling/transducers library installed via Composer and include a simple example using a User instance and uppercasing the first letter of the user's name. Other examples of the transducer functionality are also included such as: converting values to strings, filtering and composing sets of multiple transformations. The tutorial also shows you how to extend the current functionality and create your own transducer class (their example drops null values).

In a post to his site Ewan Valentine looks at some considerations to think about when creating a domain specific language in your applications. This kind of language helps define common terms, conventions and practices for developers to follow in their code.

When you spin up a framework such as Laravel, Symfony etc. The first thing you'll notice, is that they have their own 'feel'. I often joke that Symfony2 is like Java and Laravel is like Ruby.

But what gives an application or a framework a 'feel'? Domain specific language or 'DSL'. Domain specific language is almost like a syntax or a language specific to your application and ecosystem. DSL is what makes your applications code unique and more usable.

He gives a specific example of a Laravel application he was creating and how he wanted the interface to function, transforming the result of a find() into a JSON response. He shows how it could actually be done but that introduces more maintenance and more code to cover. Instead he worked backwards into the domain context the request was operating in and found an ideal injection point for transformation that would keep it out of the controller action itself.

So, to design usable domain specific syntax, start at the front. In other words the part you'll be writing the most, and then work backwards to abstract the logic and make it actually work.

On the Laravelista.com site there's a recent tutorial posted showing you how to create an API with Lumen and Fractal, a combination of the popular Laravel-based microframework and Fractal, an output handling library that makes it simpler to transform data to your needs. This is the second part of his series (part one is here), making some improvements on his previous examples.

In the previous post I used Larasponse to get Fractal working with Laravel, but recently I have switched to native Fractal package. One thing to notice is that in this post I will be showing you parts of code from a real project that I am working on called Treeline, instead of just example code like in the previous post. Be sure to check the Treeline repository if you're unclear on something.

He goes back through some of the setup process, getting Fractal installed via Composer and the creation of an ApiController to handle basic things like setting the status code and transforming the response to JSON. He shows how to add in the necessary routes for the "projects" path and creates the matching controller, collection and item classes that integrate the Fractal transformers to format their output as JSON. He also includes the code for the transformer classes themselves, showing you how to pull in and modify the data for the API's needs. He ends the post showing how to integrate other data (the "notes" into a "project" instance) and the resulting JSON output.

The Qandidate.com blog has a quick new post today showing how to handle AngularJS requests with a Symfony framework based backend application. They automate the process of decoding the JSON from the Angular frontend to make it immediately usable to the framework backend.

At Qandidate.com we started using AngularJS last year and I have to say it was love at first sight! Two-way databinding, testability, dependency injection, server communication...awesome! Did I say server communication? We use Symfony 2 (which is awesome too) for our back end API’s. Unfortunately AngularJS and Symfony do not speak the same language out-of-the-box. In this post I will show you how we automatically decode JSON requests so we can use it with Symfony's Request object using our symfony-json-request-transformer library (or class actually).

They start with a simple JSON example and the action to handle it (the "postAction") and show the manual json_decode method. Instead of having to do this in each controller action, they define the Request transformer handler. This handler takes the incoming request and allows for modifications to various aspects of the request, including transforming the data. They've posted a full example here that includes the full stack, not just the transformer itself (to show the full flow of the request).

The SitePoint PHP blog has a new tutorial posted by Alexander Cogneau that gives you an introductory walkthrough of Fractal, a PHP-based library that provides a translation and presentation layer for the output of your APIs.

If you ever developed for an API, you might have had troubles with changes of your database schema. If you didn’t happen to have a good implementation, you had to rework your whole model when changing some column names. In this article I will demonstrate how you can use Fractal as a layer between your models and JSON output. This post will show you how this package will make API development easier.

He walks you through getting the library installed (via Composer) along with Silex for the application handling and the Illuminate/database package from the Laravel framework. He also provides a SQL file to create the database for the application. The sample app handles music information, providing a simple song and artist list. It uses the Fractal package to transform the data using Transformer objects for each data type.

In some of his recent work Lukas Smith has been testing the waters of what Solr (the fast, open source search platform) has to offer. In his work with it he needed a way to convert the queries that come in from users into something Solr can understand. In this new post he explains how and shares the code for his solution (symfony-based).

In this blog post I want to talk about a prototype class I threw together (Look ma', I'm using git!) by working ezcSearch to help me in parsing and transforming end user queries into complex Solr queries.

He includes a few examples of Solr queries and what sort of data they'd return as well as the source for the library he's created to extend the sfSolrPlugin translate something coming in from a form into a simple Solr-formatted query.

New on the Ibuildings techPortal today is an article from Michael looking at XML transformation with PHP and XSL (XML-based "style sheets").

If you want to transform XML from one format to another, and especially if either the input or output XML is complicated or the transformation itself is difficult or awkward to express, then XSL may be a good choice. XSL is the eXtensible Stylesheet Language; a family of three W3C recommendations to do with the transformation and presentation of XML documents. This article will walk through some examples of how XSL and PHP can be used to achieve these types of XML tranformations.

He starts off by describing what XSL looks like and how it relates back to the XML you're applying it to. XSL allows you to take an XML file and work with it as a data source to pull bits of information out of or modify and push back out the other side. He gives three specific examples: pulling information out of an XML file, rewriting URLs and one of the more handy things PHP allows you to do - directly call PHP script inside the XSL document for those things that the normal XSL standards don't include.