Making the move...
revolutionary.dan at gmail.com
Mon Mar 27 13:10:55 EST 2006
OK, I've thought about this some more and poked at some of the CGIs you've
developed. The place where this "include virtual" approach to Web site
design breaks down for me comes at the point where, as I said in my original
definition, we have "embedded command and function calls" in the underlying
Mind you, I'm not sure this isn't a distinction without a difference, but
that was my intent in my earlier posts. I had, in fact, used SSI with the
"include virtual" command a very long time ago and had shelved it, though I
am no longer clear on the reason why I chose to do so at the time. Perhaps
there are some downsides to using SSI that I'm forgetting. The Apache site's
discussion of SSI includes this caveat: "SSI is a great way to add small
pieces of information, such as the current time. But if a majority of your
page is being generated at the time that it is served, you need to look for
some other solution." Perhaps that or something like it influenced me.
In any case, what is clearly NOT happening with an SSI is the inclusion of
Transcript commands or functions directly in the HTML file from which the
dynamic page is generated. All of the Transcript code is external to the
page layout/template. The overly simplistic example I provided earlier of
using an embedded call to a built-in Ruby function such as Time.now() is the
key idea here. The call to that function generates NO HTML code, just a
value to be substituted into the HTML page when it's generated by the
server. Using CGI, you can't mix HTML and operational code *in the HTML
template or page*. This means in general that the CGI must generate HTML
blocks to be inserted into the HTML page at generation time on the server.
This means, e.g., that the person writing the CGI must know HTML and the
page design with which the CGI is designed to work. It also means that the
HTML designer must typically be given access to the CGI code or, in the
alternative, the CGI developer must be asked to hack HTML into the CGI
itself. In both cases, we mix presentation and functionality in a way that
is fraught with danger and maintenance issues.
That is where a Web app framework -- like Ruby on Rails, though there are
several others worthy of consideration -- shows its strength. By adopting
the model-view-controller (MVC) design paradigm, RoR creates an effective
split between presentation and logic. The HTML designer works on views. The
developer creates Controllers that look to Models for data they need to send
to the views and for other logic that affects program execution. That
bifurcation is important on non-trivial applications. A Web app framework
that follows the MVC paradigm (or perhaps some other approach that provides
the same division of labor) is preferable to CGI-based solutions which not
only encourage but demand a mixing of the two somewhat incompatible skill
On 3/25/06, Dan Shafer <revolutionary.dan at gmail.com> wrote:
> Wow. I gotta go try this as soon as I finish this talk I'm giving
> And please send me those URLs you mentioned offlist. This could be HUGE
> for me. I had no idea this could be done and I don't know why I didn't have
> any idea this could be done.
> On 3/24/06, Sivakatirswami <katir at hindu.org> wrote:
> > Dan, if your definition of a web app really is:
> > > a Web *app* consists of a collection of 1 or more
> > > templates -- HTML files with embedded command and function calls --
> > > that
> > > execute in a server-side scripting language interpreter running on the
> > > server. All Web pages with this embedded script code are run
> > > through the
> > > scripting language interpreter on the server, where the command is
> > > carried
> > > out and some content is generated to replace the command call
> > > before the
> > > page is sent to the HTTP server to return to the client.
> > We are *already* doing this with Rev for several years now (and I'm
> > pretty sure I'm not the only one, I got into this with Andu Novac
> > when this was all metacard years ago... he still around?) and it
> > works great, even without fastCGI...the fact that Rev is called on
> > each hit doesn't seem to be an issue at all.
> Dan Shafer, Information Product Consultant and Author
> Get my book, "Revolution: Software at the Speed of Thought"
> From http://www.shafermediastore.com/tech_main.html
Dan Shafer, Information Product Consultant and Author
Get my book, "Revolution: Software at the Speed of Thought"
More information about the Use-livecode