Stash: persisting form values and caching

gistfile1.txt

{!-- set context for this form to namespace our vars--}
{!-- @ refers to the current context --}
{exp:stash:context name="myform"}

{!-- register form variables from $_POST superglobal and save for 30 mins, scope to user's session --}
{exp:stash:get 
	name="filter"
	dynamic="yes" 
	type="snippet" 
	save="yes" 
	refresh="30" 
	output="no" 
	default="" 
	match="#^[a-zA-Z0-9_-]+$#"
	context="@"
}
{exp:stash:get 
	name="in" 
	dynamic="yes" 
	type="snippet" 
	save="yes" 
	refresh="30" 
	output="no" 
	default="" 
	match="#^[a-zA-Z0-9_-]+$#"
	context="@"
}

{!-- parse the enclosed tag and cache the html generated, but keep global {vars} intact so they remain dynamic --}
{exp:stash:set 
	name="form_options" 
 	parse="inward"
	parse_tags="yes" 
	parse_vars="no"
	save="yes" 
	scope="site" 
	replace="no"
}
	{exp:structure_entries parent="/services/global" depth="1" status="open"}
		<option value="{entry_id}"{if '{@:filter}' == 'expertise' && '{@:in}' == '{entry_id}'} selected="selected"{/if}>{title}</option>
	{/exp:structure_entries}
{/exp:stash:set}

{!-- this yields the following html that is then stored in the stash database table. If the template is viewed again the {structure_entries} tag is not run, instead the html below is retrieved from the database...  --}
			
<option value="7"{if '{@:filter}' == 'expertise' && '{@:in}' == '7'} selected="selected"{/if}>Aviation and aerospace</option>
			
<option value="8"{if '{@:filter}' == 'expertise' && '{@:in}' == '8'} selected="selected"{/if}>Business integrity and global compliance</option>
			
<option value="13"{if '{@:filter}' == 'expertise' && '{@:in}' == '13'} selected="selected"{/if}>Corporate and commercial</option>
			
<option value="354"{if '{@:filter}' == 'expertise' && '{@:in}' == '354'} selected="selected"{/if}>Dispute resolution</option>
			
<option value="355"{if '{@:filter}' == 'expertise' && '{@:in}' == '355'} selected="selected"{/if}>EC, competition and trade regulation</option>
			
<option value="356"{if '{@:filter}' == 'expertise' && '{@:in}' == '356'} selected="selected"{/if}>Employment and Immigration</option>
			
<option value="360"{if '{@:filter}' == 'expertise' && '{@:in}' == '360'} selected="selected"{/if}>Energy, trade and commodities</option>
			
<option value="9"{if '{@:filter}' == 'expertise' && '{@:in}' == '9'} selected="selected"{/if}>Insurance and reinsurance</option>
			
<option value="836"{if '{@:filter}' == 'expertise' && '{@:in}' == '836'} selected="selected"{/if}>Real estate and construction</option>
			
<option value="357"{if '{@:filter}' == 'expertise' && '{@:in}' == '357'} selected="selected"{/if}>Shipping</option>
			
<option value="358"{if '{@:filter}' == 'expertise' && '{@:in}' == '358'} selected="selected"{/if}>Transport and logistics</option>
			
		

Quite often you need the same variable names in different templates, or perhaps the same template. A typical example would be 'orderby' and 'sort' for passing to {exp:channel:entries} tag. If you register the variable from $_GET with Stash and just call it 'orderby' and save it, then wherever else you have used that variable will inherit the value of that variable. So you might have a table of entries in one template where the user has selected sort='asc', and when the user visits another template with a table using the same variable that table will also be sorted 'asc'.

Now you could just use multiple variable names, eg myform1_sort, myform2_sort - and that would work fine. However, if you have common elements to your table of entries - the header columns for example with links to change the sort direction, or the code that generates the rows of entries - then you need different code for each table you use.

Contexts allow you to use the reference '@' to point to the current context. Each variable is namespaced to the current context so it's value is independent and yet it can be referenced in the same way: @:sort or @:orderby. And that means that you can use one piece of code for generating all your tables. This makes your code DRY, and that that is a good thing.

Typically I would use {segment_1} etc to set the context, so the variable is namespaced to a uri.