edoism

KRL Safari: KRUD Redux - Kynetx CRUD with Persistent Variables

2011-10-10T16:29:00.001-06:00

Recent updates to the Kynetx platform related to Hash expressions has given me the opportunity to revisit my previous post. If your WebApp has modest requirements for storage of data it is worthwhile considering the use of Persistent Variables. To demonstrate the salient principles of using persistent variables as a datastore, a simple Kynetx WebApp addressbook is provided.

View Demo Online Download Source Code

The addressbook application stores the name, email and phone number of each person. The addressbook data is stored in a single persistant variable as key/value pairs. With the persons name used as the key:

"SomeName" : {
    "Name"  : "SomeName",
    "Email" : "SomeEmail",
    "Phone" : "SomePhone"
}

Since there is a lot of to wade through, so let me point out that parts specifically related to reading, writing and remove entries in the addressbook. In order to read all of the entries in the addressbook the following ruleset is used:

foreach ent:KRUDaddresss.keys() setting (addressKey)
pre {
  email = ent:KRUDaddresss{[addressKey, "Email"]};
  phone = ent:KRUDaddresss{[addressKey, "Phone"]};
  addressRow = &lt;&lt;
      
          #{addressKey}
          #{email}
          #{phone}
          Remove
      
  >>;
}
{
  append('#panelAddressList .DataTable tbody', addressRow);
}

New entries for the addressbook are entered via a standard HTML form. With a watch() placed on the submit the following rule captures the entry from the form, builds a new entry and adds it to the persistent variable:

select when submit "#formAddressAdd"
pre {
  formName  = event:param("formName");
  formEmail = event:param("formEmail");
  formPhone = event:param("formPhone");
  formHash = {
      "Name"  : formName,
      "Email" : formEmail,
      "Phone" : formPhone
  };

  KRUDaddresss = ent:KRUDaddresss || {};
}
{ noop(); }
fired {
  set ent:KRUDaddresss{[formName]} formHash;
}

Entries are removed from the addressbook by calling the following rule with an entries name as the event parameter:

pre {
  keyName = event:param("keyName");
}
{ noop(); }
fired {
  clear ent:KRUDaddresss{keyName};
}

You can play with the online demo to see the end results. And you can get the source code for the whole WebApp on GitHub. Heads up, there's a lot of code in the WebApp related to the GUI, that's why I wanted to call out the salient CRUD elements above. Enjoy!

11 Oct 2011: Revised code for adding new addressbook entries to use the new expression syntax for Persistent Hashes. When these new expressions are used you avoid loading, binding and transferring the entire hash.

View Demo Online Download Source Code

KRL Safari: KRUD - Kynetx CRUD with Persistant Variables

2011-02-04T10:25:00.000-07:00

Got KRUD? In this KRL safari we will be using persistance variables as a database. While most web developers have written code to access a database, most Kynetx applications retrieve their data via RESTful web services. But there are times when a persistant data store is needed. Building a one off web service to host the data is certainly an option, but if the storage needs are moderate you can simply use a persistant variable. After all 2 million bytes of data can be stored in a persistant variable!

To keep the focus on the mechanics a simple data structure is used to demonstrate KRL CRUD ... an array of strings which will be used to implement a tag cloud. The demo provides a web interface to see all of the strings in the tag cloud, add new tags and delete tags. To permit the demo to be accessible to a broad audience, it has been distributed using a site tag. Just visit the demo page to see all of the current tags which have been entered by all who have used the application. You can add a new tag by entering text into the form, then click the Add button. To delete a existing tag simply click on the text of the tag.

While the KRL code has comments thoughout, it should be emphasized that application persistent variables accessed in the rule prelude:

TagCloud = app:TagCloud;

And the updated persistent variable are saved in the postlude:

set app:TagCloud TagCloud;

Adding a new value to the persistent variable is performed using the union operator:

newCloud = TagCloud.union(cleanTag);

Removing a value from the persistent variable is done using the difference operator:

newCloud = TagCloud.difference(tagText);

To see the implementation using a complex data structure take a look at Kynetx App A Day 28 Updating User's List When User Joins App.

Hey! Where's the U in KRUD? Multiple choice response:

Left as an exercise for the reader
Updated was not needed for demo
I'm lazy :)

Enjoy!

KRL Scope Safari: Application Variables

2010-12-22T10:15:00.000-07:00

The safari continues with a tour of persistent application variables. This is the second article in the series to chronicle the investigation of scope and extent of persistent variables in the Kynetx KRL platform. In the first KRL Scope Safari we explored persistent Entity Variables. Application variables in KRL are used to record persistent data within a ruleset. The value of an application variable is retained between execution of the ruleset. So far application variables seem to be the same as entity variables. The difference is that application variables are shared across all sessions of the ruleset. They are not restrained to a single browser session. A truly global application variable!

