Thanks for the info Jacque. It really explains a lot I didn't know.
-=>JB<=-
On Apr 17, 2009, at 6:21 PM, J. Landman Gay wrote:
Joe Lewis Wilkins wrote:
I have found this whole subject so far over my head that I'm
embarrassed. Can anyone sight some sort of reference that just
"might" get me off of my desktop. I am soooo uneducated on this
topic. Simply stated, what's this for, why is it needed and what
does it let us do that we can do now? There MUST be others who are
just as much in the dark.
It's kind of hard to explain if you don't create web pages or have
a familiarity with how they are written. But in a nutshell, web
pages written in pure HTML are static. Whenever you see a page that
does something dynamic -- buttons with different rollover states,
data that changes depending on live user input, dynamic content of
any type -- those actions must be scripted into the page using a
second, scripted language like JavaScript or PHP. The scripted
language is integrated into the same page as the HTML code and the
server interprets the scripts and shows you dynamic content.
Up until now, anyone who wanted dynamic content on a web page had
to learn one of those other languages. What has just happened is
that Runtime has figured out a way to allow a web server to work
with our familiar xtalk, and allow that to be embedded into a web
page instead of one of the other languages. This is big stuff.
The server needs to be set up in a particular way to allow this,
and as of now, only Runtime has that setup in place. They have made
their web service available so we can take advantage of this new
capability. Their setup pretty much matches industry standards in
terms of features and capability -- except for this remarkable
scripting feature which no one else has. There is nothing to lose
by changing to Runtime's web hosting service, and everything to
gain if you want to write web pages using the language we know and
love.
For years now, the Rev engine has always had the capability to work
with a server as long as it was set up as a CGI service. This is a
complicated and tedious task in general, but once it was set up it
works well. (This method isn't going away, by the way. It will
still be functional for those who want it.) However, with the new
HTML-integrated capabilities, CGIs are no longer needed. You can
write HTML and Rev script in the same web page and your users will
see content based on whatever your scripts do. You don't have to
worry about any of the complexities of CGIs because none of that
matters any more (permissions, engines, Apache installation,
missing libraries, line endings, etc. All moot now.)
Anyone who's had to work with the old-style CGIs will find the new
method liberating. One of the hardest things to do was debug a CGI;
it was very much like working with HC version 1.0 where the only
way to know what a variable contained was to put its contents into
the message box. If you got a script error, it was up to you to
figure out the problem, because the clues were sparse if they
existed at all. That's all over with now. RR provides a live
debugger that lets you step through the scripts on a web page just
as though you were working in a stack. That alone is worth the
price of admission for web page authors.
For me, I haven't seen such a cool thing since I was gobsmacked by
the ability to run a stack from a remote server in one line of script.
--
Jacqueline Landman Gay | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
_______________________________________________
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
