Easy Flashdata Notifications
With their clean designs and minimized feature-set, 37signals’ applications have popularized the flashdata notification. Whether it be an error or a success message, this form of communication with your users is up-front, easy to understand, and user friendly.
In this CodeIgniter tutorial, I’ll show you how to implement flashdata notifications with the Session library. We’ll start by understanding the code behind the notification, we’ll then clean it up a bit and add in support for multiple notification types, and finally we’ll turn it all into a new library and helper so you can use it easily within your own applications.
Understanding Flashdata
At it’s core, flashdata is nothing more than session variables with some neat little tricks thrown on top. Flashdata variables are designed to be created within one request and only used in the following request, after that it is deleted. This could be used for a variety of reasons but is most commonly used to produce error and success messages.
For example:
- User A attempts to login to your site but gets his password wrong.
- Your form processor catches the error and saves an error messages to a flashdata variable. Then the user is redirected to the login form controller again.
- The login form’s view sees that an error message now exists, displays that to the user, and the controller deletes the error message at the end of the request.
Now, lets take note of a few things in this example:
- The error message wasn’t displayed to the user the first time they visited the form. This is because the flashdata variable was not defined at that time.
- After the flashdata variable is defined, the controller redirects the user back to the form (rather than just loading the form view). Flashdata variables are only available upon the next request, not during the current request (which is what loading a view would accomplish).
- The flashdata variable is deleted at the end of the next controller’s lifecycle. This behavior can be modified, forcing the framework to maintain the variable again, until the next request - but we won’t be utilizing that functionality within this tutorial.
So, you’re ready to get to the code, right?
Nice tut. Wondering though why you do not handle both setting and getting/displaying in the one library and just autoload it?
You definitely could - I just wanted to use this tutorial to introduce the creation of your own libraries and helpers.
Plus, the helper cuts down on a little bit of typing within your views by not referencing the CodeIgniter super-class or the Flashnotice class.
Now I really understand what flash session data is. I was completely clueless even after I read the documentation (or maybe I didn’t read properly).
Great first tutorial
I like this. It’s a great tutorial. And a great approach.
The only question I have is in regards to the example. Wouldn’t you want to flash a notice if the username didn’t pass the “required” validation also?
I guess you would want to flashnotice->set if the contents of $this->validation->username_error wasn’t null? Or something along those lines?
But I like it. And will use it.
Thanks!
@Walt
We do - in a round about way - by issuing a flashnotice if the username is not correct. Does the user (or us, the developer, for that matter) really care whether the username was submitted or not?
The bottom line is, the login information is incorrect - if the username does not equal what we specifically define (or what has been established in a database).
Login screens can be tricky - you don’t want to give away to much information. By telling users all sorts of information about every field you could easily introduce a way for a bot to continue submitting a form until they find a valid entry.
For example: Let’s say we are using email addresses for a user’s username and if a username is submitted that doesn’t exist in our database we send a flashnotice message “that account does not exist.”
Now, our site is about dogs and Joe Spammer has a nice spam message he wants to send out about buying stock in dogs from a Zimbabwe king (he just needs your bank credentials and you can keep half the money).
So - he runs his list of addresses through our login page and he now has a confirmed list of people who are interested in dogs.
Kind of an outlandish example but there are hundreds more scenarios of this nature with much worse end results for your users.