Note: For another perspective on KRL persistent variables I would highly recommend the Kynetx App A Day article Day 12 - Persistent Variables by Michael Grace.

We need some KRL code for this safari! Starting with the KRL from the last safari we replace all occurrences of ent:safari_entity with app:safari_app. There are three rules in the demo application. The first rule, Safari_Initialize displays a growl notification which includes a title, the current value of the application variable and two html forms which permit the application variable to mutated and cleared. The second rule, Safari_Respond_Submit processes the form submission to mutate (change) the application variable. The last rule, Safari_Respond_Clear processes the form submission to clear the application variable.

The value of the application variable can be accessed inside prelude expressions. In the prelude section of Safari_Initalize the value of safari_app is accessed. Application variables are mutated in the postlude section of a rule. In the postlude section of Safari_Respond_Submit the value of the application variable safari_app is set to the value of newValue. And in the postlude section of Safari_Respond_Clear the application variable safari_app is cleared.

It's demo time! You can follow along with the demo by running the application in two separate browsers at http://kynetx.aculis.net/safari/app.html The screen shots below are taking from Mozilla Firefox and Google Chrome. Starting in Firefox, the very first time the Kynetx ruleset is run the application variable does not exist, so it's value is set to "Just Born!". Note: Your mileage may vary since the application variable will retain it's value from the last user.

The value of the application variable can be changed by entering a new value into the text field.

After the Mutate button is clicked the current value of the application variable is set.

Switching over to the Google Chrome browser, when the Kynetx ruleset fires the value of the application variable is the same as it was in Firefox. This is our proof that the application variable is accessible to all running sessions of the ruleset.

Still in Chrome a new value is entered into the text field.

After clicking the Mutate button the current value is updated.

Back to the Firefox browser, the page is reloaded and we can see that updated value of the application variable is the same as it was in Chrome.

Clicking the Clear button will destory the application variable.

Finally we reload the page in Chrome after it has been cleared.

In the next KRL Scope Safari we will add Modules to the adventure! Will we be able to share an persistent application variable between to different rulesets by using the same module? Stay Tuned!

Enjoy!

KRL Scope Safari: Entity Variables

2010-12-21T12:12:00.000-07:00

This KRL Safari will investigate the scope and extent of persistent variables on the Kynetx KRL platform. We begin the expedition with the most familiar type of persistent variable, the Entity variable. Entity variables in KRL are used to record persistent data within a ruleset. The value of an entity variable is retained between executions of the ruleset. It is important to note that the scope of an entity variable is directly associated with your browser session.

Note: For another perspective on KRL persistent variables I would highly recommend the Kynetx App A Day article Day 12 - Persistent Variables by Michael Grace.

Since the definitive authority is code, here is a KRL ruleset! There are three rules in this demo application. The first rule, Safari_Initialize displays a growl notification which includes a title, the current value of the entity variable and two html forms which enable the entity variable to mutated and cleared. The second rule, Safari_Respond_Submit processes the form submission to mutate (change) the entity variable. The last rule, Safari_Respond_Clear processes the form submission to clear the entity variable.

The value of the entity variable can be accessed inside of a prelude expression. In the prelude section of Safari_Initalize the value of safari_entity is accessed. Entity variables can be mutated in the postlude section of a rule. In the postlude section of Safari_Respond_Submit the value of the entity variable safari_entity is set to the value of newValue. And in the postlude section of Safari_Respond_Clear the entity variable safari_entity is cleared.

Now it's time to start the safari demo of persistent entity variables. You can follow along with the demo in another browser window by visiting http://kynetx.aculis.net/safari/entity.html. When this Kynetx ruleset is run for the first time the entity variable does not exist, and so it is set to the value "Just Born!".

The value of the entity variable can be changed by entering a new value into the text field.

After the Mutate button is clicked the current value of the entity variable is updated.

When the browser window is reload or a new window is opened the current value of the entity variable remains the same.

Clicking the Clear button will destory the entity variable.

Then when the browser window is reloaded, or a new window is opened, we are back at the beginning of this demo.

An extremely important point to note is that entity variables are tied to your browser session in much the same way as browser cookies. You can see this for yourself by running this demo in two separate browsers (e.g. Firefox & Chrome) or by running the demo on two separate computers. Simply running the demo in two separate Firefox windows on the same computer is not the same since the session is the same.

The Scope Safari continues next time when we look at the scope of Application persistent variables on the Kynetx platform.

Enjoy!