. cgi . irev. Dave Brooks University of Nebraska – Lincoln September 1, 2009. Unified Learning M odel. Since this probably is the most important work I’ve ever done, I needed to make my Web tools more versatile to support teaching of this model. Two kinds of early courses:
University of Nebraska – Lincoln
September 1, 2009
Since this probably is the most important work I’ve ever done, I needed to make my Web tools more versatile to support teaching of this model.
Two kinds of early courses:
Chemistry – much automatic assessment
Theory – much reading, writing, & discussion
In my first draft of this talk, I forgot to mention something very important. There’s a reason why people like me fool around with RunRev. It’s this:
All of the pages I showed were built using one RunRev stack!
The chemistry courses were developed in HyperCard, and used to run on an old System 9 server with WebStar. Used stacks to store data, and used appleEventsto exchange information with Web pages.
I was unable to migrate directly from HC to RunRev– because Apache does not use appleEventsand never got a tool that would move enough information using an appleEventsstrategy.
In January, 2004, heard talk by Jackie Landman Gay at a RunRevworkshop in SF. Went home to work on new backend.
Thought I had it until I came across a data transfer limit – that I never successfully worked around. Had one chemistry course “moved,” but could not move the other course format.
Moved everything to that.
It ran (and runs) successfully
I’m on a 24/10 retirement plan.
If I go into the office tomorrow (24 h) and decide that’s it, the desired books and wall memorabilia go into boxes (90 minutes), and the e-mail saying I won’t be back (30 seconds) is sent.
Since I’m 67, that day is coming in the next 10 years.
Keep in mind that I don’t make a living programming, and that I am in awe of the likes of
I’m much more like Looney, but, since I have tenure, I don’t have to make a living with my stuff (even though I sort of do that anyway).
Yes, I guess I could have moved my cgi stuff to the on-rev server and just used it as is, but what fun would that be?
Back to a RunRev Conference in Monterey. Jerry Daniels showed use of text files to store data, and I’ve been quite suspicious of databases. If you learned about databases when you were middle-aged and haven’t kept up, you ascribe many problems to them that were resolved long ago.
So, my cgi data is stored in text files. It’s not necessarily the best way, but it keeps me comfortable.
Around the same time that I decided to go to text files, I was sitting in on a computer science course in which the teacher advocated xml formats. Now, I never had much luck with my versions of RunRevand the xml functions, but I decided to use that approach in a way that could be adopted later. So, …
<?xml version='1.0' ?>
firstname.lastname@example.org,aaa,David W. Brooks
While that may be a Kosher xml file, I really couldn’t get those functions to work. So, I used my old tricks as follows:
<?xml version='1.0' ?>
email@example.com,aaa,David W. Brooks
The idea was this. If you strip out the first line, you have a real xml file. But, since the first line was designed to contain the names of every element, you could parse the file – element by element – and create a data array from the result.
You then can work with the data in this array, change the values according to the needed operations, and then rebuild the file by using theKeys for the first line and then rebuilding each file element.
It also was helpful to name the elements systematically:
Lxxxxxx (read in from an ordinary text field)
Fxxxxxx (read in from a text area field)
Axxxxxx (read in from a text area but with
strutured data in a fixed format)
Cxxxxxx (something calculated that really
shouldn’t be edited by just anyone)
Several years back I asked Jackie L-G to look over my scripts. She pointed out that I really didn’t need this xml stuff (unless the files are VERY large, xml files are easily readable).
She recommended using parsing characters that cannot be typed into a Web page – her choices being:
numtochar(3) & numtochar(8)
put url("file:"&recordPath) into BigData
split BigData by numtochar(3) and numtochar(8)
Create variable bigData from file in which what had been element names are separated from the data by numtochar(3) and what had been different elements were separated by numtochar(8)
on RebuildNewBigData, recordPath
combine BigData by numtochar(3) and numtochar(8)
put BigData into URL( "file:"&recordPath)
With the exception of a small number of files that have just one type of data in a structured format, that’s how I retrieve/store data.
The BIGGEST virtue of this approach is that I don’t have to know what kind of data I’ll have when I start – so long as I have a systematic way of naming data. In other words, I don’t have to know what the exact data structures will look like in advance. With xml, I had to know at first what the data looked like, so I had to have templates built in advance.
Today, if I add another question to the 7th week of school, I just do that.
No template modification.
No problem that the current data files don’t have an “element” for that.
Changing templates during a course because you wanted to add something was not unlike what I imagine one of Dante’s first five circles (the self-indulgent circles) to be like.
On the other hand, these text files with invisible characters are much less easy to read than were the xml files. For one thing, the systematics for sequencing the elements are obscure. My mental structure of an array turns into a hodge-podge sequence in the text file.
So, from my previous example:
$_POST[“AtheAdmins”] can be manipulated by moving it into a new variable.
Explain how convection could contribute to the controversial issue of how fast hot and cold water freezes.
irev handles the management of encoding/decoding very well. It needs a bit of help with some things, like “+” and “%”.
Returns work well in a textarea. They don’t count in html – so you need a function like this:
replace "%" with "%" in bbb
replace "+" with "+" in bbb
--put URLdecode(bbb) into bbb
put “<br />”&return into tag
replace return with tag in bbb
What the student sees.
What the teacher sees.
start timer (gDBstart)
store the current defaultFolder (path)
pull standardized Web values ($_POST)
load core functions
use switch, tTask
PROCESS (call other functions)
Whatever function is called, it creates the title that is written at the top of the file. It decides what a title should be and writes – including setting up the form and directing the action to either of TWO irev scripts.
parse.irev – handles students
ULMAdmin.irev – handles teachers
takes about 2 milliseconds to handle anything.
ULMAdmin – uses one large script and takes about 8 milliseconds to handle anything. Because teacher traffic is much lower traffic, this is fine.
Comparable cgi scripts running on a top Mac server take 10-15 times longer!
Although the top script is split out, the title comes from the function, so the file writing doesn’t start until one of the task-specialized functions opens.
The function that writes the top of the page always is called by another function.
The “guts” are provided by the individual functions. They determine the next task AND write (usually as hiddens) the data for the NEXT process. The user need not know this.
In the parse script, it is “put” out as it is built.
In the ULMAdmin script, it is stored in a global variable until complete and then written out at once. (This was done to facilitate debugging – as discussed later.)
The last thing to do before sending this newly constructed page out is to write a bottom.
writes the globals as hiddens
closes the form
calculates the time elapsed
writes access information
adds a Google Analytics tracker function
closes the body and the html
The page is then sent.
The on-rev tool helps find obvious mistakes, but it really doesn’t help enough.
Pull it into ScriptTester:
Run the test script; copy result, paste into ScriptTester, load globals into ScriptTester
Since $_POST is not available, do a replace of $_POST with bigData– which now is global variable loaded with the data that would have come in from the Web form.
Goal – keep the switch and the function to be tested in one button, and put everything else into the card script. The button script accretes the forming page in a global variable (gDBtheHTML). In irev, this is sent to the Web with a put statement. In debugging, it is written to a file that can be examined at the desktop.
SO: run with debugging, fix (iteratively), take “repaired function”, replace bigDatawith $_POST, paste back into original script, save as text file, and upload overwriting original script.
This is a supreme pain in the butt – and I wish someone who knows what s/he is doing will build a debugger for these scripts
They can represent a really stupid coding decision or really bad code.
BUT, whatever the problem, you don’t get much help. MOST of the simple problems were detected by the on-rev tool.
If you were to look at my scripts, you would see commented out MANY cases where I was reporting the value of a variable at a particular point in time.
Well, I’m happy. It took about 13 days to make this happen. I wish I’d trashed the xml right away. I still can make some changes based on better understanding of what-does-what in irev. I wish I’d mucked with a debugging stack earlier, since that might have saved time. It’s so clunky that it didn’t help save as much time as it cost to build – but building it was fun!
HyperCard was both forgiving and easy to debug.
BTW, my university offers at-a-distance doctoral programs in education, so anyone interested in receiving a degree from a bona fide AAU member, feel free to ask.