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:
<html>
<head>
<title>Current Server Time</title>
</head>
<body>
The current server time is [[the internet date]]
</body>
</html>
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
<html>
<head>
<title>Current Server Time</title>
</head>
<body>
The current server time is <! include exec="someRev.cgi">
</body>
</html>
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..
Sivakatirswami
==============
<HTML>
<!--#include virtual="/ssi/copyright.txt" -->
<HEAD>
<TITLE>Hinduism Today | Movies | October/November/December, 2005 </
TITLE>
<!--#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
</h3>
<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" -->
<!-- =========================== -->
</HTML>
_______________________________________________
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
