Today I released build 299 of KNS. There are three important updates to KRL in this build.

First, KRL now support literal hashes. Hashes are creating by enclosing comma-delimted name-value pairs in curly braces like so:

{"foo" : "bar", "fizz" : 3, "flop" : [1, 2, 3]}

Second, the annotate_search_results action has been modified to support two new configuration parameters:

• results_lister - (defaults to "li.g, div.g, li div.res, #results>ul>li") - jQuery selector for finding relevant results to annotate. The default finds search results for Google, Yahoo, and Bing.
• element_to_modify - (defaults to "div.s,div.abstr,p") - the jQuery selector for finding the element to modify within the results returned by the result lister. The default finds the main body of a search result..

These parameters give you the ability to find and annotate other items on almost any page that displays results. For example, the following action will annotate the paid search results in Google given an appropriately defined my_selector function.

annotate_search_results(my_selector)
 with results_lister = "#mbEnd li" and
      element_to_modify = "a#an1";

Third, user-defined datasources are now more flexible. Previously, the arguments to the datasource function were assumed to be name-value pairs presented as strings. The function put them together to create a QUERY string. That wasn't as flexible as needed for path-based APIs. So now the datasource takes a single parameter of either a string or a hash:

• If the parameter is a string, then it is concatenated with the URL root given in the datasource declaration without modification. What you supply here, when appended to the datasource root URL must result in exactly the URL that you intend to call.
• If the parameter is a hash, then the has is turned into a properly formatted HTTP QUERY string with names 7 values delimited by an equals sign (=) to create a name-value pair and each name-value pair delimited by an ampersand (&):

  pre {
    tweets = datasource:twitter_search({"q": query});
  }
  

This allows path-based API calls to be created as strings and QUERY string calls to be created by either creating the string or putting the name-value pairs in a hash and letting the function create the query string.