For a reason I can't quite work out, I woke up this morning wondering how to get state information into Grazr. What is state, you may ask? Think of it as the set of configuration data or information contained within a computer program, or web page. What is state good for? Configuring web forms, for one...
When you load a web page, the page itself is generally stateless. That is to say, the web page itself knows nothing about you. It is generic, although it may be customisable.
How then, do sites like Amazon always manage to know who you are, and serve you a customised page that identifies you explicitly?
One way is to use a cookie (read about cookies on Openlearn). Cookies are little data records that are stored on your computer by a website. When you first visit a website and enter your personal details, the website collects this information, creates a unique identifier for you and stores that identifier in a cookie on your computer. When you revisit the webpage, it looks for the cookie, sees who you are, and customises the page as a result. Cookies could store your personal details explicitly on your computer rather than a unique identifier, but this is usually a bad idea, for privacy reasons if nothing else.
To make things concrete in the Grazr world, consider the deliRolls script that lets you view feeds corresponding to bookmarks tagged in a particular way by particular delicious users.
The form has two customisable inputs - one or more delicious usernames, and one or more tags. As it stands, there is no way I can preconfigure this particular widget (as it stands, and as far as I know...) so that it displays the feeds I was looking at previously each time I reload the page containing the widget.
A cookie would let me do this. A cookie could be used to save the delicious usernames and tags each time I change them, so that the next time I visit the page I see the widget configured as it was the last time I used it with the same browser.
Cookies are set in a browser using Javascript. However, whilst Grazr does support Javascript, the Javascript runs on the Grazr server to build the rendered OPML file, not in your browser. The Grazr widget itself is built using Javascript, but this is not accessible to the user.
So cookies can't be used at the moment to load state data into a Grazr widget (one for the wishlist, maybe? Some cookie handlers?).
Another way of getting state information - such as the delicious username(s) and tag(s) required by the deliRolls widget - is via the URI. This approach is taken by the Yahoo Pipes team: each interface/input element in a Yahoo pipe is exposed as an argument in the URI.
The same approach can easily be achieved in Grazr if it is possible to associate arguments with a GrazrScript URL.
For example, the deliRolls script lives at http://grazr.com/data/psychemedia/deliRolls.opml; the script contains two arguments, corresponding to the input fields: deliName and deliTag. If these could be set via the OPML URL, it would be possible to load a preconfigured deliRolls widget.
For example, loading the Grazr widget with http://grazr.com/data/psychemedia/deliRolls.opml?deliName=psychemedia&deliTag=grazr%20opml should load the form with two feeds from my delicious account: one with items that are tagged "grazr", the other with items that are tagged "opml".
By supporting the passing of arguments "into" GrazrScript OPML files in this way, it would also be possible to write Grazr wrappers that could set and read cookies, and then load in an appropriately configured GrazrScript file without the Grazr widget having to offer cookie support.
The stop gap is to write a GrazrScript generator that does accept URLs and that generates a customised OPML file that gets loaded into the Grazr widget (which is the approach taken for the generators listed in the GrazrScript Generator Studio) but it would be far more elegant if Grazr could handle this directly.
So here's my feature request:
- for every form variable in a GrazrScript file, expose it/handle it as a URL (HTTP GET) argument to the GrazrScript/OPML file.
I guess it would also be handy to be able to run an onload function, too, e.g. to simulate the form submit action so that the arguments passed into the form can be used automatically as a form submit action to preload the Grazr form result node.
PS here's another request too; it's possible to pass the name of a frame you want Grazr links to open in via the linktarget= argument. What would also be handy would be the ability to pass the URL you want to open into a callout function in the browser; for example, in the Stringle environment, I'd like to be able to call a function that ensures the correct tab has the focus when a page is loaded from Grazr.
Without thinking too deeply about it, what I'd like to be able to say is callOut=foo and then, whenever I click on a link in the Grazr widget, call foo(url) in the parent window, where url is the URL I clicked on in the Grazr widget.
PPS hmm, is it possible to run a GrazrScript serverside javascript function from a Grazr link, I wonder? That is, when a link is clicked, call a GSJS function?
PPS hmm, too - (after a msg from Mike) - I wonder if a GSJS onload callback/callout would be useful; that is, the ability to call a parent window Javascript function once the Grazr form has loaded.
Mike also mentioned a hack that lets you display just the results of running a script in Grazr that I'll have a tinker with over the next few days...