[FOSS] On the creation of Rev to Web tools

[Andre Garzia]

Folks,

This is me revealing me some secret ideas I had in the last few years. I
kept this somewhat secret for many years because I wanted to implement it
but I came to the realization that I don't have the time to do it alone and
that is the exact kind of project that benefits from a FOSS initiative.

The project is to build a suite of tools to run inside Revolution IDE to
allow conversion of Stacks into a web scaffold that can be further tailored
and tweeked for deployment as web apps.

as Jerry, Sarah and Mary demonstrated it is possible to process a stack and
convert it to some other format. David Simpson also has conversion tools
built that can convert php and basic back to Rev and even more. All this
done with small teams. What a big team such as our community could build?
(<-- rethorical question)

I remember talking with Mark Wieder and Richard Gaskin during a conference
in Monterey, I think I have found the pathway that would enable us some
quick conversion from Rev to the Web. The trick is not to try to convert a
common Rev stack, if you try to convert all kinds of Rev controls and stuff,
you end up basically reimplementing the engine, this is kinda hard. What we
need to leverage is not Rev engine and controls but Rev IDE using the tools
we like but not the standard Rev language and controls. I will detail below
the tools I think are needed:

TWO ENVIRONMENT FRAMES
First of all to understand this you need to understand an important concept.
For this system to work, there will be two different environment frames
running. One is the Rev IDE and Engine process which understands RevTalk and
is our development tool. The other is a background webserver that is the
target of our development tools and does not understand RevTalk but
Javascript. Actions on the development environment do not work directly on
the stuff we're developing but instead talk to the backend server that will
follow the orders.

WEB RUNNER CANVAS
Instead of creating stacks with all their complexity, we would create
something else that in the screen would appear like a stack, a floating
window for the user to drop and arrange controls. What would be running in
fact is a Rev coupled web server not unlike Ruby Web brick. This server
would be running in the background and we would be seeing its output on this
window inside the IDE. I have a Rev WebServer external ready for this
project. Thats the second environment frame that I've mentioned above. It
understands only Javascript.

WEB SAFE TOOLS PALETTE & INSPECTOR
Replacing the tools palette with a Web tailored one with tools that we've
scripted ourselves. They can mimic standard Revolution tools such as buttons
and fields but they are not in fact creating Revolution buttons and fields
but our own controls. We would also create our own inspector for setting
properties of our own self made controls.

When we drag a control to the WEB RUNNER CANVAS, we don't actually do
anything but talk to the underlining WEB SERVER saying we dropped such
control, the server then will instantiate the control a place it for us. So
in fact we're using Rev-like tools to talk to a web server that is building
javascript on the fly for us. When we drop a button on the web runner
screen, a POST call is made to the web server that picks this and creates a
button javascript object, this is transparent to the developer.

This way Rev becomes a HTML5/JS/CSS development tool. We don't have the
overhead of converting stacks to web because we're jumping that whole step
working directly with HTML5 and friends. This solves control placement and
interaction but does not solve script processing.

SCRIPT PROCESSING
We would define a subset of RevTalk and create direct conversions from
RevTalk to JS. As time went on we would implement more and more of RevTalk
but some minimal subset should be enough for a start. Javascript is a
wonderful language and converting scripts to it is the most safe option.
Running the frontend logic in something like FastCGI adds to much processing
to the server which adds to server load and to your costs.

The elegance of this approach is that we can begin with a fastCGI engine for
the script processing by directly executing RevTalk script on the FastCGI
process without translation, this way we could place all the other pieces
together before doing the RevTalk to JS work. By then we could simply put
our efforts on that translation.

We could build this and release under BSD license which would enable
business to use it in the commercial offerings and thus making it attractive
and incentive sponsorship. I would like to be paid to develop this free
solution but I think it is now time for us to work on this or risk being
left behind. This as it is defined needs no input whatsoever from the
mothership, it can all be done in Rev.

Any thoughts?





-- 
http://www.andregarzia.com All We Do Is Code.