(Classic) Event Network Exercises: Data Storage Module

Objective

Learn how to create a data storage module. 

Data storage modules combine modules with explicite events to allow a personal event network to store data that can be shared between rulesets. 

Setup

• Complete the Foursquare Checkin exercise

Exercise

1. Create, register, and install a ruleset named location_data
   
   1. Add a rule called add_location_item that listens for a pds:new_location_data event. The attributes to this event will be key and value. 
   2. When the add_location_item rule fires, it should store the data in the value attribute in an map entity variable using the value of the key attribute as the key for the map. 
   3. Add a function called get_location_data() that takes a key as it's sole argument and returns the value of that key in the entity variable you created above. 
   4. Make sure the get_location_data() function is listed in the provides pragma in the meta section of the ruleset. 
2. Modify the process_fs_checkin rule from the Foursquare Checkin exercise to raise a pds:new_location_data event the key attribute should be fs_checkin and the value attribute should be a map with the venue, city, shout, and createdAt event attributes. 
3. Create and activate (register and install) a ruleset named examine_location:
   1. The ruleset should use the location_data ruleset as a module. 
   2. Add a rule show_fs_location that shows the last Foursquare checkin in SquareTag. 
   3. This ruleset could simply show a notify box on ktest.heroku.com or run as an app in Squaretag.com

You've built a system of three rulesets that use explicit events and modules that looks something like this:

Notes

1. Both the Foursquare and Location Data rulesets will have to be installed in your Squaretag account (i.e. your pico) to see events from each other. Obviously the Inspector ruleset will need to be installed if you run it as a Squaretag app. 
2. Persistent variables are specific to a ruleset. Put another way, rulesets form closures over their persistent variables and only their rules and functions have access to them. That's why you're building the Location Data ruleset. Think of persistent variables like private variables in an object. 
3. Be careful how you store and access the data inside the Location Data ruleset. If you're not sure things are wired up correcting, you can test the module function by having it return something static (i.e. a string) and ensuring you see it in the Inspector. 

Demonstrating Your Code Works

To demonstrate your code works (say for grading purposes), please add a send_directive() action to the rules add_location_item and process_fs_checkin as follows:

1. The directive name (i.e. the argument to send_directive()) should be venue name for process_fs_checkinThe options for process_fs_checkin should include an item with key equal to "checkin" with a value equal to the name of the venue. 
2. The directive name should be the value of event:attr("key") for add_location_item.  The options for add_location_item should include an item with key equal to "location" with a value equal to event:attr("value").