Revolution and the Web, feedback wanted, Part 3 of 3
ambassador at fourthworld.com
Mon Nov 27 23:40:18 CST 2006
From Andre, cont.:
Web applications usually have a server side component that that deals
with core business logic that is not possible to be dealt by using
the stack script a cgi/fastgi whatever. If we write a nice RPC system we
can make the stack script hold the server logic and export it as methods
To illustrate my ideas, imagine a simple money conversion. In the web it
would be two fields and two popups and one button. the two fields would
hold the amounts, the two popups the currency types and the button would
convert from one to the other. The client side would use AJAX techniques
to make the life of the user easier, so simply clicking the button would
do a roundtrip to the server, convert the amount and then using
field. How would that map to Rev. The fields and the popups and the
button all have an equivalent on the Rev standard tool pallete, we would
need a new web-savvy inspector to accomodate the needs of positioning
and ids/class stuff for xhtml. The server component might just be the
convert function on the stack script. Okay we have our maps. How the
magic conversion occurs then? We need a new "web distribution builder"
tool that would scan and process a stack converting it all to HTML + CSS
a CGI and expose it's functions thru some RPC mechanism, it would
convert the card layout to a web page format using the web-savvy
properties created by our own web-savvy inspector to guide it when
each call to a method that is inside the stack script to a RPC call to
the server component, for this to be feasible the script on the controls
should be as small and direct as possible, maybe just variable bindings
and the call to the stack, nothing more would be allowed, let me
illustrate such control script conversion.
Transcript button example:
put field "amount" into tAmount
put field "currency type" into tCurrencyType
put convertCurrency(tAmount, tCurrencyType) into field "result"
The button would be something like this
mouseup event. then we have a almost line by line conversion.
var tAmount = document.getElementById("amount");
var tCurrencyType = document.getElementById("currency type");
document.getElementById("amount").innerHTML = RPCCall("convertCurrency",
See, if the conversion is just variable binding and method calls, it's
pretty straigth forward, just need to create some RPC mechanism, it
might be XML-RPC, SOAP, REST or something new. Let me make a resumé.
We need a new tools pallete that is able to drag and drop web-mapable
We need a new inspector that is able to deal with the features we expect
from a web object such as relative position.
We need a new distribution builder that is able to pick that stack and
convert it to HTML & Friends + CGI.
You will ask, but I still need to upload everything to test and that
spoils my pure xTalk development experience and I will answer: no you
need not. We have RevHTTP transcript based web server that can run
inside the IDE, a simple IDE plugin running the server will allow you
the standard xTalk experience, develop live on the IDE, switch to the
browser, load the page from inside RevHTTP that's live on the IDE, full
xTalk experience, no compilation needed.
Everything I said can be built now, it doesn't even need to be built by
the RunRev team, it all can be built in pure transcript just by adding
plugins to the IDE. It can be done now, all it needs is leadership and a
team of developers. Thats what I think that needs to be done. That's how
I envision developing for the web using Runtime Revolution, I don't know
if I was clear and I really want to talk about this thing to make
everyone understand what I am trying to talk about.
It's now 2:53 AM... I think this email to too big for the mailserver to
allow me thru. I'll try anyway.
Technology shall set ya free!
More information about the use-livecode