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.

Junior Grossi has posted a tutorial that covers the idea of data filtering with Eloquent models. In this case, the filtering is based on user input from a URL with parameters matching the properties on the model.

Filtering models was, for a very long time, a hard task for me. I admit that I could not think in some easy way to do that. I tried, refactored some code, created custom classes for that, but I never thought how this could be easily implemented.

Watching a Laracast’s video from 2016 about the Laravel’s Eloquent ORM I faced of with a bunch of classes and a trait that removed a lot of trash from my controller actions. That was called by Jeffrey Way the QueryFilter.

He then gets into some of the goals behind the filtering and the expected input method (URL parameters). He then creates a simple Laravel application making use of Corcel to integrate with his current WordPress backend database. He includes code examples showing the creation of a Post model and controller and returning only the desired fields using a JSON response and a toArray method. He then moves on to the filtering, starting with a more hard-coded version of the search: adding a where statement to the query manually before the get.

To replace this with something more flexible, he implements the QueryFilter class that can be extended to match the requirements for the model type. He then implements the PostFilter class, adding methods for "status" and "title" fields. Finally he adds in a scopeFilter method that makes it simpler to call the filtering directly from the model instance.

The Laravel News site has a new post today describing a feature of the upcoming Laravel 5.4 release: the ability to define language files with JSON formatted files.

One of the most wanted requests we receive at Laravel is introducing better support for multilingual web applications, there are already packages out there that add some nice functionality to Laravel for better handling of multilingual projects requirements, but one of the painful issues when building such applications is managing translation keys.

Previously the trans/trans_choice helper to reference the value defined in the PHP array from your language files by a key name. With this new functionality, a new __() helper method is defined that will look through the English translation file, locate the correct key and find the matching record in the requested language to return. They also show how to pass in some parameters into the translator and how to use it directly from Blade.

In this new post to his site Kevin Schroeder has shared a helpful hint around the MongoDB library and excluding fields from the results of a query.

I am using the mongodb/mongodb library for a project of mine. The API seems fairly different from the old PECL library and it also came with some other, albeit unexpected, baggage. [...] One of the practices I’ve heard about Mongo is to get Mongo to do as much as it can, but not to worry too much about complicated joins and such as you would in SQL. In other words, don’t shy away from bringing data into the application to do some processing. That was the practice I followed, which worked fine up until my data size started to increase.

He started seeing some major performance issues when his data set grew to a significant size (50% of the response time). He went searching for a solution, tried MapReduce but eventually came upon an optional parameter letting him tell the Mongo DB to omit a value (or values) from the result set. Using this he dropped 7.5 seconds off of his wall clock time.

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.

in a new post to his site Phil Sturgeon talks about a new (old?) proposal to introduce named parameters into PHP.

Named Parameters for PHP is not a new conversation. It's reared its head several times - so much so that the named parameters RFC says: "Since the topic continually gets re-raised, and now PHP has an RFC process, the discussion should be recorded in an RFC (Note this is yet to be done) so the same arguments don't have to be revisited."

He notes the negative attitude that seems to currently be shown in the RFC and has made the offer to rewrite it to be more impartial to the subject at hand. In the comments of the post there's also some feedback about the different syntaxes and varying levels of support for the proposal.

Jerermy Kendall has written up a post for his site showing the use of his QueryAuth library for API authentication, complete with plenty of examples. The library makes it simple to sign and verify requests based on a key, secret and parameters given.

Most APIs require some sort of query authentication: a method of signing API requests with an API key and signature. The signature is usually generated using a shared secret. When you’re consuming an API, there are (hopefully) easy to follow steps to create signatures. When you’re writing your own API, you have to whip up both server-side signature validation and a client-side signature creation strategy. Query Auth endeavors to handle both of those tasks; signature creation and signature validation.

He includes code examples showing how to create a signed request, validate the signature from an incoming request and generate randomized keys and secrets. He's also created a sample implementation as a Vagrant box that sets up a Slim framework based application and uses Guzzle to make requests. He briefly looks at some of the code that makes it work and what the raw HTTP request and response look like for the result.

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

Kevin Schroeder has a quick new post with a one-liner you can use to get remote debugging working with Zend Debugger and PHPUnit.

I’m trying to do some remote debugging with PHPUnit on a remote system. I was following the rules I had written about in a previous article but for some reason I could not get path mapping to work. So I figured I’d ping the Studio lead developer because as soon as I did that I’d get it to work. Well, that’s what happened.

His fix comes in the form of setting a command-line parameter, QUERY_STRING, with the correct parameter order so the paths will get mapped back to the correct project. This parameter is a URL-encoded set of parameters that do things like start the debugging, set up the hostname for the debugger to point to and map the "original URL" back to your choice of values.

Kevin Schroeder has a quick new post about using dependency injection in Zend Framework 2 applications using multiple object instances.

When you work with the ZF2 Dependency Injection Container (DiC) when you make multiple requests for an instance of an object you will get the same object back each time. [...] But what if you want the injection benefits of the DiC but don’t want to share the object? Use the DiC’s newInstance method instead with the third parameter being false.

He includes code examples of requesting the object both ways - the usual way that returns the same object and the alternative that passes in a "false" value, complete with a debug output of each object proving they're different.