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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
