On the Laravel News site there's a post about an upcoming feature in the Laravel framework's Blade templating functionality: components and slots.

A new feature coming to Laravel 5.4 is the ability for you to add Components and Slots to Blade templates. This feature was inspired by Vue.js and allows you to simplify building HTML elements into reusable areas.

In most applications you have a master layout and then sub views that extend it. [...] Using the new Laravel Blade Components you can create [a template] with a special variable [for easy replacement].

The post then shows how to "reimagine" views using this slots and components functionality in a simple template/view example, replacing data based on names rather than it having to be passed to the view as data.

In this blog post, we show a way to split up large Laravel applications into smaller micro-services, in our case Laravel & Lumen applications, and the advantages and pitfalls it brings with it. As a result, we sped up our applications by more than 30% and achieved greater maintainability, too. These principles can, of course, be easily applied to other frameworks.

A lot of functions are needed in our REST API as well as in our administration panel. [...] While we still have a “monolithic” codebase, we have multiple completely independent backend applications. You might want to call them “micro-services” (because it’s so trendy).

These microservices required similar functionality and splitting those out into shared components made sense. They walk you through some of the basic requirements they had when splitting the application and how the components are structured. They then shift over to the Laravel/Lumen side and show how multiple applications can be hosted via the same installation and where the shared components fit in. They show how to define namespaces to load the components and set up the providers so Laravel/Lumen knows how to use them.

It is indeed really convenient and can simplify greatly your developments when you have to manage status workflows in your application, that occurs a lot.

The tutorial starts by helping you get the Workflow component installed (via Composer) and an example configuration defining a flow for a pull request. They then show the command to generate the flow graph so you can ensure the workflow is correct. From there example code is provided to use the workflow and do things like:

checking if you can transition to a certain state

get the list of enabled transitions

event handling

Code examples and configuration options are also included for these points, helping you to make your workflow even more flexible.

Symfony Components are a set of decoupled and reusable PHP libraries. They are becoming the standard foundation on which the best PHP applications are built. You can use any of these components in any of your applications independently from the Symfony Framework.

[...] The purpose of this post is to roughly describe how to implement some of the Symfony Components. I've created a set of gists to get started. You should already know how Symfony Components work in the Symfony Framework.

He starts with an example Composer configuration pulling in some of the more popular Symfony packages (like VarDumper and FormBuilder). He then includes the code to bootstrap the container instance and the services.yml he's come up with to bootstrap and integrate all of the components. The tutorial ends with examples of putting some of these components to use in resolving controllers, using the FormBuilder, using the command line and outputting errors with the VarDumper.

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).

Everyone who regularly visits my blog knows that I'm a complete fan of the ZendServiceManager component. It is always my choice to deal with dependency injection in any kind of project, more now that v3 has been released, which is faster and has a better public API.

The workflow while working with the ServiceManager is usually the same. You create a factory or abstract factory that creates a service and then you register that service into the ServiceManager itself. Of course you have to optimize your code, and you should try to reuse the same factories whenever possible, and try not to abuse of abstract factories and initializers.

He points out the main problem with using services like this in a larger application, namely that you can end up with a large amount of them, making them difficult to manage (and find problems with). He proposed solution uses this library to minimize the amount of code needed buy injecting dependencies into the service based on "inject" annotations. He includes an example of this functionality in action and includes a few things to keep in mind using the package (like the slower parsing of the annotations some limitations it currently has).

In a previous postLoïc Faugeron showed you how to take all of the components he'd talked about so far and make a simple API endpoint. In this latest post he takes the same functionality and makes a web-facing example instead.

In this article, we're going to continue the "fortune" project by creating a page that lists all fortunes.

He goes through a similar process as before, but with a few changes to make it output a web page instead of API (JSON) results:

Create the Controller

Configure related routing

Create the logic to list all current fortunes

Putting the "wiring" in place to connect it to the database

Creating the view to output a simple page with the fortune list

It's that last step that's different, resulting in a simple (non-templated) page being output with HTML markup. He then refactors this to use Twig as the templating output layer, removing the output generation from the application logic.

Loïc Faugeron has posted another article in his "Ultimate Developer Guide to Symfony" series today. In this new article he shares an API example making use of the knowledge gained from the other articles to create a simple project.

We've also seen how HttpKernel enabled reusable code with Bundles, and the different ways to organize our application tree directory. In this article, we're going to put all this knowledge in practice by creating a "fortune" project with an endpoint that allows us to submit new fortunes.

He starts by creating the project (via Composer's create-project command), sets up a basic routing configuration and installs PHPUnit for testing. He then shows the creation of the controller - test first - to handle the "fortune" endpoint requests. He then comes back in and adds in some logic around the submission including matching tests. This is then refactored further to use Doctrine to insert the contents into a database. Additional code is provided showing how to "wire it all together" and create the database structure. The entire post takes the TDD approach so tests for all submission functionality are included.

On the Symfony blog there's a new post briefly looking at Symfony 3 and what's different about it as compared to previous releases (and what's not).

Symfony 3.0.0 was released on November 2015 as planned by the Symfony 3 roadmap. As we do with any new Symfony version, we should publish a blog series explaining its new features.

However, Symfony 3.0 is a very special version which contains no new features comparing it with Symfony 2.8. Their only difference is that 3.0 removed any feature marked as deprecated in 2.8. That's why we won't publish any "New in Symfony 3.0" post. Instead, let's do a quick recap of the new Symfony 2.8 features which are also available on Symfony 3.0.

Among the items on their list are things like:

New components like Guard Authentication and LDAP

A MicroKernel component

Improvements for VarDumper, Console and the Security components

Each of the changes on their list include links to get more information about the component and the post wraps up with a quick "how-to" on upgrading to Symfony 3 from other releases.

Loïc Faugeron is back again with another of his "Ultimate Developer Guide" tutorials in his series. In his latest he looks at the Bundle component and the functionality it introduces as it relates to some of the components already discussed (like HttpKernel).

He starts by comparing the HttpKernel and Kernel components, laying them out so that their use makes sense later. From there he then gets into the actual Bundle component. He introduces the component, provides a code example showing its interface and talks about situations where bundles could be useful. To help make it a bit more "real world" he then shows how to create a "NanoFrameworkBundle" complete with Extension, Compiler, configuration and bundle definition examples.