push-style templating - an xml-like way to process xhtml

[lkcl]

On Nov 2, 11:19 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:

> Push-style though enhances the risk of mixing program logic with
> presentation-logic (as simple print-statements do), and makes it a
> precondition that anybody who's supposed to tinker with the softare
> needs to be knowledgable in Python as well as in HTML.

 i'd like to add perhaps a different perspective.  i've developed and
used the following:

 * xmlvl (http://sf.net/projects/virgule) - it's a (non-NP-complete)
XML-based programming language, which was derived from advogato's
codebase.  it outputs XHTML, is "template-based" and implements what
is best described as an XML-based lattice-like, "crystalline" and
hierarchical OO database (!!).  i understood it while i was writing
it, but woudldn't dare go near it, ever again.

 the lessons learned from this were: don't take templating to extremes
(i.e. do the absolute minimum), and never ever write programming
languages in XML.

 * python-htmltmpl (http://htmltmpl.sourceforge.net/) - it's a simple,
utterly simple, HTML-syntax-like templating language, which can do
"substitution", "if/else statements", and "loops".  that's about it.
the nice thing about htmltmpl is that it can do pre-compilation of its
templates, inserting jump-points (which are used to seek() to the next
precompiled statement) into the .tmplc files.  this saves a _great_
deal of time and CPU cycles.

 the lesson from this one is hard to get across, because htmltmpl
basically... works.  it doesn't _need_ developing, it's complete, it
works, it's never going to get up in the sourceforge "rankings"
because... it does everything that it's designed to do.

so it drops off of people's radar, and they reinvent the wheel.

if you think you need anything more than htmltmpl, which separates out
html from programming, think again.  you can pass in a list of
dictionaries into htmltmpl, that generates the table content, form
content, whatever-content.

job done.

* pyjamas (http://pyjs.org) - this is treating the web page and the
web browser as a desktop "canvas", i.e. turning the web browser
concept on its head, and allowing you to program it in exactly the
same way that you would if you were writing a desktop app with PyQt4
or PyGtk2.

no kidding about, here.

why on earth would you want to do something like this?  it's very
simple: HTML "programming" is madness.  it's madness from two angles:

1) CSS abortions.  as an example: i tried doing a centred-box, once.
it took two weeks, and it still was a failure: worked fine in firefox,
but in IE6 if you squashed the browser size, so that normally under FF
you got a horizontal scrollbar, what happened in IE6 was that the
content scrolled off the *top* of the screen!!  unbelievable - and
completely impossible to fix.

2) HTML template "option-itis" resulting in thousands of lines of HTML
that becomes impossible to read, and impossible to maintain.  i think
the worst example i ever saw - and i'm sure people will find worse -
was a technique involving _four_ separate near-identical pages (each
over 3,000 lines long) - one for new entry form, one for new entry but
with error-messages interspersed, one for edit, and one for edit but
with error-messages interspersed.  cut-and-paste gone mad.

HTML templating is, for complex applications, a baaaad idea.  even
when you start "breaking down" the content into smaller server-side-
includes, and even when you start doing multi-layered HTML templating
(one template gets marked up and then substituted into another
template and so on), even _that_ technique gets very quickly out-of-
hand and you're left with a headache.

so now i choose pyjamas over _any_ kind of web programming, any day of
the week.

the reason is very straightforward: the amount of code being written
is small; it's in python; i can re-use classes and modules; i can even
take standard python modules such as an XMLRPC client or a JSONRPC
client and actually compile them (to javascript) for use... in a web
browser!

you can put in a < div > with an id, you can find that div using a one-
line function, and you can substitute "widgets" - your classes - into
that div.  it's a very, very powerful technique.

complex application programming should be done in a complexity-capable
programming _language_.

HTML, which is a markup language, is simply not designed - and was
never designed - to be "programmed" or to be an NP-complete
programming "language".  it's great for "static content", which can be
edited by graphical tools, and that's about it.

so, there _is_ an alternative approach, with pyjamas, to what you're
saying, diez ("Push-style ... anybody who's supposed to tinker with
the softare needs to be knowledgable in Python as well as in HTML.")

the alternative is: program the entire web site in pure python.  as if
it was a pygtk2, pyqt4 or python-wxWidgets desktop application.

l.