Making the move...

Sivakatirswami katir at
Tue Mar 28 22:20:32 EST 2006

On Mar 27, 2006, at 8:10 AM, Dan Shafer wrote:

> 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
> sets.

Dan, this is a good point, in my ignorance I may be making this all  
too simplistic, but is not the "bifurcation" a design decision?

I mean if  the SSI <! include exec some rev.cgi.> returns data to the  
HTML page instead of an HTML chunk, then you have the separation  
between "views" and "data"  you describe, n'est pas? No? And if  
Revolution is running as a daemon then even if you had 10 such SSI  
calls in a given web page, I don't see how this would be  
substantially different from having 10 merge statements embed in the  
page ... in fact, if separation between the vehicle (view) and the  
data in it (returned by SSI's) is "important on non-trivial  
applications" then doesn't putting the  merge statements back into  
the html break that mandate? i.e. Marks solution puts the entire  
burden of the page development on the programmer and the HTML page  
designer is out cold.

I mean doesn't a page like this elaborated to some thing more complex  
and really useful:

       <title>Current Server Time</title>
       The current server time is [[the internet date]]

take you right back here where you didn't want to be:

> 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.

On the other hand, that problem set aside (even though, for me at  
least it *is* a core issue I face on a daily basis)  I guess we can  
see that Marks model is fundamentally different than

       <title>Current Server Time</title>
       The current server time is <! include exec="someRev.cgi">

where -- if you had ten of these includes in the page -- you are  
asking apache to call the CGI ten times.

Yes, I too saw those warnings: "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." But I just ignored them. We were not  
sophisticated enough to do a full on dBase web site and so SSI, was  
our only solution to global maintenance and separation of content  
from the DOM.

And we really don't see any delivery time issues with pages that look  
like the ones below. Of course, it we had super heavy traffic it   
might be different. I'm actually thinking now of changing the entire  
model to using a dBase web site or  XML-XSLT with flat files that  
regenerates the entire web site (or areas) that are 100% static code  
(no SSI's at all in the web pages at all) so then Apache has no work  
to do other than ship bytes. But, until SSI proves itself to be bad,  
and despite warnings I see no problems so far.. we will continue to  
use it. (aside: But what's happening is that the web site is now much  
more than just pages, it is an historical resource and in its present  
form, inaccessible. WE sell rights to some of the data engine  
companies, meanwhile we ourselves we don't even have a decent index.  
so I want to recast the content in a way that will make it much more  
useful... but I don't really know what direction to go in...)

This is an excellent discussion, I find one of our regular  
"challenges" is how to open up channels to engage more people in the  
process of web content distribution, where the "wiki" and "blog"  
model is too open ended, and yet you need a UI where people can  
contribute directly. I would concur with Chipp about separating the  
framework and talking in terms of libraries...if you keep mucking  
around changing the framework your productivity will drop through the  
floor. Though my wish list of Libraries might be different, its the  
same need.  A typical real world example could be someone who is  
responsible to inputting textual information (blog if you want to  
call it that, but it could be any kind of web page) and you want that  
to appear on a web page but you need to have it spell checked first.

All Hinduism Today web pages look like this and while the DOM is a  
bad one (the  XML tree is not complete in itself in the template doc  
and I am going fix all that one day) .. now.. imagine these includes  
were entire "processes"  There are lots of reasons why we need to  
completely re-think how we deliver this content, but this does work.  
2/3s of the page in terms or structural elements is SSI. the end  
result is an archaic, impossible table based page from before CSS era..



<!--#include virtual="/ssi/copyright.txt" -->
<TITLE>Hinduism Today | Movies | October/November/December, 2005 </ 

<!--#include virtual="/ssi/article_header.txt" -->

<!--Start article text-->

<h4>October/November/December, 2005 </h4><p>MOVIES</p>

<h1> "Super Size Me!"</h1>

<hr  class="shortrule" />

<h2>Breakfast, lunch and dinner at McDonald's for a month how it  
ruined a filmmaker's health </h2>

<h3>By Mark Hawthorne, California

<p>[snip... where the article text itself consists of very simple   
mark up] eating disorders.</p>

<!--End article text-->

<!-- ======= FOOTER TEXT ======= -->
<!--#include virtual="/ssi/article_footer.txt" -->
<!-- =========================== -->

More information about the Use-livecode mailing list