On the Laravel News site there's a new post that gets into detail about length testing in Laravel. This testing evaluates the length of the text data taken in as input from some outside source (usually user input).

I thought it might help people new to the Laravel framework and testing, to walk through how to test length validation. When I say length validation, I mean the constraints of length that you might want to put on a string field.

[...] When testing lengths, there are a couple of techniques I think can be helpful that I use with HTTP tests to verify that my validation is working as expected. Let’s walk through some hands-on examples of the validation portion of a controller request; we will also need a test database to demonstrate a test that interacts with a database.

They start by creating a new Laravel project and adding in some basic "user" functionality to store them in a local SQLite database. It then shows the code required to validate the incoming data on the "store" method including the "max" validation handling on the email address. It then shifts over to the actual testing of the validation, writing checks to ensure the maximum length is enforced with a random string, doing the same with an email address and handling cases of multiple validation tests.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

On his Medium blog Peter Lafferty has written up a post showing you a method for HTTP request validation in Silex, the microframework from the creators of Symfony.

This article covers three validation scenarios: routes, query strings [and] POST with a JSON body.

He starts with a simple Silex application that creates a "RESTful" API with endpoints providing emojis back when queried (three endpoints). He then uses this to show how to validate:

• routes for their expected values in the URL
• using a ValidatorService provider to build a set of assertions (GET request)
• using the same service to create assertions for the JSON content of a POST request

All code required is included in the post including the correct handling of the emoji output via a UTF-8 JSON response handler.

On the Laravel News site there's an article covering custom validation objects and using them in a Laravel-based application. This validation handling is added in Laravel v5.5 (upcoming as of the time of this post) to allow for easy extension of current validation rules.

Laravel 5.5 will introduce support for custom validation rule objects as an alternative to using Validator::extend for custom validation rules.

To define a custom validation rule, implement the IlluminateContractsValidationRule interface or use a Closure. The custom rule is then used directly in a validator.

They provide a few examples of defining these objects, using the "passes" and "message" methods defined in the interface. It also shows how to put them to use in a "validate" call on a request using both the object and closure versions. This new custom validation handling helps to replace some of the difficulty with the previous extension methods and makes it more flexible by allowing closures.

The NetTuts.com site has a new tutorial posted covering form validation in CodeIgniter "from start to finish" showing you how to use the built-in functionality to verify the information coming from your users.

As a web application developer, form validation is a crucial part of your work, and it should not be underrated as it could lead to security flaws in your application. You should consider it a must if you're striving to provide a professional end user experience.

In this article, we'll go through the built-in form validation library in the CodeIgniter framework. Here are the highlights of today's article: [The use of ] basic form validation, cascading and prepping, custom error messages, custom validation callback, and validation configuration

They start off by covering some of the basic included rules using a simple controller and view. These checks include values being required, maximum length of text, alphanumeric only, valid email and checking that the value is a valid IPv4 address. The example also shows how to make use of the "cascading" rules and using the rules system to "prep" the data first. They walk through each line of the code that defines the rules talking about what it does and how they can be adjusted to fit your needs. They cover more in-depth how cascading and prepping work, how to customize error messages and create custom callback validation rules you can apply along with the standard ones.

The Zend Framework blog has continued their series spotlighting various components of the framework with their latest installment. In this latest tutorial they cover the zend-validator component used to validate data against a set of rules for correctness.

In our previous post, we covered zend-filter, The filters in zend-filter are generally used to pre-filter or normalize incoming data. This is all well and good, but we still don't know if the data is valid. That's where zend-validator comes in.

The post starts with showing how to get the component installed via Composer and the optional dependency of the zend-service-manager component (to handle the use of ValidatorChain functionality). Code is included showing the interface the validators all conform to and an example of the validator in use. It then covers some of the built-in validation options and how to build up a validator "chain" of multiple checks. It also shows how to break the validation if one fails, setting priority (order of execution), evaluating values in certain contexts and registering your own custom validators.

In this new post to his site Leonid Mamchenkov talks about validating JSON content sent to your application to ensure it matches a JSON schema definition.

GitHub was rather slow yesterday, which affected the speed of installing composer dependencies (since most of them are hosted on GitHub anyway). Staring at a slowly scrolling list of installed dependencies, I noticed something interesting.

Of course, I’ve heard of the seld/jsonlint before. It’s a port of zaach/jsonlint JavaScript tool to PHP, written by Jordi Boggiano, aka Seldaek, the genius who brought us composer dependency manager and packagist.org repository.

But JSON schema? What’s that?

From there he gets into a high level definition of what JSON schema is and the similarities it has to XML's structure. He then links to a PHP package that can help with the validation and how to use it (defining a simple JSON file, a schema and the code to perform the evaluation).

On the Full Stack Radio podcast host Adam Wathan is joined once again by Jonathan Reinink to follow up their previous show and talk more about complex validation.

In this episode, Adam and Jonathan continue their discussion about forms from episode 54, this time focusing on the complexities of validation.

Topics mentioned include form requests in Laravel, a forum post about a possible bypass of CVC and ZIP checks with Stripe and HTML5 form validation. You can listen to this latest show either through the in-page audio player or by downloading the mp3 directly. If you enjoy the episode, be sure to subscribe to their feed and follow them on Twitter for updates on when new shows are released.

Mohammed Said has a new post to his site sharing how you can add validators conditionally in Laravel based on different requirements using the "sometimes" method.

Laravel's validation library is very powerful and easy to use, using a few keystrokes you can build a strong defence around your application, preventing invalid user input from corrupting the application flow and potentially introducing bugs.

In this post I'd like to highlight a trick related to conditionally adding validation rules, this trick is specially important since I've seen many people on Laravel's GitHub repository opening issues complaining about an un-expected validator behaviour.

He sets up a simple scenario where the "subject" value is required allowing for a custom value but validating the length if custom is selected. He then shows how to modify things to use the "sometimes" method for conditional checks for the same "custom" checking. He also shows how to pass in multiple fields and how to evaluate a "model exists" for a user.

On the Laravel News site there's a quick post looking at Laravel's login validation and how you can make updates to its handling (and where the changes should be made).

Laravel’s included auth system is a great way of scaffolding out a basic flow for authenticating users through a complete registration, login, logout, and forgot password system.

When it’s all setup the login and password reset validation is stored in an AuthenticatesUsers and ResetsPasswords trait. Even though it’s a little hidden away it’s still easy to adjust this to your needs. Let’s take a look at how to adjust this.

The post then breaks each of these down, showing where in the framework source the code lives and how you can update or override the current handling. The login validation lives in the default "AuthenticatesUsers" trait and the password reset verification is in "ResetsPasswords". These can each be overridden in your own controllers as they're just methods included via traits.