Paul Winkler wrote:
+sys.maxint
ugly python expressions in ZPT is to me a clear signal that
you need to refactor and that's a GOOD THING. And refactoring
is easy when you can just start by copy / pasting the
python expressions into a Script. If they were some
new-fangled if: then: else: syntax
Lennart Regebro wrote at 2003-3-7 15:57 +0100:
1. Python is kept as is.
2. To support one-line if-else in attributes in ZPT, the python
expressions used in ZPT imports an extra method. This method can be
called whetever people want it toi be called, but for claritys sake lets
call it
On Fri, Mar 07, 2003 at 07:33:44AM +0100, Joachim Werner wrote:
If I understood the intentions of ZPT right one of the ideas was to get
rid of too much application logic in the template. But currently ZPT
seems to be extended to become very similiar in functionality to DTML.
I'd prefer to
Steve Alexander wrote:
This is possible. But, the problem remains that both a and b (in your
example above) are evaluated.
I don't see the problem with that, unless a or b actually do stuff, and
modify stuff, and if it does, in ZPT it should then be put into a
script, since the template
Evan Simpson wrote:
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not
(Tested with
div tal:replace=if:options/x then:string:yes else:string:no)
There are an awful lot of colons in there :-)
Here's an off-the-wall idea:
div tal:replace=talif
tal:if=options/x
tal:true=string:yes
tal:false=string:no
This looks better as a tal:tag
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard. Here's a
On Tue, Mar 04, 2003 at 03:21:57PM -0600, Evan Simpson wrote:
Is this worth a robust implementation, ZPT folks?
maybe, but i'd rather first wait and see how the PEP goes.
it would suck to have to constantly deal with two totally
different flavors of ternary.
--
Paul Winkler
