Different Vars require different mechanisms for synchronization.
Different Vars require different mechanisms for synchronization. This method implements the Var specific synchronization mechanism
Generate a function that will take a snapshot of the current RequestVars such that they can be restored
This defines whether or not Lift will log when a RequestVar is set but then not read within the same request cycle.
This defines whether or not Lift will log when a RequestVar is set but then not read within the same request cycle. Change this to false to turn off logging. Logging can also be turned off globally via LiftRules.logUnreadRequestVars.
LiftRules#logUnreadRequestVars
Return a function that, when applied, will set the value of the RequestVar to its current value
Is this RequestVar a member of a snapshot group? If so, specify the group here
A typesafe container for data with a lifetime nominally equivalent to the lifetime of a page rendered by an HTTP request. RequestVars maintain their value throughout the duration of the current HTTP request and any callbacks for servicing AJAX calls associated with the rendered page. RequestVar instances have no value at the beginning of request servicing (excluding AJAX callbacks) and their value is discarded at the end of request processing. They are commonly used to share values across many snippets. Basic usage:
object MySnippetCompanion { object myRequestVar extends RequestVar[String]("hello") }The standard pattern is to create a singleton object extending RequestVar instead of creating an instance variable of a concrete RequestVar subclass. This is preferred because RequestVar will use the name of its instantiating class for part of its state maintenance mechanism.
If you find it necessary to create a RequestVar subclass of which there may be more than one instance, it is necessary to override the nameSalt() method to return a unique salt value for each instance to prevent name collisions.