Revlet as backend tool

Richard Gaskin ambassador at
Tue Apr 13 11:13:08 EDT 2010

Terry Vogelaar wrote:

 > I have been asked to make a HTML-version of a Flash-based site,
 > because not all internet browsing devices have Flash. The site
 > is not hosted on On-Rev, so I cannot use an .irev file.

Not a problem, since .irev and Flash work on opposite ends of the 
system:  .irev is a PHP-like variant of CGI on the server, whereas the 
Flash plugin provides a user interface in the browser.

 > The CMS is Flashblocks; a Flash-based commercial CMS that writes
 > all data to an XML-file. So the task of parsing the data and write
 > it to a bunch of HTML-files should be fairly simple.
 > So I want to write a revlet with a simple user interface.

I suspect that any browser not running the Flash plugin will probably 
not have the RevWeb plugin available for the same reasons, whatever they 
may be.  I suppose there may be a few isolated exceptions, but since 
Flash is pre-installed and RevWeb will need to be installed by each 
user, it's very rare to find a browser that won't run Flash but be 
amenable to running another proprietary plugin.

Michael Kann's suggestion (and thank you for the very kind words, 
Michael, even if they gave more credit than is warranted <g>) of 
considering a standalone may be as good an option as a RevLet:  both 
require the user to approve the download and both take about as long to 
download.  Any place that will run a proprietary plugin they don't 
already have is about as likely to run a "custom browser" (standalone).

But if neither of those are viable for your project, this leaves your UI 
options limited to JavaScript, the only language built into every browser.

Dealing with the semi-OOPness and the differences between "=" and "==" 
may seem daunting at first, but the more I learn about JavaScript the 
more I like it.

I've been reading O'Reilly's "Head First: Data Analysis", and have 
become a fan of the series.  While some aspects of that series may seem 
a bit too fun-oriented for serious programming types, I see no harm in 
being entertained while I learn, and am looking forward to others in the 

They have one for JavaScript as well:

Looking at the table of contents, it seems there's a chapter on AJAX 
methods which should provide the background you'll need for using the 
XMLHttpRequest object to obtain your XML data from the server.

Sure, JavaScript is a learning curve, but given its ubiquity there's 
probably no other second language as valuable to learn.  Besides, it's 
good for the mind to keep exercising the learning muscle. :)

Of course this assumes that the client-side UI needs to by dynamic, that 
elements on the page will be changing in response to user actions.  Such 
things will require JavaScript, Java, Flash, RevWeb, or another plugin.

But if it turns out that all you need are static HTML pages generated 
from XML, you should be able to use Rev's CGI for this and have a great 
time doing it.

The Rev engine makes it easy to read files, parse XML, and using the 
merge function you can easily put function results into any HTML template.

For example, suppose you have this in a template named "MyTemplate.htm":

Today is [[the date]]

The CGI that uses it is simple:

#!rev -ui

on startup
   put url ("file:MyTemplate.htm") into tData
   put merge(tData) into tOutput
   put "Content-length:" && len(tOutput) &cr&cr
   put tOutput
end startup

If you want to use one of your library stacks with that, if you had a 
library function called "GetXMLtoHTML" in a stack called "myLib.rev" the 
template can look like this:

Look at this cool data: [[GetXMLtoHTML()]]

...and your CGI looks like:

#!rev -ui

on startup
   start using "MyLib.rev"
   put url ("file:MyTemplate.htm") into tData
   put merge(tData) into tOutput
   put "Content-length:" && len(tOutput) &cr&cr
   put tOutput &cr&cr
end startup

For getting started with CGIs I know of no better reference guide than 


  Richard Gaskin
  Fourth World
  Rev training and consulting:
  Webzine for Rev developers:
  revJournal blog:

More information about the Use-livecode mailing list