What Rev CGI can do? Please advise.

[alex298]

Hi,

I already setup Rev CGI and played around for some time. It seems that the stack, card, button, fields, and other objects cannot be used on Rev CGI. Is it true? If the answer is positive, I wonder why I use RR to develop websites?

Best regards

[FourthWorld]

I've been able to create and use cards and controls for data storage, but beyond that objects have little meaningful role in CGI work.

CGI's are just a way of dynamically generating HTML for delivery to a browser. Rev's native objects mean nothing to a browser.

What would you like to do?

[alex298]

Hi Richard,

Since I have been using Perl and PHP to develop websites for quite a long time, I would like to see if Rev CGI can do something like Flash. This would be wonderful if cards and objects can be used in Rev CGI.

Best regards

[FourthWorld]

Ah, but Flash isn't a server-side technology; it lives on the client-side as a plugin.

There have been many requests for a Rev plugin, but frankly I'd much rather see Java bytecode generation.

The problem with a plugin is that it still needs to be located, downloaded, and installed before anything can be run. In practical terms, this is no different from making any Internet-savvy standalone in Rev which you can do right now. Any organization that won't deploy a standalone to their users won't likely deploy yet another plugin.

Flash got around this by negotiating the first bundle agreement with Netscape, and with the full force of Macromedia's marketing behind it they won the plugin wars long ago. That particular historical moment is unlikely to ever be repeated, so any other plugin faces the same deployment issues as a standalone.

There are a great many Rev-based standalones that make innovative use of Rev's built-in support for HTTP and FTP, and some even use Rev's socket support to provide custom protocols as needed. There's no end to the types of widgets that can be made with Rev.

But displaying them in a browser specifically is a tough task. If it were absolutely essential to run Rev media within a browser window, Java bytecode would be one way to go.

But in the meantime, pretty much all of the "Web 2.0" apps have UIs driven by just JavaScript, which can be generated by a Rev CGI just as easily as from Ruby or Perl or anything else. This way you're on a level playing field with other web app developers, but you get the grace and ease of Rev's chunk expressions and other text-manipulation goodies to make it that much easier.

If it's the Internet connectivity you're after and you don't necessarily need to run your app inside the limitations of a browser window (giving you all the benefits of connectivity with additional things not possible in a browser-only app like local data storage and an offline mode), that's even easier to build right now.

So while it might be convenient to have Java bytecode output, there's nothing stopping us from building a wide range of Internet apps with Rev right now, both inside the browser and beyond it.

[alex298]

Hi Richard,

What a wonderful post! You are a real expertise. I really learn a lot.

By the way, are there any online web applications and websites that are made with Rev CGI? I think I can get more ideas and inspiration by studing how people using Rev CGI to develop websites and online applications.

Thanks and best regards

[ale870]

Hello,

I found this interesting topic, so I wish to highlight how I use Revolution.

Currently, I create rich client applications using rev studio, and the server side is made in java, using Glassfish (simply great, simply open source!).

Client and server communicate via http, and exchange data using xml (for data-only).

Since Rev has the great feature to be able to load pieces of application from a server at runtime, I distribute to the clients a minimal Rev program, then everything else remains on the server.

So I can create some "plugins" (library, etc...) that I send to the client to compose the final application.

This method let me build rich client programs like a Lego (the famous little bricks used to compose many objects).

Java, on the server side, gives me all the power and flexibility I need to create a robust back-end (business logic and database connection) for the applications.

[alex298]

Hi ale870,

This is really interesting. I am sure I have a lot to learn. I really don't want to sleep.

There are something that I am not quite understand. Since you distribute the Rev client application to your clients. The Rev clients will download stacks (e.g. plugins, library, etc..) from your server to compose the final Rev application. It seems that there is no need for the Java server side application. What is the purpose of the Java server side application?

Thanks and best regards

[ale870]

Hello,

server side (java or other systems) are really needed since when you develop "rich client applications", in the client side (RunRev) you create only a front-end: fields to insert/show data, variables to maintain the status of the software, check use input validation (first level, more checks could be done in the server-side), etc....

Then the server-side takes the data (xml? ok) and...

1) verify if everything is correct
2) makes needed calculations
3) get/store data in the database
4) etc...

Furthermore the server could get/send data even in other formats.
For example, if you create BIG applications, some people (other developers) could ask you to get your data using their applications (not using yours, since, even if your application is very good it does not fit their needs. So, in the server-side, you could create some web services in order to spread the content (not the program!).

Another example.
Someone tell you that he wants to access to the data not only using his desktop (and RunRev), but even using a smartphone. In this way you could create a small java client app, or some HTML pages (with reduced html instruction set) and distribute those information to everyone.

Look at the "schema" (sorry, it is bad, but I'm a programmer not an artist ):

Code: Select all

Client RunRev        --> |
Client Web           --> |                        |Other resources
Client smartPhone    --> |  SINGLE APP.SERVER --> |Database
Client unknown       --> |

Every client is interfaced to the server (in my case, using Java) using specific connectors (you could using different tecniques).

The "trick" is create a separation layer between the data and the applications (that manage the data).

Using an application server you can concentrate all the so called "business logic" in a single place (in the server, not in the client), in this way you don't need to replicate the same code, but you write it only once (shorter development time, better maintenance, etc...).[/code]

[FourthWorld]

This may also be of interest - see the middle of this page:

http://www.runrev.com/newsletter/may/is ... W48S502007

[alex298]

Hi all,

Thanks for your great information. The New Web Plugin must be an exciting new feature for RR. Hopes that it will release very soon.

Thanks and best regards

[Stryder]

Hi Richard,

What a wonderful post! You are a real expertise. I really learn a lot.

By the way, are there any online web applications and websites that are made with Rev CGI? I think I can get more ideas and inspiration by studing how people using Rev CGI to develop websites and online applications.

Thanks and best regards

The company I work for has deployed an entire website built on Runtime Revolution:

http://www.gatewestcoin.com/

Of interest would be the online store, the auction website, and the bullion prices page. All of these are built using Revolution CGI.

[FourthWorld]

The company I work for has deployed an entire website built on Runtime Revolution:

http://www.gatewestcoin.com/

Of interest would be the online store, the auction website, and the bullion prices page. All of these are built using Revolution CGI.

Nice work. Glad to see you got the CGI running, and have made some excellent use of it.