On the Jolicode.com blog, there's a tutorial they've posted showing how to "mix security and forms" in a Symfony application to show only certain form fields based on a user's roles.

In some applications, it could be required to disable some form fields depending on user’s roles.

In this article, we will see how to implement this feature thanks to a simple example: a blog engine.

For their example, they use a Symfony 4 application with the MakerBundle and create a basic blog with "article" entities and an "admin" entity for the user list. From there, the post includes the code needed to update the buildForm method in the ArticleType class to check the current user and be sure they have the "admin" role. To make this work, they also build out a SecurityExtension form extension class that performs the actual check. This is then hooked into the pre-submit event on the form to prevent other issues where an attacker might delete the "allowed" element and submit the data anyway. The post wraps up with an example of performing a similar check but hiding the field instead of just disabling it in the form.

The Pineco.de site has a new tutorial posted showing you how to implement custom logic with raw SQL in the Eloquent query builder in the Laravel framework.

Laravel’s query builder offers a nice way to work with raw SQL. We can use them in our where conditions and also in our orderings as well. Let’s see some examples where we can use raw SQL to implement custom logic for ordering the results.

The post starts with a brief mention of the difference between sorting and ordering results, noting that one happens on the SQL server and the other on the results collection. Next they show examples using raw SQL to order a query using both a simple and more complex condition. There's also a link to the official documentation for the raw methods for more information and examples.

The BitExpert blog has a post sharing some of author Stephan Hochdörfer's experience in combining Doctrine and the ramsey/uuid-doctrine and willdurand/hateoas packages to create a system that follows the HATEOAS API documentation structure for his Doctrine-based objects.

Recently I experimented a bit with Doctrine ORM and the willdurand/Hateoas library to expose my Doctrine objects via an HATEOAS api which luckily is a fairly trivial thing to do. All you need to do is set up the Hateoas serializer and call the respective serialize() method passing your Doctrine object as well the serialization type.

He shares the code to make the integration work, pointing out that the ramsey/uuid-doctrine library makes masking the autoincrement database identifiers (their "id" column) with UUIDs easier. He shows how to integrate this Uuid data type into the Doctrine docblock configuration and how to use the HateoasBuilder to handle the serializer instance containing the Doctrine object/results.

Joe Fallon has a post to his site talking about immutable objects in PHP, objects that once the property values are set they cannot change.

When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed.

[...] Now, I favor creating immutable objects. The folks over in the functional camp are super excited about this concept. However, it’s been around for quite a while and it has so many benefits.

He talks about how immutable objects make it easier to not only test code but also allow for more rational reasoning about their contents. He points out that they also make it easier to understand the state of an application should an exception arise. He then gets into some examples of immutable objects, creating an ImmutableClass and a ImmutableClassBuilder to help create instances based on values provided.

The SitePoint PHP blog has a new tutorial posted from author Daniel Sipos about form handling in Symfony2. More specifically, about creating them and handling the results from their submission. This is an introduction to the topic and gets into two examples, one focusing on a view implementation and the other using the form builder.

In this tutorial we will look at two examples of using forms in Symfony 2. In the the first, we will place form elements straight in the View file and then handle the form processing manually in the controller. In the second, we’ll use the Symfony form system to declare forms in an object oriented way and have Symfony process and persist the values. We will be working on a simple installation of the Symfony framework.As you may know, it comes with a default bundle called AcmeDemoBundle and we will use that to illustrate working with forms.

In the first example he looks at "non-entity forms" and shows how to create the form from normal HTML elements in the view. The form is just a simple input field and a submit button. He includes the code you'll need to process the form submission too. In the second example he includes an example of how to create the same setup but using the Form Builder instead. It's also links it to a data object, making it simpler to save the submission results.

In his latest post Gonzalo Ayuso shows how you can automatically inject dependencies into your PHP objects with the help of Pimple, a simple dependency injection container.

I must admit I don’t really know what’s the correct title for this post. Finally I use “Auto injecting dependencies in PHP objects”. I know it isn’t very descriptive. Let me explain it a little bit. This time I want to automate the Hollywood Principle (“Don’t call us, we’ll call you”). [...] We need to use Reflection to create our instance and to call our action. Sometimes I need to work with custom frameworks and legacy PHP applications. I’ve done it in a couple of projects, but now I want to create a library to automate this operation.

He includes a simple example of a "Controller" class that is injected with a "Request" via constructor injection. He refactors this to create the dependency injection container with a "Builder" class) and shows how to fetch the instance of the "Bar" class from it. It's this Builder class he shares on GitHub.

In the latest post to his MaltBlue.com site Matthew Setter takes a look at magic methods. He tries to answer a few basic questions about them - are they worth using and can you truly test effectively when they're in use.

As a freelance Zend Framework developer, I’m always looking to improve the quality of the applications I produce. So over the last 6 – 12 months, I’ve been learning as much as possible about testing. During this time, I’ve found the way I code’s dramatically changing (and improving). [...] In a recent development session, I attempted to test some of my ZendDb based classes, specifically the code which used the magic methods for dynamically building where clauses. [...] I can’t speak for what it’s like using PHPUnit’s mock objects, as I always use Mockery instead. But after attempting to do so in Mockery, I hit a stumbling block when trying to test the chained call.

His example is a call to "lessThanOrEqualTo" to create his where clause that makes use of the "__get" magic method to get and return "Where" object. After some research (and conversations on IRC) he started wondering if the magic methods were worth the trouble they may cause during testing. He references this post and lists several of the comments made about their use, most of them not in favor.

Alex Bilbie has passed along a link to a project he's been working on to try to simplify access to MongoDB databases from PHP - his MongoQB library:

A few years ago I released a MongoDB library for the CodeIgniter PHP framework which has become quite popular thanks to it’s likeness to CodeIgniter’s query builder library. I’ve just spent the last week travelling and to keep myself occupied I spent some time re-architecting the library’s code; removing the framework dependancy, making it Composer friendly and adding a full suite of unit tests. Check out the code on Github - https://github.com/alexbilbie/MongoQB.

The library makes it simpler to do most of the usual CRUD (Create, Read, Update, Delete) operations with your Mongo data. Example code is included in the post. This is a nice lightweight alternative to things like the Doctrine query builder.

Giorgio Sironi has a new post to his blog about a "refactoring" he's done of PHPUnit's mock objects to make their creation with getMock easier.

Not an actual refactoring, but at least the introduction of a layer of indirection, a Parameter object, called PHPUnit_Framework_MockSpecification. I have already written the patch in a branch of my github repository. They are actually two independent patches, since PHPUnit core and the mocking component are in two separate repositories.

If you create a basic object, the creation is simple, but when you start wanting to use one of the other optional parameters down the line, things can get messy. His solution adds methods like disableOriginalConstructor and disableAutoload to make this simpler. You can find the patches on his github account.

UPDATE: This feature has been included in the latest PHPUnit master branch.

Starting off a new series on his blog Giorgio Sironi has posted two new tutorials looking at PHP design patterns - specifically the Abstract Factory and Builder patterns.

[This series will] touch the majority of the known design patterns, with a special look at their application in a php context. A running code sample will be provided for each part of this series, along with the theory and the terminology of each pattern.

In the Abstract Factory (or just Factory) post he includes a diagram of the pattern's relationship with other "participants" and has a Zend Framework-based code sample to create a simple WidgetHelper. In the second article he looks at the Builder pattern and how it can make creating instances of complex objects a bit easier. As before a diagram and code are included.

You can keep up with the rest of the posts in the series as they're added by following along here.