On Jun 27, 9:09 am, "John Salerno" <[EMAIL PROTECTED]> wrote:
> Of course, I suppose whether or not any of this matters depends on if you
> are a web designer or a programmer, but am I missing something about
> templates, or is it really the case that they, more or less by definition,
> combine content and logic?
This is a little anecdote about "separation of presentation, content,
and logic." I used to work in a web application development
environment that resembled Visual basic. The application presented its
data through a java applet, and the server was written in lisp. If you
were able to avoid the bugs (a bit like the fire swamps from The
Princess Bride) then you could be fairly productive. The server took
45 seconds to start, took up a gigabyte of memory, and the applet took
up 50 megabytes of memory in the browser and had sluggish performance.
When I got a job as a LAMP, P = python developer, I first created a
little program that would sift content in an "xhjp" file (which stood
for "cross between html, javascript, and python.") The big idea was:
you could write "dynamic elements" like so:
{{{ <div some HTML div to anchor your element/>
Python code to render a chunk of XML
|||
Javascript code to use the XML to do something interesting
}}}
There was a makefile that turned a single xhjp into a javascript file,
and html file, and a python file. The hope was that you could think
about the logic of elements in a single place.
I thought this was a great idea and that it would be a big help in
development, but it turned out to be a drag. Eventually I realized
that I had to get my hands dirty and write a decent javascript
framework to manage the page layout. This was somewhat painful, since
among other things firefox doesn't report javascript exceptions that
occur in response to an async http (commonly known as AJAX) request,
but now swapping components in and out of the page is relatively easy.
Currently the app gets its information with JSON (highly recommended),
and tells the server what it wants with a "why" dict entry in the
async http post (the information sent to the server is bundled in a
dict). The server runs Django. To give you an idea of the current
design, an async post scrapes a piece of information off of every dom
element whose class is "context", bundles it with a "why", and
provides a custom callback (this is far from ideal, something of a
compromise). The vast majority of the dom elements are constructed
with dhtml using information supplied by the server; this is possible
because it is a intranet app. A public web app would do this with a
template, before it hits the browser.
BTW there is a good document design_philosophies.txt in the Django
documentation. They have a section on why you *don't* want to put
python code in your html.
Cheers,
David
--
http://mail.python.org/mailman/listinfo/python-list
