Python vs PHP

[Alex Martelli]

Ian Bicking <ianb at colorstudy.com> wrote:
   ...
> 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

In this corner, one or more excellent programmers with the typical
aesthetic and artistic sense of the average programmer: lousy-minus.

In the other corner, one or more excellent graphics designers who
specialize in producing wonderful web pages mixing HTML, style sheets,
graphics, maybe a drop of javascripts for effects and usability -- with
the typical program-design ability of the average artist: lousy-minus.

How do we get great web pages out of this team?

I don't want the HTML, CSS etc to come out of the programmers' work: it
would look bad and be unusable.

I don't want any program design to come out of the artists' work: it
would be crufty and unmaintainable.

What I want is: let the programmers program, and the artists write HTML,
CSS, and the like.

Moreover, in the typical business scenario, the visuals and exact
effects of the pages will be endlessly tweaked and tinkered with,
because that's what clients, marketeers and focus on.  The program must
be able to remain stable and just reflect to the browser the current
state of the tweaking and tinkering (ideally without needing to stop and
restart the program, to help the poor artists' lives).

Nevow helps a _lot_ with this scenario.  The programmers (with all due
consultation and customer involvement, to be sure) define all the logic
and implement it in Python; _NOT_ in .HTML files, but quite away from
them.  What the HTML files need to contain is the mention of the data
sources and renderers that are to be used, out of the 'palette' supplied
by the Python code (nevow:data and nevow:render attributes, data_this
and render_that methods in Python) and markers to identify 'this is the
spot' for the renderer's benefit.

The programmers can develop all logic (with lousy looks) with their own
ugly and nastly HTML files.  The artists "just" need to write beautiful,
corporate-standards-du-jour compliant HTML, CSS, etc, with the
appropriate choice of data sources and renderers and 'this is the spot'
markup.  Each time a template file is modified, nevow will know to
reload and reparse it next time it's used, which is handy for tweaking
and tinkering purposes.

Nevow has a lot of stuff I haven't needed yet, such as most of stan (can
generate HTML w/o any templating), live-page functionality (use Python
instead of Javascript... but with a round trip every time... well, maybe
on a LAN...), freeform/formless -- maybe I won't ever need it, and it
does not necessarily fit within the above scenario all that well.  But
the templating per se seems to me to be just what I need in the above.


> 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.

Right, business vs presentation logic separation is done 'behind' the
template, in Python.

> 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.

Bingo: the fewer the better.


> 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

And nevow lets some people (graphics artists specializing in webpages)
work primarily in HTML/CSS/maybe javascript (sigh) for effects &c.
That's exactly how I like it...

> 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.

I believe it's not -- by design.  If program logic must be modified,
programmers (able to work in Python, not a terribly high bar btw) will
be the ones modifying it.  I like the idea.


> 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

Absolute agreement here: such mixing is a problem.  Nevow avoids it.

> 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

As long as said small bit of Python code is in a Python module, I'm fine
with that.  Normal inheritance easily lets you split that way the class
that works behind a nevow template: any data supplier or renderer which
is rich or complicated may be stashed away in a base class somewhere
else, and the actual class driving the page need only "little bits" of
overriding/wrapping or adding new simple methods.  If you only work with
graphic artists/page designers who are a little bit comfortable with
Python, they can work on retouching the easier, front-side parts, while
all the heavy and please-don't-touch parts are elsewhere and clearly
marked as such.  Other such refactorings may quite well be possible; the
"pure" programmers-on-one-side, artists-on-the-other arrangement is
surely not the only one that Nevow enables... just the one that I think
I need, and that I've seen no other templating system enable so well.

> 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.

No, in my worldview that's CSS's job.  Python code only need to emit the
table rows with alternate (CSS) class attributes.  The existing sequence
renderer supplied by nevow's infrastructure enables that, btw: write
more than one nevow:pattern="item" tags and render_sequence will render
them in round-robin style.

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

Ah, you see the guy coding the HTML/CSS/etc as "the programmer".  I
don't.  The world has even too many webpages made by programmers: it
shows.  Let's have some more made by people who know how to do pleasing
and usable graphic designs: they don't need to be programmers (at least
in the "pure" arrangement), they do need to be good artists.  Meanwhile
the programmers may have all the aesthetic sense they're famous for,
without thereby spoiling the output pages...


Alex