In a new post to his site Tomas Votruba looks at autowiring Symfony services and parameters to make it even easier to integrate services into your application.

I love how Symfony caught up late autowiring integration in since Symfony 2.8. Then set a trend in Symfony 3.3 with service autoregistration.

That opens new possibilities to almost config-less registration, doesn't it?

He first looks at some of the "old" configuration handling, defining the services manually in the YAML configuration along with their arguments. He shows how this evolves with the addition of autowiring and autodiscovery, minus the parameters. He continues on to show how to integrate parameter handling into the services configuration via the bind option. He also shows how to improve this and use autowired parameters and call them directly in the constructor of your class and let the DI container do the rest.

On the TutsPlus.com site today there's a new tutorial where they spotlight one of the components in the Symfony framework: the routing component. The tutorial outlines some of the basics about the component, installing it and putting it to use.

The Symfony Routing Component is a very popular routing component which is adapted by several frameworks and provides a lot of flexibility should you wish to set up routes in your PHP application.

If you've built a custom PHP application and are looking for a feature-rich routing library, the Symfony Routing Component is more than a worth a look. It also allows you to define routes for your application in the YAML format. Starting with installation and configuration, we'll go through real-world examples to demonstrate a variety of options the component has for route configuration.

The tutorial starts with the commands to get the component installed (via Composer) and other related components for YAML parsing, HTTP handling and configuration parsing. It then provides examples of:

• setting up the instance and defining some basic routes
• how route matching works
• loading routes from a YAML file

The tutorial finishes with an example of an "all in one" router that pulls in the route configuration and creates a new Router instance with them ready and waiting to handle requests.

Tomas Votruba has written up a new post to his site sharing an update to a project he has to make it easier to enforce various coding standards in your application's codebase. In this update he talks about the Easy Coding Standard project's v4 alpha that includes a "clean" Symfony standard with support for Yaml and Services.

I wrote about news in Easy Coding Standard 3 a while ago. EasyCodingStandard 4 is not released yet (still in alpha), but soon you'll be able to use all the news I'll show you today.

And what are they? Neon to Yaml, semi-static to Services, customizable caching, even simpler skipper, short bin and more.

He breaks the new features down into a list of six updates:

• Configure Caching Directory
• Skip Anything, Anywhere
• Short vendor/bin/ecs is the King
• DI Migration Finished: From Neon to Yaml
• From Semi-Static Checkers to Services as First-Class Citizen
• Good Bye Neon Class Autocomplete Or not?

For each there's a brief snippet showing how to configure it a brief description of what it enforces.

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 Liip blog there's a post from Jon Minder talking about the new Drupal 8 migration API/module and includes a guide to get you started using it in your Drupal application.

We at Liip AG believe, that the migration API is the best and most efficient way to import data into Drupal. [...] The Migrate 8 module in core is only an API. There is no user interface. This makes it difficult for new developer to start with Migrate 8.

I suggest you, to install the [several] extension modules right away before you start developing if you want to realize the full potential of migrate.

The post starts with a list of reasons they see to use the migration module over other methods including the fact that it's sponsored and supported by Acquia. He provides a list of modules to install before getting started with Migrate and links to a GitHub repository if you'd like a "quickstart" environment to follow his examples. He then compares the previous version (from Drupal 7) of the migration handling with the newer Drupal 8 functionality, most notably the change over to YAML configuration rather than PHP code. He helps you understand the structure of these files and gives an example. He shows how to run the migration, gives a more advanced JSON source example and mentions the included process plugin.

On the Symfony Finland blog there's a post that talks about Symfony controllers and services and how making the controllers services instead could be beneficial.

Controllers are quite straightforward in their actions (ha-ha) and simply take requests and return responses. The concept of a services is simple too, it's technically just a PHP object that performs a task over and over again somewhere in your application.

[...] Using services for tasks repeating in multiple locations of your application undoubtedly makes sense, but why should you shrinkwrap your controllers into a service? If you look at the official Symfony Demo Application does not do this. So why should yours?

Once again he uses the eZ Platform software to illustrate the point, describing how it packages up the controllers into services, including the configuration required to make it work. He shows how the dependency injection works and how controllers/services can call actions in other controllers/services easily.

Loïc Faugeron has posted the next part of his "Ultimate Developer Guide" series covering individual Symfony components. In this new article he details the routing component.

In this guide we explore the standalone libraries (also known as "Components") provided by Symfony to help us build applications. We've already seen: HTTP Kernel and HTTP Foundation [and the] Event Dispatcher. We're now about to check Routing and YAML.

He starts with a basic overview of the component and what kind of top-level handling it provides. He describes the UrlMatcherInterface and its role in the routing process and a simple collection of Route instances that implement it. Then he gets into the YAML component, providing a simple example defining the routes for your application. He shows how it's converted from the YAML structure into a PHP-based (array) output and is then dumped into a RouteCollection to define the resulting routes.

On the Toptal.com blog there's a recent post about true dependency injection with Symfony between components in your application and only using the dependency injection container for its intended purpose.

Symfony2, a high performance PHP framework, uses Dependency Injection Container pattern where components provide a dependency injection interface for the DI-container. This allows each component to not care about other dependencies. [...] But this means DI-container can be used as a Service Locator.

[...] In this article we will try to build a Symfony2 application without implementing Service Locator pattern. We will follow one simple rule: only DI-container builder can know about DI-container.

They start off by talking about the structure of the dependency injection container and how it relates to the three main types: controller, method and property injections. He then starts in on creating the sample project and requiring only the Symfony DI, configuration and Yaml components. He then creates a ContainerBuilder class and sets up the HttpKernel functionality to pull the response from the container. He then makes a simple controller with a default action that just responds with text. With this working he updates it to pull in an input variable. He then makes updates to the application with changes to the route handing, templating (Twig), Doctrine (database) and tag handling.

In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.

Their list shows you how to lint (syntax check) several different types of content:

• standard PHP code
• Twig templates
• Composer configuration
• XML files
• Bash scripts
• JSON files
• YAML files

Some of them use tools that already come built-in (like PHP's "-l" or Twig's "twig:lint") but others require the use of external software such as xmllint or melody. Command examples are also included for each.

On the SitePoint PHP blog today there's a new tutorial posted that gets into the details on one of the powerful (and most used) components of the Symfony framework, the Router, and how to interact with it via annotations. Symfony's route annotations allow you to define functionality at the controller level or via a YAML configuration file.

When you download the Standard Symfony 2 Distribution, it includes an interesting bundle named SensioFrameworkExtraBundle which implements a lot of great stuff, especially the opportunity to use annotations directly within your controllers. The idea behind this article is not to convice developers to embrace this way of doing, but to point the finger at an alternative method to easily configure controllers. Keep in mind that there is no magic recipe, it depends on what you need in each specific scenario. Symfony 2 implements a strong built-in component to manage all the routes of an application: the Routing Component. Basically, a route maps a URL to a controller action.

His example sets up a simple blog and compares the two ways of configuring the routing: one side putting it all in the YAML configuration and the other in the controller docblocks (annotations) themselves. He adds a base page for showing the listing of posts and a single article route, complete with slugs. He also shows how to add in some additional configuration handling to do things like set default values, making things required and enforcing the HTTP method on the request (GET, POST, PUT, etc)