Python vs PHP

[Alex Martelli]

Istvan Albert <ialbert at mailblocks.com> wrote:

> Alex Martelli wrote:
> 
> > Not sure what example you mean:
> 
> http://www.divmod.org/Home/Projects/Nevow/
> 
> data/render methods
> 
> > But the point is, the logic
> > is in the code, Python code well out of this HTML file; the role of the
> > template is to provide the HTML basis, and tag where the current data
> > comes from, which method renders it
> 
> The render_colorful method creates a new attribute "color" that
> was not specified in the template. They may have moved all python
> out from HTML but surely did not move out all HTML from the
> python code.

Surely there is no prohibition against the Python code generating all
the HTML it wants; it doesn't even have to use any template whatsoever
if it doesn't want to, generating HTML from code is the main thrust of
stan, somewhat similarly to Quixote.  It's not true that Nevow _is_
templating: Nevow _has_ templating, as one of many tools -- it just
happens to be the one tool I think should be used, given the scenarios I
explained.


> I would argue that this is not templating in the way
> people use this term. Here the "color" attribute just
> appears from thin air.

I don't see anything contradicting the usage of "templating" in leaving
code in ultimate control of what gets output -- adding attributes is no
different from adding or removing tags.  Once my nevow-using code has
gone for the templating choice, it's in fact not in "ultimate control",
in a sense, since renderers are chosen by the template; the code
controls which renderers it supplies and what exactly they do, the
template controls which renderers, out of those supplied, get used (and
with what arguments, if any -- with what DOM subtree being passed to
them, since that's exactly the template's contents -- etc).


> I stick to my opinion that every framework must allow one to bend
> the rules because in real situations one cannot always choose
> *the right thing*.  What nevow seems to be doing is bend
> them by allowing  HTML to be moved into python,
> or to say it more nicely, by allowing python to modify
> the template document object model (DOM).

Oh, it also allows Python to create HTML out of thin air, if the
programmer so wishes -- there's no constraint in Nevow to actually force
your code to use any of the templating subsystem.  It's mechanism, not
policy.  I think it _is_ feasible to use that mechanism to always do the
right thing, even in perfectly real situations: never emit any piece of
HTML that didn't come from templates, using renderers only to select,
reiterate, etc, the appropriately marked-up pieces.  But there's no
constraint against writing a renderer that just ignores everything and
returns '<strong>pekaboo!</strong>' (direclty or via stan); just like
there is nothing in Python that stops the renderer from having a nice
'while 1: pass' right at the start, and block everything.  It's simply
better to not combine the mechanisms that Python and Nevow order in ways
which make them implement such ill-advised policies, that's all.


Alex