OT Re: [Zope-DB] writing a template to test if the sql worked

[Charlie Clark]

On 2004-05-06 at 11:07:31 [+0200], Philip Kilner wrote:
> I'm interested in this statement, because it touches on something I
> don't feel I understand sufficiently.

Well, it is a little deliberately provocative. Google for "PHP is evil" and 
see some other quotes. I've come to this conclusion after what seems like age 
in web stuff. While I'm not much of a programmer myself I've had to maintain 
sites with work done by other people and maintenance is where the problems 
start. Notwithstanding Bogdan's perfectly valid point that it largely depends 
on the programmer. True, true: a good programmer will always produce good 
code whatever the language or environment and a bad programmer will pretty 
much alwas produce illegible junk. Now exactly what is good or bad, legible 
or illegible is often subjective. This puts us pretty much in the Python vs. 
perl argument where my preference is for explicit rather implicit coding 
rules.

> Sure, DTML intertwines presentation and logic - but if I develop a ZPT
> which conditionally fires python script (e.g. for form validation, or a
> database write), is that any less "in-line scripting"?

ooh, I can't see ZPT really doing either directly: surely the form's action 
would be a script? The only case I've seen is dealing with possibly empty 
result sets or needing to pre-process results for particular presentation 
needs (in columns rather than rows). But even so the important thing is that 
the ZPT *declares* everything so you stay in the same mode of speech as it 
were. Just as your PythonScript will essentially be based around variable 
checking and transformation and your SQL about storage and retrieval. 
Debugging may involve switching between them a few times and ExternalEditor 
is your friend, but the important thing is that you can focus on each bit in 
isolation.

It's anecdotal but I recently had to do some work on a PHP site and came 
across the usual mix of SQL embedded in PHP embedded in HTML. While the stuff 
I was looking at was fairly cleanly typed it was still very frustrating as I 
had to rewrite entirely for a simple change. This happens because there is 
little or no incentive to abstract in the inline scripting world whereas the 
ZPT / Script approach makes it imperative.

> I've just made a transition in what I'm curently working on from using
> scripts which call ZPTs (Which I found mightily confusing WRT to
> namespace and scope issues - e.g. where a script called a ZPT which in
> turn called a script - yuck!), to exclusively using ZPTs which call scripts.
> 
> /I/ feel as though I've now got a much more intelligible paradigm - but
> I'm not sure that it doesn't still qualify as in-line scripting ...
> although of course in any one document there is no mix of logic and
> presentation (aside from a few conditional statements).

Sounds fine to me: it is generally possible to see how things interact simply 
from the folder structure. I normally work in a similar manner although I 
normally pass forms to scripts to valid and process and get them to add 
values to the request if necessary, ie. when passing error messages as I much 
prefer this over TALES options.

However, Jim Penny made a very good case for having a PythonScript 
essentially be the index_html calling ZPTs or other objects as required this 
being a good way of preventing unpleasant or unexpected things happening. I 
can't find it locally or online, maybe he can repost it.

Charlie