@@ -16,10 +17,6 @@ To store items in the session call the put method on the Session class:
The first parameter is the **key** to the session item. You will use this key to retrieve the item from the session. The second parameter is the **value** of the item.
The **flash** method stores an item in the session that will expire after the next request. It's useful for storing temporary data like status or error messages:
Session::flash('status', 'Welcome Back!');
<aname="get"></a>
## Retrieving Items
...
...
@@ -53,6 +50,27 @@ You can even remove all of the items from the session using the **flush** method
Session::flush();
<aname="flash"></a>
## Flashing Items
The **flash** method stores an item in the session that will expire after the next request. It's useful for storing temporary data like status or error messages:
Session::flash('status', 'Welcome Back!');
Flash items that are expiring in subsequent requests can be retained for another request by using one of the **reflash** or **keep** methods:
@@ -304,7 +304,26 @@ Once you have performed your validation, you need an easy way to get the errors
Great! So, we have two simple registration routes. One to handle displaying the form, and one to handle the posting of the form. In the POST route, we run some validation over the input. If the validation fails, we redirect back to the registration form and flash the validation errors to the session so they will be available for us to display.
**But, notice we are not explicitly binding the errors to the view in our GET route**. However, an errors variable will still be available in the view. Laravel intelligently determines if errors exist in the session, and if they do, binds them to the view for you. If no errors exist in the session, an empty message container will still be bound to the view. In your views, this allows you to always assume you have a message container available via the errors variable. We love making your life easier.
**But, notice we are not explicitly binding the errors to the view in our GET route**. However, an errors variable ($errors) will still be available in the view. Laravel intelligently determines if errors exist in the session, and if they do, binds them to the view for you. If no errors exist in the session, an empty message container will still be bound to the view. In your views, this allows you to always assume you have a message container available via the errors variable. We love making your life easier.
For example, if email address validation failed, we can look for 'email' within the $errors session var.
$errors->has('email')
Using Blade, we can then conditionally add error messages to our view.
{{ $errors->has('email') ? 'Invalid Email Address' : 'Condition is false. Can be left blank' }}
This will also work great when we need to conditionally add classes when using something like Twitter Bootstrap.
For example, if the email address failed validation, we may want to add the "error" class from Bootstrap to our *div class="control-group"* statement.
