PHP: How to safely call a dynamic function

1. How to call a built-in function in PHP (part one)
2. How to write and call your own function in PHP (part two)
3. How to safely call a dynamic function in PHP (part three)

Introduction

PHP has a library of built-in functions. Different functions are available depending on the PHP version you are running, and the extensions you enable. You can extend this library at run-time by writing your own functions.

This article demonstrates how to call a built-in function, how to write and call your own function, and how to safely call a dynamic function.

How to safely call a dynamic function in PHP

With PHP, it's also possible to call a functions in a slightly different way. This technique will mostly become useful when you want to start writing very generic code. For example, we use this technique for form processing on all of our websites.

How does it work?

By using a combination of the is_callable() and call_user_func() functions, you can safely call any function. Below is our generic "Functions" object. It allows us to safely call functions dynamically.

The example shows the function doSomething of class SomeClass is being statically called, and passed "A text string" as the data.

A more practical example

As I mentioned previously, we use this technique for handling the submission of all of our forms. This is where stuff starts to get a bit more advanced, but stick with it because the end result is cool.

Assume the following:

1. You have two simple forms:
   1. A simple login form with email address and password fields e.g. our login page.
   2. A simple password request form with an email address field e.g. our password request page.
2. You use three web pages per process: one for showing the form, one for processing the request, and one for displaying a success page.
3. Both forms are simple form objects, extending a more complex, generic form object.
   1. The simple form objects contain basic information about the form. E.g. The labels to use next to the form fields, and the name of the function to call when the form is being processed.
   2. The parent, generic object contains functions that handle the simple forms being submitted, error handling, etc.

Using this model, I know that when the above two forms are submitted, for 90% of the process, they are being handled exactly the same way. The other 10% is whatever is specific to the form, e.g. logging the user into their account, or emailing the user their password.

If you want to see this in action, try it out for yourself:

1. Open our login page and retrieve password page.
2. Don't fill in any details, just hit the login or retrieve password button.
3. You'll see that the our system gives you a generic error, then highlights specific fields that are in an error state.

By using the generic model above, both forms are handled by more or less the same code. This means that we can ensure that all of our forms are rendered in a similar way, errors look consistent, and importantly that input data is cleansed in just one place in the system before being processed by each form's own function.

The Code

The following code is our retrieve password form object. The login form is basically the same, with exception of the fields, and the values passed to parent::__construct().

Notes on the above:

1. HtmlForm::POST is a constant to indicate what type method the form should use.
2. Path::root(true) is a generic function that will return the root URL of the website. The "true" indicates that it should be a secure URL if it is available. This is how we can use the exact same form/code for several websites at the same time.
3. FormStructure is an object used to store different types of form field, and their state.

And a cut-down version of the base class:

When the form is submitted, the HtmlForm::submit function runs. The data from the form is passed through as an array, with the form field as the key, and what the user entered as the value.

A few lines down and you can see Functions::unary. This is where the magic happens. The retrieve password or login forms have told HtmlForm what function to call. HtmlForm calls the function and passes the data from the form. The function can then do whatever it needs to do.

If no errors occur, the user goes to the success destination (which could either be a simple success page, or their account screen if they have just logged in). If an error occurs, the base HtmlForm class handles those for us. Neither the individual form objects, or the function that has been called need to do anything. The user is returned to the original form screen and the errors are displayed.

Cool, huh?

What does this mean?

1. You're processing data in one location: Imagine if each form implemented the basic processing itself. You have hundreds of forms. Then you discover a weird security issue that needs to be addressed. Oh dear - you have hundreds of forms to update. This model means you do it one place.
2. Making new forms is faster: You can create new forms that are handled safely very quickly. Yay.
3. By making the forms generic, you can re-use them (which is not the same as copy & paste). See our login page, Moody's login page, or Annie Hill's login page. The same, right? Right. The exact same code is run. Boring? These sites don't need fancy login screens. Take a look at Extrascents. The exact same thing, just ever so slightly nicer.
4. We've come a long way from the sausage calculator.

That concludes this three part article, thanks for reading. If you like this article, please show the love by leaving a comment, liking our Facebook page, or following @switchplane on Twitter. You can also follow me personally on Twitter @tom_fielder.