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.