LEAP 5 Documentation

The LEAP™ 5 LEAP_manageFeatures system

LEAP™ 5 has a flexible data map that is specific to the content plugin instance. Using LEAP_manageFeatures is appropriate for configuration data and low-volume content data, but not for larger volume text objects.

When larger volumes of data are to be stored, use LEAP_MasterContent.

NOTE: Detailed specification of LEAP_manageFeatures is located here.

Usage: Set up and initialize

var(Feature_Map = map)
LEAP_manageFeatures->populate
local(featurelist = map(
		'aVar'		= 'yes',
		'bVar'		= 'I am Variable B',
	)
)
with i in #featurelist->keys do => {
	$Feature_Map->find(#i)->isA('void') ? 
		LEAP_manageFeatures->update(#i,#featurelist->find(#i)) 
}

Line 1: It is important to re-initialize the Feature_Map variable so features from other plugins do not interfere with your plugin instance.

Line 2: LEAP_manageFeatures->populate - this loads any existing data stored for this content instance.

Lines 3-7: The keys of this map are the features, and the associated values in the pairs are the default values. Note the default storage format for LEAP_manageFeatures is a string. If the value is an integer, it should be stored as a string and evaluated as an integer during usage.

Lines 8-11: This is the initial setup and initialization of the data for this plugin instance. It will populate the stored map with the default data as defined.

Usage: Saving Data on Edit Submit

if($actionis == 'save' && $gv_admin) => {
	if($ContentID > 0) => {
		with i in #featurelist->keys do => { 
			LEAP_manageFeatures->update(#i,string(client_param('LEAP_'+#i))->trim &) 
		}
		LEAP_manageFeatures->populate
	}
	$gv_admin = false
}

This is an example "save" function that only deals with config data stored for the plugin, and not for any substantial data which would normally be stored in Master_Content or a specialized table.

Line 1: The default action on save from the Plugin Edit mode. The variable $actionis is described in detail in a separate section. Note we are also checking for $gv_admin == true as this is verified by the LEAP_Admin "kernel" through which all Edit Mode communication passes.

Line 2: Checking $ContentID > 0. This is an extra verification step to ensure the module has been created and no bypass has been effected. See additional documentation for how to create and clone content.

Lines 3-5: This is a query expression to iterate through the list of features and cause an update. Note the usage of "client_param" - this is a base method that is a drop-in replacement for action_param and is "inline safe" in that it can be used within nested inline containers.

Line 6: LEAP_manageFeatures->populate is invoked again to force-reload all content to ensure the latest data is indeed available.

Line 8: $gv_admin is set to false to prompt the display mode to activate

Using the Features in your Edit and Display Modes

Accessing the stored data is as simple as invoking a find of the feature name on the Feature_Map variable.

To use this in a display context, lets look at the "helloworld" example plugin:

'Hello world, today\'s date is: ' + date
'<br />aVar is currently: ' + $Feature_Map->find('aVar')

Using it in an Edit Mode context:

<input 
	size="12" type="text" 
	name="LEAP_aVar" 
	class="LEAP_mod[$ContentID]" 
	id="LEAP_aVar[$ContentID]" 
	value="[string($Feature_Map->find('aVar'))]" 
/>

Note, on line 3 the variable name is prefixed by "LEAP_". This is to assist in verification that data submitted to the LEAP_Admin kernel is meant for this purpose.

Line 4 contains a class reference to LEAP_mod[$ContentID]. This is further detailed elsewhere in the API spec.

Line 5 demonstrates a unique ID, a combination of the name as seen in line 3, and the $ContentID. This assists in access by javascript validation or other processes you may wish to include.

Line 6: the reference to the data.

An input with this format will be automatically picked up and fed back to the admin system to save for use in Display Mode logic.