Download
1 / 34
340 likes | 429 Views
Runtime Revolution. A tool for rapid application development Presented by David W. Brooks dbrooks1@unl.edu Omaha ITC April 1, 2004. HyperCard. Developed by Apple in 1987, HyperCard was the first of a series of hypermedia applications.
E N D
Runtime Revolution A tool for rapid application development Presented by David W. Brooks dbrooks1@unl.edu Omaha ITC April 1, 2004
HyperCard Developed by Apple in 1987, HyperCard was the first of a series of hypermedia applications. ToolBook is the best known of the Windows hypermedia apps.
Dated HyperCard 2.4 runs under Mac OS (System 9.2) Neither HyperCard nor Mac OS are still supported. Although a new Mac will run HyperCard, it does so by starting the ‘Classic Environment’ as a single thread and runs one such thread at a time.
Objects Buttons (that bring about actions) Fields (that hold text, data) Cards Backgrounds Stacks (files)
Messages GUIs operate by sending messages. For example, when a mouse interacts with an object, there are several possible messages such as: mouseEnter, mouseWithin, mouseLeave mouseDown, mouseStillDown, mouseUp
Message Handler The ‘programming’ in these systems involves writing something that ‘handles’ or responds to the message For example, when a mouse button goes up, you might want the system to beep twice -- so the program or script would need to accomplish this task.
Sample Handler on mouseUp beep 2 -- pass mouseUp end mouseUp A script for an object consists of one or more handlers or functions.
Object Oriented Programming Several characteristics usually are associated with object oriented programming. One of these is hierarchy In a nutshell, messages can be passed up a message hierarchy seeking a handler. A message can be acted upon by a handler at one level, and then passed along for action by handlers further along in the stream
Revolution is object-oriented • Revolution has a variety of objects • It has messages • It has a hierarchy • Users can create objects • Users can group objects
Transcript The scripting language for Revolution is Transcript. This language is very much like HyperTalk, the scripting language for HyperCard. It has about 3 times as much “stuff.”
Bottomline You can build extremely powerful applications quickly using Revolution.
Web-Based cgis In 1994, after the release of Netscape, my group changed emphasis from desktop applications to Web applications. BUT, we used HyperCard as a back-end for our Web applications. We serve about 7 G/month from a bottom-of-the-line iMac. We have 70-80,000 ‘hits’ on a midweek school day.
Goal In 20-30 minutes, you can’t really demonstrate a complex piece of software. My approach will be to describe how our operations work. We have now just about completely finished the conversion of one ‘course’ back ends from HyperCard into Revolution.
Usual Approach Most programmers trying to do what we do use a scripting language (most often PHP) to take data in from a Web form, process it, and store it in a database (like MySQL). They generate responses based upon those scripts, the input, and the appropriate database components.
Parallel Revolution Approach One does the same thing in Revolution. The difference is that you use the Revolution scripting language, Transcript, instead of PHP.
Current: Mac OS with HC • WebStar 4.4 is the server software. • The action statement in the form is directed to HC. • WebStar generates an AppleEvent. HC detects this event (with a handler). • Information is passed to HC. • HC scripts parse the info and process, creating whatever responses are needed. • Responses go back to the sender through WebStar.
Proposed: OS X with RunRev • Apache is the server software. • The action statement in the form is directed to Runrev. • ACGI Dispatcher generates an AppleEvent. RunRev detects this event (with a handler). • Information is passed to RunRev. • RunRev scripts parse the info and process, creating whatever responses are needed. • Responses go back to the sender through Apache.
Why? • Why do this? It’s slower. • Doing it this way allows real (not virtual) copies of RunRev files to be opened so one can write to fields and save the data. In my world of operations, this makes planning, development, and debugging much faster than when using either external files or databases.
Also When dealing with a small amount of information, say records for 1000 students, the RunRev stacks easily can hold the data without other (external) files.
Work in Progress This is obviously a work in progress. However, the reason it is taking a while is that we are learning how to make better use of the strength of the RunRev built-in tools. For example, when ‘stuff’ comes in from the Net, it comes in as a string with all spaces replaced by ‘+’ signs and all special characters encoded. We used to have to decode this stuff; now we can mae use of a built in function -- URLDecode.
Timing Scripts need to be compiled -- and often are regarded as slow for that reason. Once a script has been used by RunRev, it is compiled and runs very fast. Most of the operations we have tested so far take 0 or 1 ticks (sixtieths of a second) from the time to start and stop of the script.
Projections We’re trying to garner support for a large trial of a learning strategy for high school chemistry. If we get this, we’ll serve all hs chemistry students in Lincoln, Omaha, Las Vegas (and Waverly). There are 12,000 students involved -- so we need some serious throughput.
Questions Trial copy from: http://www.runrev.com Various pricings. A serious license is $1K/y, but a really good stand-alone copy of the application is ~$150.
