Dan Shafer wrote:
> On 3/14/06, Richard Gaskin <[EMAIL PROTECTED]> wrote:
>
>> But if the goal is to deliver the benefits of productive,
>> flexible systems, Transcript can prove quite capable in
>> ways that may surprise.
>
> Richard.....
>
> I *certainly* don't disagree with your response, but I'm earnestly
> seeking a description of how you'd go about building an app in Rev
> that is entirely deliverable via a Web browser, which is, I submit,
> the definition of a Web application. I think that was the original
> point/question. Creating thin-client Web appliances is amazingly
> easy with Rev. Creating CGIs that run on a server -- including
> back-end database access -- is also feasible, if somewhat limited
> in terms of performance (no FCGI support as far as I know).
>
> If this is possible, I'd sure like to know how to do it.
A "web application" has at least a web-based interface, and often also
has a server-side component to it.
There are three viable methods of making an interactive interface in a
web browser:
a) Java
b) Flash
c) DHTL (recently re-christened "Ajax")
Rev doesn't produce Java or Flash output, so if those are desired you
would indeed have to go to another tool.
But neither does Ruby.
Nor is Ruby embedded in web browsers.
Web browsers have only one universal language at this time: JavaScript,
which is the heart of DHTML/Ajax.
JavaScript is plain uncompiled ASCII text. It can be
generated/assembled/sliced/diced by a Rev-based CGI just as assuredly as
any other language, such as Ruby, can do so.
Rev's merge function is enormously powerful, as are its chunk
expressions and file handling. Smartly-designed snippets of JavaScript
and HTML can be combined and recombined quickly and easily with Transcript.
As for performance, most CGIs are loaded when called. The exception is
FastCGI, employing a stay-resident option to minimize load times. Many
ISPs preconfigure their Perl installations to use FastCGI, and FastCGI
is the recommended interface when you install and set up Ruby. It may
be possible to use FastCGI with Rev; I'll leave it to the server experts
here to fill us in on that.
When run as a CGI, the Rev engine loads _much_ faster than it does on
the desktop, which is pretty darn fast as it is. As a CGI it doesn't
need to initialize any of its GUI elements, so the load time on a decent
server should be roughly on par with any other engine of equivalent size.
It would be helpful is someone here has performance benchmarks on Rev as
a CGI relative to Perl, Python, Ruby, and other server-side languages.
If FastCGI cannot be used with the Rev engine, then indeed we can expect
a performance disparity between the Rev engine and the Ruby engine. But
"impossible"? I don't see how.
One of the main bullet points for developing in RoR is the MVC
implementation, but again that's not exactly new. Smalltalk had MVC,
and there are implementations in most OOPs and many non-OOPs as well,
including a few done in Rev to varying degrees. While the Rev ones have
focused on native controls for triggers, one would have to write
JavaScript triggers for web-based UIs, as they would with any
browser-based implementation.
Ruby is a fine language, and the "on Rails" framework is well thought
out and very useful. But it's not magic; Ruby is just a language, its
"Rails" just a framework, and I've seen nothing in it that couldn't also
be done with Perl, Python, Rev, or any other CGI. There may be
tradeoffs with runtime performance and development productivity, but I
see nothing which would discount all web applications as "impossible" to
do in Rev.
And as you note, Rev does one thing Ruby can't: compliment the range of
deliverables with a net-savvy desktop app (think maps.google vs Google
Earth). While only useful in a subset of scenarios, it offers many
benefits, esp. for intranets where employers are losing billions in lost
productivity by providing open web access to their employees when all
they really need is access to specific company- and vendor-specific
resources. Rev-based net-savvy apps (or "net apps", or "net
appliances", or "thick clients", or whatever else one might call them)
are like VPNs for the rest of us. And, as with Google Earth, there are
UI benefits to such desktop implementations as well.
All that said, there are two benefits to Ruby: most of the code you'd
need is already written, and as open source it's all freely available.
But while Ruby may have some advantages, that doesn't make using other
languages to generate DHTML interfaces impossible.
Taking this a step further, I'll close with an exercise for the reader:
1. Make a web app development tool in Rev for laying out and generating
DHTML controls for web pages.
2. Now make the same tool in Ruby.
;)
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
