Download
1 / 74
740 likes | 907 Vues
. 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:
E N D
.cgi .irev Dave Brooks University of Nebraska – Lincoln September 1, 2009
Unified Learning Model 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.
Switched to a straight Rev cgi. Moved everything to that. It ran (and runs) successfully
Reason to change now: • Impetus of ULM (new work) • Server protection from the vagaries of retirement • Academic excuse to travel to Scotland
A Digression on Retirement Plans 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.
I bought on-rev space as soon as it was available (like April, 09). • As I started to mess with irev, I realized how much fun it was.Further, since much of what I had been doing was: • reading in Web form data, • deciding what to do with it, and • composing an html response • irev was a natural for me.
Keep in mind that I don’t make a living programming, and that I am in awe of the likes of Daniels Garzia Gaskin Wieder …. 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. un-paid plug 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, …
My files looked like this. <?xml version='1.0' ?> <Administrators> <AtheAdmins> dbrooks1@unl.edu,aaa,David W. Brooks simth2@unl.edu,bbb,Roger Smith </AtheAdmins> <CtheEditDate> 01/02/09 </CtheEditDate> </Administrators>
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:
AtheAdminsCtheEditDate <?xml version='1.0' ?> <Administrators> <AtheAdmins> dbrooks1@unl.edu,aaa,David W. Brooks simth2@unl.edu,bbb,Roger Smith </AtheAdmins> <CtheEditDate> 01/02/09 </CtheEditDate> </Administrators>
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 would end up with an array: Administrators[“AtheAdmin”] Administrators[“CeditDate”] Administrators[“theKeys”] 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.
Systematic naming 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)
File to Array: function ExtractNewrecordPath put url("file:"&recordPath) into BigData split BigData by numtochar(3) and numtochar(8) return BigData end ExtractNew 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)
Array to file, reverse the process: on RebuildNewBigData, recordPath combine BigData by numtochar(3) and numtochar(8) put BigData into URL( "file:"&recordPath) end RebuildNew
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.
A VERY nice feature in on-rev is that Web data goes into a global array, $_POST. So, from my previous example: $_POST[“AtheAdmins”] can be manipulated by moving it into a new variable.
Also, Web data is streamed in a different format than you might expect: Explain+how+convection+could+contribute+to+the+controversial+issue+of+how+fast+hot+and+cold+water+freezes. 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: function BRdecodebbb replace "%" with "%" in bbb replace "+" with "+" in bbb --put URLdecode(bbb) into bbb put “<br />”&return into tag replace return with tag in bbb return bbb end BRdecode
Remember, I need TWO different systems. What the student sees. What the teacher sees.
tTask= function to which data is directed tTaskis written as a hidden; it might be changed in the browser using javascript. Sometimes it is set to “none” and all of the choices end up resulting from javascripting. IF the task is determined by javascripting, then that scripting must somehow either be in or be created by the function that is creating the page.
FLOW of processing: start timer (gDBstart) store the current defaultFolder (path) designate globals pull standardized Web values ($_POST) load core functions use switch, tTask PROCESS (call other functions) build bottom
