Parameters, Defaults, Variables, and Sessions

This article discusses a strategy for dealing with input values for a page including how to establish defaults, fetch values from sessions, override values with form or URL parameters, and validate inputs.

Introduction

As Web developers we spend a lot of time dealing with form and URL parameters. Since the Web is stateless we need our pages to be nimble enough that they use proper default values when the page is loaded directly in a browser, they use values from a session if the user has one, and they process parameters passed in a form or URL if they are provided.

It is good style to think of each page in your Web site as an individual program. The program accepts inputs, performs some processing, and generate some output. By grouping all the inputs in one location it is a lot easier to determine the different ways in which the page can be called and to reduce the number of side effects which can result from different inputs.

In the following code it is not too difficult to determine what inputs are expected. However, as the page becomes more complex and the inline becomes buried among other code it can be difficult to determine what the inputs of the page are at a glance. If we want to create a URL which calls this page and finds a specific group of people we need to parse through the inline, and possibly a lot more code on the actual page, and scan to find all the [Action_Param] tags within.

!insert lassosscript here

  inline(-search, -database='mycompany', -table='people',
      'first_name'=action_param('first'),
      'last_name'=action_param('last'),
      -maxrecords=action_param('max'),
      -skiprecords=action_param('skip'),
      -inlinename='people_search');
  /inline;
 
?>

 

If instead we separate out the parameters of the page into a block at the top of the page then it is a lot easier to see what parameters the page takes. Now we can see that the page takes four parameters by reading the Input Variables at the top of the page. As the page grows more complex we can maintain this portion of the page ensuring that we always know where to find the inputs.

!insert lassoscript here

  // Input Variables
  var('search_first_name') = action_param('first');
  var('search_last_name') = action_param('last');
  var('search_maxrecords') = action_param('max')
  var('search_skiprecords') = action_param('skip')
 
  // Perform Search
  inline(-search, -database='mycompany', -table='people',
      'first_name'=$search_first_name,
      'last_name'=$search_last_name,
      -maxrecords=$search_maxrecords,
      -skiprecords=$search_skiprecords,
      -inlinename='people_search');
  /inline;

?>

 

Adopting the convention of processing our page inputs at the top of the page will make it a lot easier to maintain the code in the long run including maintaining session variables, handling the precedence of different values, and handling input validation.

Setting up Variables

The first step in setting up a page is to determine what input variables we need. It is good style to define all the input variables at the top of the page in a single area. This makes it easier to determine what variables are available and how their values are going to be determined. Even if we define some temporary variables and output variables later, at least we have a good record of all the inputs of the page here.

We start by defining the variables with default values. If no other values are provided then these default values will be used directly.

For the purposes of this example we will define four variables $search_first_name and $search_last_name which will be used as search parameters within an inline and $search_maxrecords and $search_skiprecords which will be used for paging the search results.

!insert lassoscript here

  // Input Variables
  var('search_first_name') = '';
  var('search_last_name') = '';
  var('search_maxrecords') = 'all';
  var('search_skiprecords') = 0;
 
?>

 

Value Precedence

A value for a variable may be provided in several different ways. It is important to determine what precedence each of the different methods will be given within your Web solution since this will affect decisions that you make about how to structure your page. The following precedence is common and will be used throughout this tip.

1. Form and URL Parameter - The highest precedence is given to a new value which is passed through a form submission or a URL value. A valid value passed in this way will always be used. This will apply to all of the variables which we have defined.
2. Session - If a value is stored in a session variable then that value will be used (unless a new value was passed in a form or URL parameter). For this tip, we will store $search_maxrecords in a session so it is remember from page to page. We will not record the search values or $search_skiprecords so these will reset on fresh pages.
3. Default - The default value will be used if the variable has not been assigned a value. The $search_maxrecords and $search_skiprecords variables will have defaults, but the other variables will default to empty.
4. Validity - After all the precedence rules have been applied each input should also be checked for basic validity. We'll see below how the $search_maxrecords and $search_skiprecords variables are checked for validity. If the validity check fails then either the variable can be pulled into the proper value range or an error can be generated.

Your application may provide values for variables in additional ways. For example, you might store preferences in a database, store values in a cookie, have different defaults based on some additional information, or want to treat URL and form parameters differently. Some of these methods are discussed later in the tip.

Session Variables

Our application is going to use a session variable to store the visitor's preference for the $search_maxrecords value. Immediately after we define the Input Variables we load the session using [Session_Start] and inform Lasso that we want it to keep track of the $search_maxrecords variable using [Session_AddVar].

!Insert Lassoscript here

  // Start Session
  Session_Start(-name='mysite', -expires=1440, -usecookie);
  Session_AddVar(-name='mysite', 'search_maxrecords');
   
