Making the move...

[Richard Gaskin]

Dan Shafer wrote:

> Richard....
> 
> I agree that "merge" is very cool and quite powerful.
> 
> Still, I cannot put into a Web page:
> 
> Hello, there. The time is <% merge [[the time]] %> (regardless of the
> dellimiter being used around the call) as I can with Ruby. The merge
> operation would, I think, have to be included in the CGI generating the
> entire text string above, right? Or am I really missing something obvious
> here?

The merge function can take any block of text (such as an HTML page, for 
example) and will replace Transcript expressions between "[[" and "]]" 
with the evaluated result.  You can but any expression or container 
reference between those brackets, including variables, constants, or 
even calls to Transcript functions defined elsewhere, and you can place 
any number of these anywhere in your HTML.

It really is worth devoting a half-hour to playing with.  Merge is one 
of the best things Transcript adopted from SuperTalk (from back in the 
days when Allegiant was pushing a server-side engine).

You can use the merge function in a CGI script, or in HTML templates 
processed by the engine, however you like.  And just like the 
recommended Ruby setup, we have users on this list who set up Rev with 
FastCGI, so performance should be roughly on par with similarly 
configured systems.

With Ruby it's common to create server directives that pass any files 
accessed in specified directories through Ruby on the way out (in 
essence an "implied CGI"), and I see no reason one couldn't do the same 
for any text processing engine they're using, such as Rev.

So while it seems somewhat magical to use:

    http://www.domain.com/appstuff/

...all that's really happening there is the server is set up to 
interpret that as:

    http://www.domain.com/appStuff/default.rb

Set up similarly, you could just as easily set up the server to have 
implied default pages specified as belonging to Rev, so calling the 
directory above would be interpreted as:

    http://www.domain.com/appStuff/default.revhtml


> Again, as I said earlier, this may well be a distinction without a
> difference when it comes to accomplishing what I'm pointing out as the main
> advantage/feature of an MVC framework for Web development, namely the
> (relatively) clean separation between presentation and business logic. I'm
> not promoting Ruby, just trying to understand the qualitative difference in
> using an embedded scripting language vs. a CGI approach.

"Embedded" is just how you set up your server to use the text processing 
engine of your choice, be it Ruby or Rev or whatever.  Since Ruby is 
most commonly set up using FastCGI, any distinction between "embedded" 
and "CGI" may be too subtle to be instructive.

But when you mention the framework, now you're on to the big difference 
that makes RoR attractive:  Rails already exists, whereas one would need 
to write a well-factored web app framework in Rev to get the same level 
of productivity.

MVC can make a good foundation for such a framework, as can many other 
common patterns.  Anything that separates code, content, and 
presentation is a step in the right direction, esp. if it makes smart 
use of triggers and accessors as MVC and similar patterns do.

As I noted here recently, I'm not yet convinced MVC per se is the best 
fit for Rev.  I'm open to opinions to the contrary, and would enjoy 
learning about successful apps shipped with a Transcript implementation 
of MVC.

Among languages that don't already provide MVC classes, there's much 
debate about how to graft them on.  The more I look into it the more I 
find many different flavors of MVC, MV, and similar factored patterns. 
For example, there's at least one good paper outlining how Apple's MVC 
in Core Data differs from SmallTalk's.  The biggest debates out there 
seems to focus on the scope and role of the Controller (most pretty much 
agree what a Model and a Viewer are), and a few have dropped the 
Controller altogether.

I haven't had enough commercial experience with MVC to have a strong 
opinion about those differences.  But stepping back from other people's 
implementation specifics to focus on the results we're all looking for, 
there are many ways to separate code, content, and presentation with 
Transcript.

Couple that with the high productivity of Transcript's typelessness, 
chunk expressions, and merge function (just to name a few), Rev would 
seem a worthy contender for anything involving a lot of text processing, 
on the desktop or the server.


PS: For a fun take on the flipside of frameworks, this post at Joel is a 
hoot:
<http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12>

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com