Thoughts on Kevin's announcement

[Jim Ault]

On May 12, 2010, at 6:03 AM, Richard Gaskin wrote:
>
> RevServer, and even the existing Rev CGI engine, are great solutions  
> on the back end.
> But what goes in the browser?
> It's still HTML, and for interactivity it means learning JavaScript.
> That said, JavaScript is fun language, and as the only language  
> natively handled in every browser it's well worth learning.

An essential element to using browsers successfully is very good power  
scripting for accurate browser detection.  The best resource online  
that I have found is QuirksMode.org to modify the HTML for the best  
result in the various browsers.

Also high on the list to study is the Adobe Flash detection scripts  
that show the array of detection logic paths required for a developer  
to deliver the best possible user experience in a browser.  Of course,  
you would not use Flash, but their detection algorithms are very  
complete.

The Rev community incarnation would be a library of routines that  
could be built by collaboration and updated as new versions of  
browsers hit the market.

There are huge advantages to using your RevServer account to host the  
functions you would require for your 'apps'.  One advantage is that  
variations in javascript between browser versions would have far less  
effect.  In this case you could use basic javascript code to trigger  
functions (eg. formatText.irev, parseArray.irev, errorCheckForm.irev)  
based on user interactions.  Now you need not learn everything about  
javascript and do the tricky stuff in irev/rev stacks/cgi

Some on the list may not realize that you can build a stack of many  
cards, then launch it on the RevServer using Rev cgi/irev so that its  
stack script is available momentarily.  Just add the stack to the cgi  
environment, build the scripts, launch it without using any User  
Interface (UI) objects, then access the fields, navigate the cards  
just as you would on your desktop.  After the cgi call is completed,  
the stack disappears from memory, but the idea is that its stack  
script functions returned a result that is sent back to the users  
browser to be displayed.

Theoretically, you could have one Rev stack for each web page you  
would own or support.  Or you could have a Rev stack containing all of  
the browser detection scripts, and this stack would be called/used for  
each ping from the web page.  The result is highly accurate HTML for  
each browser.

By sharing this development, those who know javascript could show how  
to build simple 'hooks' so that most of the heavy lifting would be in  
RevTalk

Of course, if you wanted to use zero javascript, your web solutions  
would be less powerful and more difficult to create.

Hope this helps.

Jim Ault
Las Vegas