If you’ve found an error, spotted something missing, or feel a section could be clearer or better explained, we’d love to hear from you. Your feedback helps keep the documentation accurate and useful for everyone.
Please report issues or suggest improvements on GitHub. Community input is invaluable in making the docs stronger.
Not comfortable with GitHub? No problem — you can also get in touch with us directly via our contact form. We welcome all feedback.
Displaying Validation Errors
In the previous pages of this chapter, we've deliberately avoided going into detail about what to do when there are server-side form validation errors. On more than one occasion, we've offered code samples that look like this:
Now, let's explore how to handle server-side form validation errors in a professional and graceful manner.
The Importance of HTTP Response Status Codes
With traditional, PHP-based form handling, HTTP response status codes are not considered important. Indeed, it's possible to enjoy an entire career as a PHP developer without ever using or even knowing about HTTP response status codes!
When you're working with Trongate MX, however, HTTP response status codes become very important.
The HTTP response status code returned by your server - after a form submission - can be used to indicate whether the form passed the validation tests or whether validation errors occurred.
For more information about HTTP response status codes, visit MDN Web Docs: HTTP Response Status Codes.
Sending Appropriate HTTP Response Status Codes
When form validation errors occur, it's widely considered a best practice for the server to return an HTTP response status code of either 400 (Bad Request) or 422 (Unprocessable Entity). These codes clearly signal to the client that the request was received, but that there was a problem with the submitted data.
Conversely, if the form submission passes validation and is processed successfully, it's customary to return a 200 (OK) response status code.
In PHP, sending an appropriate HTTP response status code is remarkably straightforward and can be achieved with one line of code. For example:
Incorporating proper status codes not only improves the clarity of communication between the server and client but also lays the groundwork for building more robust, API-friendly applications.
How To Render Server-side Validation Errors
Trongate MX builds on the principle of returning meaningful HTTP response status codes by allowing your endpoint to return a response body that contains an array of validation errors. These errors can then be automatically extracted and displayed by Trongate MX on the front end. This is made possible using the validation_errors() form helper function.
If that last paragraph seems a bit overwhelming - don’t worry!
When it comes to handling server-side validation errors, Trongate MX takes care of all the complex logic behind the scenes. You don’t need to understand how the response body is parsed or how the errors are rendered - it just works!
If you're already familiar with Trongate’s traditional form handling, you might know that validation_errors() is typically used within view files to display validation error messages. However, when working with Trongate MX, we use validation_errors() differently - by calling it from your controller and passing in the desired HTTP response status code. For example:
Using validation_errors() this way eliminates the need to separately call http_response_code(). It handles both setting the HTTP response code and returning the validation errors in one clean, elegant statement. This makes your controller logic more concise and efficient.
Here’s what this looks like in practice:
What About the Front End?
Now that we’ve covered how server-side form validation works, let’s turn our attention to the front end. Our next goal is to display form validation errors when they occur - clearly and elegantly.
To automatically render server-side validation errors on a submitted form, simply add a CSS class of highlight-errors to your opening form tag. Here’s an example:
In Conclusion
The ability to dynamically render inline form validation errors - with just two lines of code - is arguably one of Trongate MX’s most impressive features.
Ask yourself:
"How long would it take to build this kind of functionality without Trongate MX?"
Even for an experienced developer, building this from scratch could take hours or require dependence on third-party libraries.
What truly sets Trongate MX apart is that it lets you harness the power of Trongate’s Validation class, built-in security, and form helpers - right out of the box. You can create beautiful, highly interactive single-page applications without writing any JavaScript, and without relying on any third-party libraries.
And There’s More!
With Trongate MX, you can also invoke your own custom JavaScript functions after validation errors have occurred. Full details on how to use this advanced functionality are offered on the next page.