Python vs PHP

[Ian Bicking]

Alex Martelli wrote:
>>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.

Well, this quickly becomes a matter of aesthetics, intractible to argue 
about... but anyway...

The question then is, what are you trying to achieve with nevow's 
templating?  (Or maybe, what do you think is achieved?)  I don't think 
anyone is achieving the separation of rendering logic from control or 
business logic with templating -- rendering logic is too sophisticated 
(in real applications) to always rely on a template.  In ZPT, some logic 
remains in the template; the amount of logic is flexible, and frequently 
changes back and forth as the application is developed.

Nevow has a very strong limit to how much logic can go in the page -- 
and that limit is very low.  It's not a limit of zero, since it is more 
sophisticated than something like XMLC or the DOM.  But it's not 
terribly high.

Something that ZPT tries to attempt -- and not entirely successfully -- 
is a separation of concerns, so that some people can work primarily in 
ZPT.  I frequently work with people who work entirely in ZPT, sometimes 
stretching it further than it should go; but in those cases they are 
able to move forward with ZPT, and later we can cooperatively refactor 
the code.  If I'm the only one comfortable going into the Python (which 
is usually the case), I'm not a bottleneck.  I'm not sure this is 
possible in Nevow.

Now, there might be a valid compromise where a more declarative template 
language is acceptable in my sort of situation.  Indeed, there is a 
problem where control and rendering logic become mixed, which is part of 
why other people aren't comfortable going into the Python code (though 
there's other reasons, like they aren't familiar with the domain objects 
or other pieces of the system).  In some ways, I'd like to see a 
templating system where I can call the template from my control code 
with a minimal, fixed interface, and that there is a small bit of Python 
code that does the heavier lifting of making that data acceptable for 
the template.  To a degree that's already true.  OTOH, I don't know if 
it's helpful to code alternating row colors for a table in Python, when 
it will be necessarily far away from the table that needs the coloring.

Anyway, I'm very suspicious of any system which limits the programmer 
for their own good.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org