session
or cookie
scope with some added
functionality. It is cleared at the end of the next page that the user views.
This means that it's a good fit for storing messages or variables temporarily
from one request to the next.edit
action. Please note that this is done on the next
request since we performed a redirect after setting the Flash.success
, but it could have been anything that we wanted. Just like with a normal struct, the naming of the keys is your job.error
, and another one for storing messages after a successful user operation, called success
.success
argument coming in and knows that it's not part of its own declared arguments.flashInsert(success="The user was updated successfully.")
for you behind the scenes.edit
action and set a key in the Flash
named action
as well? Simply prepend the key with flash
to tell Wheels to
avoid the argument naming collision.action
, but these naming
collisions can potentially happen when you want to redirect to a route that
takes custom arguments, so remember this workaround.StructClear
and StructDelete
—they clear
the entire Flash and delete a specific key/value from it, respectively.<p>
tag on requests where the Flash is empty.
( flash() will return an empty string when the specified key does not
exist.)class
attributes set
similarly (errorMessage
for the error
key and successMessage
for the
success
key).key/keys
argument to limit its reach
to a list of given keys. Let's say that we only want our layout to show messages
for the alert
key but not for the error
or success
keys (or any other for
that matter). We would write our call like so:cookie
or the session
scope. You can find out where Wheels stores the Flash
data in your application by outputting get("flashStorage")
. If you have
session management enabled in your application, Wheels will default to storing
the Flash in the session
scope. Otherwise, it will store it in a cookie on the
user's computer.session
scope, you need to make sure
that session management is enabled. To enable it, all you need to do is add
this.SessionManagement = true
to the config/app.cfm
file.session
scope. Users could open their cookie file up and manually change its value.
Sessions are stored on the server, out of users' reach.set(flashAppend=true)
to you /config/settings.cfm
file.flashMessages()
would render:set(flashAppend=true)
, you can also directly pass in an array of strings like so:2.2
upwards:cookie
as a viable route. But if set to cookie
, you always get Set-Cookie
being returned, which is unnecessary.set(flashStorage = "none")
which will prevent the creation of the cookie, and also not try and write to a session.