[Zope-dev] Re: TALES idea: tuple unpacking

[Paul Winkler]

On Wed, Jul 23, 2003 at 05:15:48PM -0400, Shane Hathaway wrote:
> Paul Winkler wrote:
> >On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
> >
> >>There are those that consider using python: expressions in ZPT should
> >>be discouraged, primarily because it's yet another syntax for a web
> >>developer to learn.
> >>
> >>I'm not necessarily one of them, but I am sympathetic with that
> >>reasoning.
> 
> That's not my reasoning either. :-)
> 
> My feeling is that you should avoid mixing syntaxes in a single 
> document.  The more syntaxes you mix, the more perfection you require of 
> developers.

Ah. yes, i think there's something to that.

> Take the following code:
> 
> <pre tal:content="python: text.replace('\\n', '<br /')" />
> 
> This code has at least four errors (one XML, one HTML, one ZPT, one 
> Python--can you spot them?),

heheh, good example... took me a while to find 4 :-)

>but it will work anyway without complaint. 
>  This is hard to debug because it requires complete understanding and 
> perfect spelling of four languages at once: XML, ZPT, HTML, and Python.

yeah, that sucks. Maybe I'm just upset that you want to remove my
favorite of the four. :-)  Given the context, of course, python is 
the only one that's a candidate for removal from the template.

> I wholeheartedly agree that newcomers should learn Python as well as 
> ZPT, but there should be a clean separation of the two.

I think I'd have to try rewriting some of my complex templates with 
no python expressions whatsoever before I'd know if I agree with you.

> I have a slightly different concern.  You're concerned that people will 
> use path expressions when they could use Python expressions.  I'm 
> concerned that people will use *any* kind of complicated expressions 
> instead of Python code blocks.  To me, the choice between path 
> expression and Python expression isn't very meaningful; either way I'm 
> putting logic in a template, and if it's too complicated, it doesn't 
> belong there.  The better goal is to move complicated logic out of 
> templates and into Python code blocks, don't you think?

Yes, I do. But I've found that when I write templates, there is a typical
progression:

 1. Start with a simple path expression:

     request/foo

 2. Whoops, now I need to do something a bit more involved:

     python:here.do_something(request.foo, here.something_else, ...)

 3. ugh, it's getting too long - 
    move the python expression into foo_script and change
    the tales expression to:

     here/foo_script

The current proposals aim to reduce the need to go to step 2.
Nice goal - it is true much of my ugliest template code has
been caused by pushing 2 too far. But I find that going from step 2 
to step 3 is so easy that I don't mind refactoring and it's
usually very quick.

However... it should be noted that step 2 can be completely bypassed.
There's nothing preventing me from going from 1 directly to 3.
I only use 2 because it's there :-)  Thinking more about it, it
occurs to me that python expressions in TALES provide a huge hole
in the separation of presentation from logic. 

Consider the psychological factor - python expressions are 
convenient sometimes. Many of us do not have the willpower to 
resist. :-)  Adding features to TALES doesn't change this, it 
gives us another brand of rope to hang ourselves with.

> I know of two ways to avoid writing complicated expressions in templates:
> 
> 1. Move complicated expressions into Python code blocks.
> 
> 2. Provide a simpler equivalent for complicated expressions.

what about:

 0. make complicated expressions illegal

I'm only half-joking. Why are we arguing for adding more stuff to TALES
rather than removing python expressions? Can someone think of an 
example that *requires* a python expression and can't be done with a 
path expression and a Script? If so, is it solvable by improving
the interaction between templates and Scripts instead of adding
features to Templates?

I seriously doubt this would meet community approval for zope 2,
there's too much existing code that would break.  but maybe it should be 
considered (if it hasn't been already) for zope 3.

> Prefixes in the middle of path expressions attacks #2.

hm. i guess i would agree if I thought any of the proposals actually 
are significantly simpler!  Let's stick to your first point - 
python in ZPT is undesirable because ZPT already makes you deal with
3 languages (assuming the output is html and not just XML).

But since we are stuck with 3 languages in one file,
why do we want to make one of them more complex than it already is? 
And since we know that we very often need a fourth language in another file, 
why not leverage that capability to keep the template super-simple?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's PORN STAR OMEGA!
(random hero from isometric.spaceninja.com)