Revolution => Flash

Andre Garzia andre at andregarzia.com
Fri Oct 12 13:57:31 EDT 2007


Hello Friends,
Again we touch the topic of revolution, plugins, flash and the web. This
topic always appear, not because we're stubborn but because it is hot and
current. I'll not repeat all things the other mails said but will try to
propose a simple solution that can be attained now with the resources we
have, it just take a group of developers engaged to make this happen.

Exporting from Rev to Flash or Java is not feasible because it ties Rev to a
third party product that can take directions that completelly break rev
compatibility. Creating such exporter would require a new engine that would
run inside the flash or java plugin or it would require a translator that
would convert revolution logic to actionscript or java. This poses a problem
since the three languages have unique features. It's not that it can't be
done, it's that it is not worth being done.

What people appear to want here is something that would enable them to build
AJAX application with Revolution. Create the next 37signals or something
like that. Nothing is stopping anyone here from building Revolution based
web applications, the problem is that one of the biggest advantages of Rev
is lost when building web application, which is the presentation layer.
Revolution UI elements are not transferable to the web. So even as if we can
code in transcript our web application, we can't build the interface in Rev,
we need another set of skills like css, javascript, html to build the UI.

So in the end the problem is very simple, our only problem is: "how do we
map revolution UI to the Web?", if we could map this, then a pure transcript
solution for converting stacks to the web would be born in a couple thousand
lines.

Every web application is divided in the following components: UI, UI logic,
Server Side Logic. The UI logic makes the connection between the UI layer
and the server side components. This is a variation of the MVC paradigm also
called model2 by Sun. We can already create the server side logic, we need
to create tools to work out the UI and UI Logic component.

The User interface is mostly HTML + CSS + some javascript in some cases
(rollover and animation effects). The UI logic is pure javascript (XHR calls
and the like). I know we all love Transcript but allow me to say that
Javascript is a very nice language supporting some very nice features. It's
actually pleasant to code in javascript once you know. The thing is that Rev
coder should not be forced to learn javascript or at least that Rev could
create basic javascript for the developer so that the end job is just a
fine tuning one (like ruby on rails skeletons).

To programatically convert UI logic and UI components from Rev to the web is
not an easy task. The models are completely different.

Rev -> Stacks, Cards, Groups, Objects. Most based on fields and buttons.
Web -> The DOM, CSS, nested nature of HTML. Most based on text and images.

Mapping from Rev to the Web is a daunting task, for example, how do you map
"go next card" to the web, what should happen? go to a new page? display a
hidden div?

What we need is a new tools palette with WEB ELEMENTS and a converter
plugin. This plugin would know how to convert those elements to the web.
Then Revolution becomes like Apple Interface Builder, you have a set of
palettes to build an interface that can be accessed later by your web
application. Instead of trying to convert a stack app to the web, we begin
from the start building a web application using web safe elements and web
safe code. This can be created inside revolution right now, it just take
time and effort.

This web safe environment would have conventions like "stack script" goes to
server side component, "card script" goes to UI Logic component. The stack
controls disposition is converted to CSS using absolute positioning. We
don't even need the build-upload-debug cycle, we can keep testing all this
at runtime by a combination of RevBrowser and RevHTTP inside the IDE.

This is easier shown than explained. I'll build something to show in the
next two days...
andre



More information about the use-livecode mailing list