Python vs PHP

[Alex Martelli]

Istvan Albert <ialbert at mailblocks.com> wrote:

> Alex Martelli wrote:
> 
> > Me too.  nevow forever...!!!
> 
> Hm, it says on their page:
> 
> "However, no actual code may be embedded in the HTML template"
> 
> alas these are the sort of design decisions that
> won't adapt well for real life scenarios.

Works fine for me.

> Should we use code in templates? No. Should we make
> every possible effort to prepare the data exactly as
> we need. Absolutely.

The template is not going to be exactly the HTML code we need to output,
of course; that's what the nevow namespace is all about --
letting the template get the data it needs and pick the rendering
approach it prefers among those the application makes available.


> Yet as soon as the whole thing is working we realize
> that we forgot something and that fixing it the
> "right way" will cause a significant setback. That's
> reality, trying to avoid these by mandating a
> certain behavior will only make the framework less
> usable.

What setback?  If you've omitted to provide (e.g.) a rendering method
you realize you need, you add it to the Python code and access it with
the appropriate nevow:data="whatever" attribute in the template.  No
problem.


> And that is where ZPT shines. You want full separation
> go ahead. You want to bend the rules a bit go ahead.

Special cases are not special enough to break the rules.

That's what makes Python great.  It's what will make nevow great when it
gets a bit more stable (it IS still at 0.3, after all -- and I've seen
bugs in 0.3 that are already fixed in CVS [duplicating the patch I was
going to submit, natch;-)]).

> You want to do it the wrong way and put your entire
> program into the first "define" tag, well, guess
> what you can do that too.

If you think that's a plus, go ahead, but then to be consistent you
should be coding in Perl...


> ps. as I look that the data/render example, I noticed
> the color attribute is actually created in the
> code ... IMO this is exactly what we are trying to avoid
> with templating. There is no indication in the
> template that a new attribute is going to be added
> to the tag ...

Not sure what example you mean (I'm not up to date on nevow's current
docs).  If the template gives control over to a rendering method, it's
of course fine for the rendering method to perform whatever rendering
alterations it's documented to perform.  I disagree that removing
rendering functionality from code is "exactly what we're trying to
avoid": _some_ rendering requires logic (conditionals, loops) and
getting such logic OUT of the HTML is what _I_ see templating as being
mostly about.

There are many finer-grained ways, such as nevow:slot and
nevow:attribute, for the template to suggest exactly what aspects of the
rendering should be controlled by the code.


> compare this to the same thing in ZPT:
> 
> <span tal:content="name" tal:attributes="style color">Tag Name</span>

With the appropriate renderer (and NS declaration), the nevow equivalent
might be:

<span n:render="name">
    <n:attr name="style"> <n:slot name="color"/> </n:attr>
</span>

It could well be simpler, in many ways, depending on how the renderer
method render_name in the code behind this page is specified (where else
but as a style attribute should the color go, for example?  so wanting
to spell it out this way may be redundant).  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, and what spots need to be
identified (as slots, attrs, or patterns).


Alex