?>

 

The action of the [Session_Start] tag depends on the current visitor. If the visitor has already browsed your site then they will have a session cookie and their existing session will be loaded. The [Session_Start] tag then acts as a series of one or more [Var] tags which set the variables tracked by the session to the value used on the previous page the visitor loaded.

In our case, the [Session_Start] tag will set the $search_maxrecords value to the same value it was on the previous page the visitor loaded. To the visitor this value will become a preference which they set on one page and is remembered on subsequent pages on the site.

If the visitor is new to the site and this is the first page they have loaded then the [Session_Start] tag doesn't do anything right away. At the end of the page the session variables which are being tracked will be stored automatically and the [Session_Start] tag on a subsequent page will then be able to load those values.

Form and URL Parameters

Form and URL parameters are going to be given the highest precedence so we want to check whether a value has been passed for each of our defined variables and override the variable value if it has.

We can do this using a conditional expression. If Action_Param('inputname', -Count) is greater than 0 then a value has been specified for the input and we need to override the value of the variable. We do this for all four of our inputs.

!Insert Lassoscript here
 
  // Page Inputs
  (Action_Param('first', -Count) > 0) ?
    $search_first_name = Action_Param('first');
  (Action_Param('last', -Count) > 0) ?
    $search_last_name = Action_Param('last');
  (Action_Param('max', -Count) > 0) ?
    $search_maxrecords = Action_Param('max');
  (Action_Param('skip', -Count) > 0) ?
    $search_skiprecords = Action_Param('skip');

?>

 

The conditional is chosen carefully to check for the existence of a parameter rather than for a particular value of the parameter. We could do (Action_Param('inputname') != '') but that would not let the user reset an input to empty. If we use a conditional which checks for a non-empty value then inputs may tend to stick to a value once it has been defined.

Valid Values

Now each of the input variables of our page have a proper value, but we want to make sure that we only pass valid values on to the inline later on the page.

We can't do much to check the value of the $search_first_name and $search_last_name fields since their value is determined by the user. At worst if the user specified a bad value they will get no search results.

We can ensure that the $search_maxrecords variable is either set to 'all' or set to an integer within a valid range and that $search_skiprecords is set to a non-negative integer value. The following code does this using the [Math_Range] and [Math_Max] tags.

<?LassoScript
 
  // Validate Inputs
  If($search_maxrecords != 'all');
    $search_maxrecords = Math_Range(Integer($search_maxrecords), 10, 100);
  /If;
  $search_skiprecords = Math_Max(Integer($search_skiprecords), 0);

?>

 

Put It All Together

Below we see all the code for our page inputs put together. This code is certainly more verbose than simply using [Action_Param] tags within the inline, but we have gained a lot of functionality. Each input is clearly labeled and easy to find. The inputs have default values. One input is fetched from a session automatically, but can be overridden by a URL or form parameter. The inputs are checked for validity automatically.

!Insert Lassoscript here

  // Input Variables
  var('search_first_name') = '';
  var('search_last_name') = '';
  var('search_maxrecords') = 'all';
  var('search_skiprecords') = 0;

  // Start Session
  Session_Start(-name='mysite', -expires=1440, -usecookie);
  Session_AddVar(-name='mysite', 'search_maxrecords');

  // Page Inputs
  (Action_Param('first', -Count) > 0) ?
    $search_first_name = Action_Param('first');
  (Action_Param('last', -Count) > 0) ?
    $search_last_name = Action_Param('last');
  (Action_Param('max', -Count) > 0) ?
    $search_maxrecords = Action_Param('max');
  (Action_Param('skip', -Count) > 0) ?
    $search_skiprecords = Action_Param('skip');
 
  // Validate Inputs
  If($search_maxrecords != 'all');
    $search_maxrecords = Math_Range(Integer($search_maxrecords), 10, 100);
  /If;
  $search_skiprecords = Math_Max(Integer($search_skiprecords), 0);

  // Perform Search
  inline(-search, -database='mycompany', -table='people',
      'first_name'=$search_first_name,
      'last_name'=$search_last_name,
      -maxrecords=$search_maxrecords,
      -skiprecords=$search_skiprecords,
      -inlinename='people_search');
  /inline;

?>

 

If we want to add a fifth input to this page we can work our way through each of the sections adding the input to each. Doing so helps us to ensure that we consider each aspect of the new input. Does the new input have a default value? Should the input be stored in the session? Can the input be overriden by a URL or form parameter? Does the input require validation? Once we've asked all these questions we can be sure that our new input is handled with the same level of robustness as our existing inputs.

Author: Fletcher Sandbeck
Created: 16 May 2008
Last Modified: 2 Mar 2011