The examples on this site are currently tested to work on Phalcon V3.4 and Phalcon Devtools V3.2 Some issues may arise when using later versions.

Please get in touch or post a comment below the post if you encounter a problem.

Validating user submitted data is a vital part of building a system. For any given attribute there is generally a range of different possible allowable values. For text based data this might be the maximum number of characters allowed in a field, for numeric data it could be a minimum and maximum allowable number. Although a system can function without restricting the data entered it is highly desirable to ensure good quality data is entered. As the adage goes "Garbage In Garbage Out".

Beyond the simple validation of data business rules may be used to make calculations of certain derived attributes. The fee for making a booking in the tennis club, for example, should be calculated on a cost per hour basis where the cost may be different for Senior vs Junior members. We will leave this kind of more complex business logic to one side for the moment as we focus on validation of data.

The other important point to note about validation of data is that there are normally a number of options as to where this validation logic is placed. At a simple level validation can either take place on the client side (typically using javascript or jQuery) or on the server side using the programming language of the server - in our case PHP and Phalcon. Validation rules and constraints are also often included on the database itself and more complex rules can be implemented using 4GL Stored Procedures and Triggers in the case of relational databases.

How and where the validation is processed can also have a big impact on the UX of the system. Consider, for example, a system which lets the user know with each keystroke whether the password they have chosen qualifies as "Strong" or "Weak". The immediacy of this provides for a clear and responsive UX. The alternative whereby a User must submit their chosen password and wait a couple of seconds only to be told their password doesn't qualify would be frustrating to most users of modern systems who are used to the former approach.

A password strength rule which requires the user to enter a password of at least one upper case, one lower case, one special character and be a minimum of 8 characters doesn't require information from anywhere else and so can easily be implemented using client-side scripting. A validation rule that needs to check if a particular username has already been chosen however will need to query the database. This kind of rule is more easily implemented using server side logic. It is possible to implement this on the client side in a responsive way using AJAX scripting but this approach adds a layer of complexity. Software engineers decide on how best to implement this intelligence depending on the type of business rule and the importance of UX to the success of the system.

Over the following few posts we will focus on how to create simple server-side validation rules which can be implemented on Model classes.

A very important part of validating information is relaying an appropriate message to the user in regard to the data validity. The validation classes of the PhalconPHP API work together with the model messenger to relay information. This message class can also be used by programmers writing more specific customised business rules. I look at this approach in a later post.

The scaffolder includes the following code when saving or updating data.

if (!$member->save()) {
	foreach ($member->getMessages() as $message) {

		'controller' => "member",
		'action' => 'new'


If the $member object was not successfully saved to the database this code will output any and all messages arising after the dispatcher has forwarded the application to the next appropriate action. Messages appear in a twitter bootstrap "well" at the top of the next screen the user has been directed to.

Along with the validation class itself ( there are a wide range of validator classes which allow the programmer to test a wide range of different validation rules. Each time a validator is added the user supplies a message which will be appended to the model and output to the user if that particular validation rule is broken. If a number of different validation rules are broken, in accordance with the foreach loop above, each of the messages which has been appended to the model will be output to the screen.

In the next post we will add some simple validators to attributes in the member model.