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
javascript on the client side. We can map that to stack script and make
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 be used by the client side which is CSS+HTML+Javascript+A Human.
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
javascript + DOM manipulation it would insert the answer in the text
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
+ Javascript + CGI. This tool would pick the stack script and pack it as
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
needed. It would convert the control scripts to javascript and relay
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:
Code:
on mouseup
put field "amount" into tAmount
put field "currency type" into tCurrencyType
put convertCurrency(tAmount, tCurrencyType) into field "result"
end mouseup
web-thing conversion
The button would be something like this
Code:
<input type="button" onmouseup="javascript:buttonMouseup()" />
meaning the html button has a javascript methond connected to it's
mouseup event. then we have a almost line by line conversion.
Code:
buttonMouseUp() {
var tAmount = document.getElementById("amount");
var tCurrencyType = document.getElementById("currency type");
document.getElementById("amount").innerHTML = RPCCall("convertCurrency",
tAmount, tCurrencyType);
}
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
objects.
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.
Andre
_________________
Technology shall set ya free!
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
