Re: [Zope-dev] ZPT and 'else'
on 5/10/02 1:18 PM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened: Still, yuck. It's - for better or worse - not a valid XML way. Even XSLT does things like this: snip Well that makes this look palatable: You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Still I think the concept of TAL having some kind of 'stack' for condition results makes sense and is worth exploring... Could yield better logical constructs, and things like case statements. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
Tim Hoffman wrote: The big problem with the whole 'else' issue as I see it, is that non coders, using dreamweaver etc.. would no doubt end up with both bit's of html in their template. But that's exactly what you want! hey can then see what would happen in either case and will probabyl write better templates as a result :-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened: You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. What's so bad about that? The stack wouldn't carry over after html/html or body/body - couldn't practically more than 1000's - insignificant! You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Which would ensure / cut back on needless growth of stacks and/or global variables. Personally, I think the way Page Templates can do it (via a 'not' expression) is fine. When I used it today (and in the past), I never felt myself missing 'else', because there's not really an 'if' to begin with. Just conditions. It keeps TAL light, and lets TALES take on the lifting of how to write those conditions. Point is, it's slow and inefficient, and a clunky syntax. Reasons the whole idea of 'else' was invented in the first place. I worry, that ZPT is benchmarked 4x slower than DTML and it's becoming the standard - not a step forward. And issue like this haven't been satisfactorily resolved. I think, if it's going to have logic in there, make it sufficiently powerful and efficient. Otherwise get rid of it altogether, unapologetically, and require Python for such things ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
on 5/9/02 11:58 PM, Tim Hoffman at [EMAIL PROTECTED] scrivened: The big problem with the whole 'else' issue as I see it, is that non coders, using dreamweaver etc.. would no doubt end up with both bit's of html in their template. Don't you have that now with the kludgey 'not' construct? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
On 5/10/02 9:25 AM, Marc Lindahl [EMAIL PROTECTED] wrote:
on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened:
You would need something to close off the 'if' statement, otherwise, a
document full of 'if' statements and no 'else' ones could fill up a stack
needlessly.
What's so bad about that? The stack wouldn't carry over after html/html
or body/body - couldn't practically more than 1000's - insignificant!
Still, yuck. It's - for better or worse - not a valid XML way. Even XSLT
does things like this:
xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/
xsl:choose
xsl:when test=system-property('xsl:version') = 1.1
xsl:exciting-new-1.1-feature/
/xsl:when
xsl:otherwise
html
head
titleXSLT 1.1 required/title
/head
body
pSorry, this stylesheet requires XSLT 1.1./p
/body
/html
/xsl:otherwise
/xsl:choose
/xsl:template
/xsl:stylesheet
xsl:if can stand on its own, but to do the equivalent of else, one has to
use:
xsl:choose
xsl:when test=expression(template)/xsl:when
xsl:when test=expression(template)/xsl:when
xsl:otherwise(template)/xsl:when
/xsl:choose
But, Page Templates are not XSLT. And I thank gods for that. XSLT is
powerful, but I wouldn't be able to do the type of work I've been doing this
week with them as easily as I've been able to do them with Page Templates.
I couldn't even have done them as easily using DTML.
You would at the very least need something like:
condition
if.../if
elif.../elif
else.../else
/condition
Which would ensure / cut back on needless growth of stacks and/or global
variables.
Personally, I think the way Page Templates can do it (via a 'not'
expression) is fine. When I used it today (and in the past), I never felt
myself missing 'else', because there's not really an 'if' to begin with.
Just conditions. It keeps TAL light, and lets TALES take on the lifting of
how to write those conditions.
Point is, it's slow and inefficient, and a clunky syntax. Reasons the whole
idea of 'else' was invented in the first place. I worry, that ZPT is
benchmarked 4x slower than DTML and it's becoming the standard - not a step
forward. And issue like this haven't been satisfactorily resolved.
If speed mattered that much, we'd all still be using C and/or assembly
language. Scripting Languages have become very standard, even though
they're orders of magnitude slower than their compiled counterparts. I
don't think it would be any more worth turning Page Templates back into an
imperative programming language than it would be to turn Python into C. Or
Haskell into Python. Or J into Lisp. Or Zope into PHP. Every language
and platform has its strengths and weaknesses, and I think ZPT's strengths
more than make up for its current speed deficiencies. I spend less time
debugging and cleaning up Page Template code than I did with DTML,
particularly late-generation DTML. And the results look *much* better.
I personally can't see a way of having an else (or equivalent of
'xsl:choose') without starting to clutter up the current elegance of Page
Templates, and it has to do with the way Page Templates are designed (and
it's a design that I think is done pretty close to right). One reason being
that, since all TAL things happen on attributes (it is the 'Template
Attribute Language', and by law all XML attributes have to be quoted, you'd
end up with something like this:
div tal:choose=
h1 tal:condition=some/expressionYay!/h1
h1 class=warning tal:otherwise=Boo/h1
/div
The only way out of this is to introduce special TAL tags. And at that
point, we're back to some of the problems with DTML - 'special markup tags
and the editors the bruise them'. And at _that_ point, we're out of one of
the intended audiences of Page Templates.
I think, if it's going to have logic in there, make it sufficiently powerful
and efficient. Otherwise get rid of it altogether, unapologetically, and
require Python for such things
Another option is the XMLC route, which is painful. XMLC identified every
possible writable element with an id, and id only. Then, corresponding Java
code could refer to that ID and replace the element with something. It kept
the visual design side very clean, but the code to do the dynamic generation
could get very ugly.
Or, there's the option is to give up on templating altogether and go with
PHP style syntax, or fill up Python code with:
s += 'emNo contents available/em'
I personally think Page Templates are rather elegant and a joy to use after
five and a half years of DTML usage. I keep having to deal with other
solutions like 'tea', 'cheetah', ASP/PSP, and it's just a mess.
--
Jeffrey P Shell
www.cuemedia.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
[Zope-dev] ZPT and 'else'
On 5/9/02 7:07 PM, Tim Hoffman [EMAIL PROTECTED] wrote: Just my 2c worth, but I would like to defend order of execution of ZPT. What it does mean for me is I can guaruntee zpt commands will always be processed in a known order irrespective of where you put them in a tag, this I like ;-) Me too. Occasional alarms, no surprises. What I do miss is else clause but I think it would be probably be too hard to implement, and too much of encouragement for people to start putting more logic in the template, so on the whole it is probably best to leave it out. See ya T On Fri, 2002-05-10 at 05:15, Jim Penny wrote: My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. 'else' is tricky within the block oriented structure of anything XML-ish, because of the concept of 'well-formedness'. The 'if' statement would have to be singly wrapped, and the else block wrapped separately, looking at least somewhat awkward any way you go about it. The best I can come up with in my mind is this, in order to have the 'else' pick up on the condition expressed in its surrounding container. But, yuck: if ... true stuff else false stuff /else /if A good page template way is something like this: tal:if condition=myTalesExpression truth /tal:if tal:else condition=not:myTalesExpression false /tal:else The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div This is something I did a lot in DTML too, setting a search result to either a global variable, or inside of a large dtml-let namescape -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
Yecch! Why not: if ... True stuff /if else False stuff /else If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them Something like that? on 5/9/02 11:10 PM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened: 'else' is tricky within the block oriented structure of anything XML-ish, because of the concept of 'well-formedness'. The 'if' statement would have to be singly wrapped, and the else block wrapped separately, looking at least somewhat awkward any way you go about it. The best I can come up with in my mind is this, in order to have the 'else' pick up on the condition expressed in its surrounding container. But, yuck: if ... true stuff else false stuff /else /if A good page template way is something like this: tal:if condition=myTalesExpression truth /tal:if tal:else condition=not:myTalesExpression false /tal:else The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div This is something I did a lot in DTML too, setting a search result to either a global variable, or inside of a large dtml-let namescape ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
The big problem with the whole 'else' issue as I see it, is that non coders, using dreamweaver etc.. would no doubt end up with both bit's of html in their template. T On Fri, 2002-05-10 at 11:39, Marc Lindahl wrote: Yecch! Why not: if ... True stuff /if else False stuff /else If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them Something like that? on 5/9/02 11:10 PM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened: 'else' is tricky within the block oriented structure of anything XML-ish, because of the concept of 'well-formedness'. The 'if' statement would have to be singly wrapped, and the else block wrapped separately, looking at least somewhat awkward any way you go about it. The best I can come up with in my mind is this, in order to have the 'else' pick up on the condition expressed in its surrounding container. But, yuck: if ... true stuff else false stuff /else /if A good page template way is something like this: tal:if condition=myTalesExpression truth /tal:if tal:else condition=not:myTalesExpression false /tal:else The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div This is something I did a lot in DTML too, setting a search result to either a global variable, or inside of a large dtml-let namescape ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
On 5/9/02 9:39 PM, Marc Lindahl [EMAIL PROTECTED] wrote: Yecch! Why not: if ... True stuff /if else False stuff /else If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them Something like that? You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Which would ensure / cut back on needless growth of stacks and/or global variables. Personally, I think the way Page Templates can do it (via a 'not' expression) is fine. When I used it today (and in the past), I never felt myself missing 'else', because there's not really an 'if' to begin with. Just conditions. It keeps TAL light, and lets TALES take on the lifting of how to write those conditions. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
