On the Sticher.io site a new tutorial has been posted introducing you to Laravel view models. This functionality allows you to remove view-only logic from other parts and isolate it for transformation.

View models are an abstraction to simplify controller and model code. View models are responsible for providing data to a view, which would otherwise come directly from the controller or the model. They allow a better separation of concerns, and provide more flexibility for the developer.

In essence, view models are simple classes that take some data, and transform it into something usable for the view.

The post starts with some of the basics behind the "view model" design pattern and jumps in to an example for a blog site. In it, the code pulls in the category listing that's needed to display the page, removing the need for it to be in the controller code. It also includes the addition of custom logic to the model and the refactoring that can help move the logic into it. The tutorial also includes a section covering some of the "niceties" that can be added including passing it directly to the view method, returning it as JSON and returning individual properties as JSON.

Tomas Votruba has a post to his site sharing his top seven tips for writing exceptions that "everyone will love" and how they could be considered a more than just a programming tool.

Do you ever had that feeling, that you've seen that exception before and you know what it means and how to solve? What if that would be clear even for those who see it for the first time? It would save yours and their time.

Exceptions are not just error state. Exceptions are the new documentation.

He starts off by describing a situation just about any developer would be familiar with, the "circle" where an exception is thrown when something breaks and there's no additional information so you're back to where you started. Based on his work in the EasyCodingStandard he's come up with seven tips to help prevent this in your applications:

1. Make Exception Names for Humans
2. Use " around" Statements
3. What Exactly is Wrong?
4. What is The Wrong Value?
5. What File Exactly is Broken?
6. What Options do I have?
7. Link what You can't Fit 140 Chars

For each item on the list there's code snippets illustrating the suggestion and a brief description for more context.

TJ Miller has written up a post for his site sharing a method he's created to verify the compatibility of a package in Laravel based on the version of Laravel installed.

I’ve been working with Honeybadger to build a new set of PHP integrations. I would like to write more about that soon, however, I feel like I’ve stumbled across something that could be useful to others. I wanted to share it as soon as I could.

For the Laravel package, I was aiming for Laravel 5.5 and newer support as it is the latest LTS version. [...] In hindsight, I don’t think that I actually ever tested it against a 5.5 install. I relied on the CI process to make those verifications for me.

[...] As Laravel 5.7 is now out, I needed to add support to both the package’s composer configuration and verification in CI. [...] Now that I am supporting three versions I felt that I needed a more specific way of verifying compatibility with different versions of Laravel.

He shares his initial version of his Travis-CI configuration, running tests on PHP 7.1 and 7.2 with the prefer-lowest flag. In order to make it easier, he updated this based on what he'd seen in other packages: adding a matrix that runs PHP 7.1 through 7.3 against versions 5.5.x, 5.6.x and 5.7.x to ensure compatibility across all variations. His resulting build looks something like this.

Nikola Posa has a new post to his site sharing what he calls a "community-driven PHP 8 wishlist" as gathered from replies to a tweet he posted back in July 2018.

It's been over two months since I started a research on Twitter about the things that developers would like to be added or improved in the next major PHP release. [...] It had a surprisingly long reach, inspiring developers, prominent experts, community representatives to express their opinion through more than a hundred responses.

It would be a waste to leave such a valuable data in the form of a raw and fuzzy Twitter thread, so I finally found some time to turn it into something more useful.

In the post he shares the results in a spreadsheet, with the top three being: arrow functions, multi-threading and method overloading. Other interesting features also made an appearance pretty high on the list including boot-time preloading, scalar objects, native async and built-in request/response objects. Check out the post for the complete list and how it was processed into its final form.

Latest PEAR Releases:

• PHP_CodeSniffer 3.3.2
  

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.

Larry Garfield has written up a post with a somewhat controversial headline, especially for anyone that's done any kind of unit testing on a larger codebase. His suggestion is to no use mocking libraries and some other techniques that can replace them.

I am all for testing. [...] There's a lot of opinions on what constitutes a "good" test, of course, and much is subjective to the type of code you're working on. However, since the release of PHP 7 I've found that while writing tests... I am never using a mocking library. In fact, I'm going to go as far and say that you should never use a mocking library in PHP 7.

Before all of you gasp, clutch your pearls, and send ninja hit squads after me, let me justify that position.

He starts off by defining what a "mock" is a more general sense and then, more specifically, how mocking libraries are mostly implemented in PHP. He covers the DSL (domain specific language) knowledge that's required to use most of them and how something already included in PHP 7 - anonymous classes - could be a viable alternative. He goes on to show examples of using this method rather than a mock for simple object handling and even recommends making an actual class (just for testing) if the need is there. He ends the post talking about the "upper bounds" of when this might not be as useful and how this can actually be good (using it as an indicator that you need to refactor the main code to simplify).

In a new post to his site Matthias Noback takes a look at the concept of assertions and some libraries including some effective ways to use them in your code for validation of values.

When you're looking at a function (an actual function or a method), you can usually identify several blocks of code in there. There are pre-conditions, there's the function body, and there may be post-conditions. The pre-conditions are there to verify that the function can safely proceed to do its real job. Post-conditions may be there to verify that you're going to give something back to the caller that will make sense to them.

[...] Sometimes the programming language itself can help with these pre-conditions: for instance, the language may support strict typing, which prevents certain types of invalid input to be provided. Some languages offer more advanced ways of defining pre-conditions, like pattern matching.

Following a brief use case for assertions (at a high level) he gets more specific to PHP and mentions two assertions libraries that could be used to add these kinds of checks to your code (in addition to PHP's own assert function). He then answers the "why use assertions?" question and some basic rules around using them:

• don't use assertions to validate user input, use it to validate function arguments.
• don't use assertions to validate return values from other functions.
• don't use assertions as a replacement for exceptions.

For each of these, he provides a summary with a bit more background and code examples to help illustrate the point. He ends the post with some useful "rules of thumb" when using assertions and a reminder:

Assertions are sanity checks. When they would be left out, you should still have a correctly function application. They should never become user-facing errors.

Tomas Vortuba has a new post on his site sharing information about one of the improvements that has been added to the Symplify, specifically in the PackageBuilder.

PackageBuilder was always sort of meta package with all the cool and shiny features anyone can use. After all, it's the most downloaded Symplify package hitting almost 1000 downloads a day.

In Symplify 5 now it allows you to drop manual binds from Symfony configs, separate files from directories in one method and merge nested YAML parameters with 1 service.

He lists out the three notable changes:

1. Drop Manual Binds in Symfony configs
2. Separate Files from Directories
3. Merge Parameters without Leaving Any Behind

For each item in the list, he provides a link to the pull request that implemented it, a basic summary of the changes and code examples of what it enables.

Popular posts from PHPDeveloper.org for the past week:

• StarTutorial.com: Modern PHP Developer - Composer

• AWS Developer Blog: Introducing support for Amazon S3 Select in the AWS SDK for PHP
• php[architect]: PHP 7.3 is On Track
• DeliciousBrains.com: PHP Encryption Methods for Passwords & Other Sensitive Data
• Jolicode.com: How to Mix Security and Form with Symfony
• Matthias Noback: Assertions and assertion libraries
• Tomas Votruba: New in Symplify 5: 3 New Cool Features of PackageBuilder
• Larry Garfield: Don't use Mocking libraries