. Now the subtemplate will be treated as part of the main template during rendering, and all variables will be shared. Cheers, Evan @ 4-am From cfox@crystalcherry.com Mon May 6 17:48:11 2002 From: cfox@crystalcherry.com (Colin Fox) Date: 06 May 2002 09:48:11 -0700 Subject: [ZPT] Passing objects In-Reply-To: <3CD6A0FB.7060206@4-am.com> References: <1020638358.2293.34.camel@elgrande> <3CD6A0FB.7060206@4-am.com> Message-ID: <1020703691.15555.37.camel@elgrande> --=-FStYEenBjRoKeQFO1ddY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-05-06 at 08:27, Evan Simpson wrote: > Colin Fox wrote: > > I had a large, complicated ZPT that I'm trying to split up. It has > > logical sections, so I'm just taking each section out and making it a > > zpt and including it with > here/subtempl"> >=20 > This is exactly what METAL is for. Most discussion of it centers on the=20 > more difficult slot-oriented page macros, but breaking out bits is quite=20 > easy. Instead of the tal:replace, you would write: >=20 >

>=20 > ...and wrap the sub-template in a

. Now= =20 > the subtemplate will be treated as part of the main template during=20 > rendering, and all variables will be shared. Thanks - that worked perfectly! I didn't realize that there was this kind of difference between sub-templates and metal macros. --=20 Colin Fox cfox@crystalcherry.com CF Consulting Inc. GPG Fingerprint: D8F0 84E7 E7CC 5C6C 9982 F1A7 A3EB 6EA3 BC97 572F --=-FStYEenBjRoKeQFO1ddY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA81rPLo+tuo7yXVy8RAk1CAJ4jOygKOORng2sAt5MHvGUITuq06gCcDzwA zgAXXyMKcFIVrCGRXBA2rzc= =Kzic -----END PGP SIGNATURE----- --=-FStYEenBjRoKeQFO1ddY-- From Boriesv.demBussche Mon May 6 17:49:30 2002 From: Boriesv.demBussche (Boriesv.demBussche) Date: Mon, 6 May 2002 18:49:30 +0200 Subject: [ZPT] ZPT, CMF, batches and accessing ZClass properties Message-ID: <3BF4BD55-6111-11D6-ADFE-003065BBE1BA@fafalter.de> Hi, it took me some time to figure it out and since I didn't notice a hint in documentation this might save some time: I used a batch like the one described in chapter "Advanced Page Templates" of the Zope Book. The source was not a SQL query, but a list of ZClasses which inherited from PortalContent and DefaultDublinCoreImpl. When I tried to access attributes of that ZClass I could access the metadata, but not any of the attributes I had put into the ZClass by myself. The solution is to put the attributes, which shall be accessible via the batch into the portal catalog. hope that helps Bories From blalor+dated+1021217540.33f531@ithacabands.org Tue May 7 16:32:18 2002 From: blalor+dated+1021217540.33f531@ithacabands.org (Brian Lalor) Date: Tue, 7 May 2002 08:32:18 -0700 (MST) Subject: [ZPT] how to access the owner of an object? Message-ID: Hey all. Sorry if this has been covered before, but I did some searching yesterday and didn't come up with anything. I'm *very* green with Zope, but like I handle most new things, I'm learning by diving in head first. I'm trying to put together something of a weblog on my Zope site. Each entry is a File object. I'm using a series of page templates to display each news entry, and I'd like to be able to say who posted the item; I intend to have each File object owned by the user who made the entry. How do I, either via Python or within the template, access the owner of the object? I don't see it as a property anywhere in the object hierarchy of the File object. Thanks, B -- Brian Lalor blalor@ithacabands.org From chrisw@nipltd.com Thu May 9 08:55:45 2002 From: chrisw@nipltd.com (Chris Withers) Date: Thu, 09 May 2002 08:55:45 +0100 Subject: [ZPT] Order of attribute execution Feature Request References: <20020508160011.2585.58622.Mailman@mail.python.org> <20020508195121.GN31103@universal-fasteners.com> Message-ID: <3CDA2B81.8105FC16@nipltd.com> Jim Penny wrote: > > 2) that is introduces some additional, fairly baroque magic in the > "order of execution of element type" definitions. I would have > preferred that they be evaulated/performed in textual order. I'd second that... where do we stick feature requests like this? cheers, Chris From dieter@handshake.de Thu May 9 19:50:12 2002 From: dieter@handshake.de (Dieter Maurer) Date: Thu, 9 May 2002 20:50:12 +0200 Subject: [ZPT] Order of attribute execution Feature Request In-Reply-To: <3CDA2B81.8105FC16@nipltd.com> References: <20020508160011.2585.58622.Mailman@mail.python.org> <20020508195121.GN31103@universal-fasteners.com> <3CDA2B81.8105FC16@nipltd.com> Message-ID: <15578.50404.799793.490371@linux.local> Chris Withers writes: > Jim Penny wrote: > > 2) that is introduces some additional, fairly baroque magic in the > > "order of execution of element type" definitions. I would have > > preferred that they be evaulated/performed in textual order. > > I'd second that... where do we stick feature requests like this? I think the order is irrelevant because the DOM considers attributes unordered. Not good to implement things against the standard model. Furthermore, changing this facet in the implementation will break lots of exiting templates. Where do we condemn feature requests like this? Dieter From klm@zope.com Thu May 9 21:07:14 2002 From: klm@zope.com (Ken Manheimer) Date: Thu, 9 May 2002 16:07:14 -0400 (EDT) Subject: [ZPT] Order of attribute execution Feature Request In-Reply-To: <15578.50404.799793.490371@linux.local> Message-ID: On Thu, 9 May 2002, Dieter Maurer wrote: > Chris Withers writes: > > Jim Penny wrote: > > > 2) that is introduces some additional, fairly baroque magic in the > > > "order of execution of element type" definitions. I would have > > > preferred that they be evaulated/performed in textual order. This is a case where i'd say "baroque" is intemperate. The documention ( http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 ) not only specifically declares the order of operations operations, but it goes on to describe the rationale behind them! Now, if you _disagree_ with the choices, and can cite cases which substantiate your reasoning, then great, file a collector issue! But calling it baroque implies that it's overelaborate and/or obscure to the informed user - neither of which seems, to me at least, to be the case. > > I'd second that... where do we stick feature requests like this? I would assume it's the Zope collector. I suppose you could add comments in the ZPT wiki, as well. If you see a glaring error, and feel it warrants stirring up a lot of attention, then post something to zope coders - but you've both been pretty vague about your complaints, i don't have the impression you are chafing from some particular error. > I think the order is irrelevant because the DOM considers > attributes unordered. Not good to implement things against the standard > model. Attributes are unordered in the traversal, but of course the processing of the resulting structure (the semantics) is up to the application! And the documentation is very clear about how the application behaves - with good motivation. > Furthermore, changing this facet in the implementation will break > lots of exiting templates. > > Where do we condemn feature requests like this? :-) I imagine whoever is responsible for PageTemplates will float a proposal for changes if they're convinced any are necessary. -- Ken klm@zope.com From gotcha@swing.be Fri May 10 09:36:00 2002 From: gotcha@swing.be (Godefroid Chapelle) Date: Fri, 10 May 2002 10:36:00 +0200 Subject: [ZPT] Re: Zope-Dev digest, Vol 1 #1682 - 11 msgs In-Reply-To: <20020510041301.27208.73860.Mailman@mail.python.org> Message-ID: <5.1.0.14.2.20020510103209.00b05850@pop.swing.be> At 06:13 10/05/2002, zope-dev-request@zope.org wrote: >'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: > > > true stuff > > false stuff > > > > >A good page template way is something like this: > > > truth > > > false > > >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: > >

tal:define="editItems python:here.getMenuItem(...)"> > >

Edit Menu Items

> > >

tal:condition="not:editItems"> > No menu items available >

> >

> > >This is something I did a lot in DTML too, setting a search result to either >a global variable, or inside of a large namescape It is maybe not clear that the above is really usable and allowed. I do not know how and where to stress that the tal: marked tags are underdocumented what a pity. I have already tried : http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx#3-44 Sorry that I am not able to explain it better... -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 From evan@4-am.com Fri May 10 18:39:32 2002 From: evan@4-am.com (Evan Simpson) Date: Fri, 10 May 2002 12:39:32 -0500 Subject: [ZPT] Stylesheet Language Message-ID: <3CDC05D4.3040204@4-am.com> Thanks to Casey Duncan, I'm now thinking hard about an extension to ZPT that I'm tentatively calling Template Style Sheet Language (pronounced "Tassle"). Much like CSS, this would allow you to write the equivalent of TAL statements out-of-line, and apply them based on tag selectors. Stylesheet sytax is much more forgiving than attribute syntax, so some of the more awkward aspects of TAL could be abandoned. For instance, we can use "=" instead of "define", and we can have multiple instances of the same kind of statement applied in whatever order we specify. String expressions could simply be quoted strings, and explicit expression types could become pseudo-functions such as "python()". A major advantage would be the ability to attach generic code to tags based on pattern matching. This also eliminates the need to add new tags in order to control scope and order of operations. Here's a complex example with made-up syntax:

Record

The interaction between TAL and TSSL could be controlled by having all TSSL statements for a tag execute before TAL on the tag, but providing a "@tal;" statement, so that the following:

...would produce:

1 2 3

...since the order of execution would be: 1) x = "1"; 2) y = "2"; 3) tal:define="z string:$x $y" 4) y = "$z 3"; 5) [z] = z; 6) content: y; For documents, such as XML with a DTD, in which an inline > >

Record

> > > > The interaction between TAL and TSSL could be controlled by having all > TSSL statements for a tag execute before TAL on the tag, but providing a > "@tal;" statement, so that the following: > > > >

> > ...would produce: > >

1 2 3

> > ...since the order of execution would be: > > 1) x = "1"; > 2) y = "2"; > 3) tal:define="z string:$x $y" > 4) y = "$z 3"; > 5) [z] = z; > 6) content: y; > > For documents, such as XML with a DTD, in which an inline I really like your ideas above. After a couple of reads it was pretty eas= y to=20 grok based on exisitng TAL idioms. =20 [snip html] > The interaction between TAL and TSSL could be controlled by having all=20 > TSSL statements for a tag execute before TAL on the tag, but providing = a=20 > "@tal;" statement, so that the following: >=20 > interesting. > For documents, such as XML with a DTD, in which an inline > > I really like your ideas above. After a couple of reads it was pretty > easy to grok based on exisitng TAL idioms. > > [snip html] > >> The interaction between TAL and TSSL could be controlled by having all >> TSSL statements for a tag execute before TAL on the tag, but providing a >> "@tal;" statement, so that the following: >> >> > > interesting. > >> For documents, such as XML with a DTD, in which an inline I like the concept. It could make a lot of things simpler. But... really, to me, not knowing CSS nor Perl extensively, the syntax used in the example above looks like CSS, Python, and Perl smashed together in a train wreck. ;-) Imagine mixing in some generated HTML, JavaScript, comments, and Python code blocks. It would be very unwieldy. Maybe we can discuss the requirements first? It sounds like what we want is server-side, stylesheet-like tag processing. That's what XSLT is good for, though a lot of us believe XSLT is too complicated to fit the same uses ZPT has. OTOH, perhaps your example is a lot like CSS. In that case, CSS has come to resemble Perl. :-) Shane From chrisw@nipltd.com Tue May 14 10:33:48 2002 From: chrisw@nipltd.com (Chris Withers) Date: Tue, 14 May 2002 05:33:48 -0400 Subject: [ZPT] CVS: Zope/lib/python/TAL/tests - test_xmlparser.py:1.4.32.1 utils.py:1.4.32.1 Message-ID: <200205140933.g4E9Xm715620@cvs.baymountain.com> Update of /cvs-repository/Zope/lib/python/TAL/tests In directory cvs.zope.org:/tmp/cvs-serv15607 Modified Files: Tag: Zope-2_5-branch test_xmlparser.py utils.py Log Message: Merge fix for dodgy test to 2.5 branch. === Zope/lib/python/TAL/tests/test_xmlparser.py 1.4 => 1.4.32.1 === else: parser.parseString(source) - self.assert_(parser.get_events() == events, parser.get_events()) + if utils.oldexpat: + while events[0][0] in ('decl', 'doctype'): + del events[0] + self.assertEquals(parser.get_events(), events) def _run_check_extra(self, source, events): self._run_check(source, events, EventCollectorExtra) === Zope/lib/python/TAL/tests/utils.py 1.4 => 1.4.32.1 === # Set skipxml to true if an XML parser could not be found. +pyexpat = None skipxml = 0 try: import pyexpat @@ -22,7 +23,22 @@ import xml.parsers.pyexpat except ImportError: skipxml = 1 + else: + pyexpat = xml.parsers.pyexpat +# Set oldexpat if the StartDoctypeDeclHandler and XmlDeclHandler are +# not supported. The tests need to know whether the events reported +# by those handlers should be expected, but need to make sure the +# right thing is returned if they are. +oldexpat = 0 +if pyexpat is not None: + p = pyexpat.ParserCreate() + # Can't use hasattr() since pyexpat supports the handler + # attributes in a broken way. + try: + p.StartDoctypeDeclHandler = None + except AttributeError: + oldexpat = 1 def run_suite(suite, outf=None, errf=None): if outf is None: From matt@zope.com Tue May 14 16:22:50 2002 From: matt@zope.com (Matthew T. Kromer) Date: Tue, 14 May 2002 11:22:50 -0400 Subject: [ZPT] CVS: Zope/lib/python/TAL/tests - test_htmltalparser.py:1.25.32.3 Message-ID: <200205141522.g4EFMoU13180@cvs.baymountain.com> Update of /cvs-repository/Zope/lib/python/TAL/tests In directory cvs.zope.org:/tmp/cvs-serv12835 Modified Files: Tag: Zope-2_5-branch test_htmltalparser.py Log Message: update test for cdata mode to include two end tags === Zope/lib/python/TAL/tests/test_htmltalparser.py 1.25.32.2 => 1.25.32.3 === def check_cdata_mode(self): - """This routine should NOT detect an error with an end tag not + """This routine should NOT detect an error with an end tag not matching the start """ + s = """""" output = [ rawtext(s), ] From matt@zope.com Tue May 14 16:24:10 2002 From: matt@zope.com (Matthew T. Kromer) Date: Tue, 14 May 2002 11:24:10 -0400 Subject: [ZPT] CVS: Releases/Zope/lib/python/TAL/tests - test_htmltalparser.py:1.28 Message-ID: <200205141524.g4EFOAu13393@cvs.baymountain.com> Update of /cvs-repository/Releases/Zope/lib/python/TAL/tests In directory cvs.zope.org:/tmp/cvs-serv13305 Modified Files: test_htmltalparser.py Log Message: Add double end tag to test cdata ignore === Releases/Zope/lib/python/TAL/tests/test_htmltalparser.py 1.27 => 1.28 === def check_cdata_mode(self): - """This routine should NOT detect an error with an end tag not + """This routine should NOT detect an error with an end tag not matching the start """ + s = """""" output = [ rawtext(s), ] From fdrake@acm.org Tue May 14 16:33:23 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 14 May 2002 11:33:23 -0400 Subject: [ZPT] CVS: Zope/lib/python/TAL - HTMLParser.py:1.21.30.2 Message-ID: <200205141533.g4EFXN115992@cvs.baymountain.com> Update of /cvs-repository/Zope/lib/python/TAL In directory cvs.zope.org:/tmp/cvs-serv15981/lib/python/TAL Modified Files: Tag: Zope-2_5-branch HTMLParser.py Log Message: Simplify code to allow multiple "false" end tags in CDATA content. === Zope/lib/python/TAL/HTMLParser.py 1.21.30.1 => 1.21.30.2 === elif endtagopen.match(rawdata, i): # = 0: - self.clear_cdata_mode() elif _contains_at(rawdata, "expr mapping to a # name-->(compiled_expr, translate) mapping for key, value in repldict.items(): - if key == 'src': - print >>sys.__stderr__, "src = %r" % value + #if key == 'src': + # print >>sys.__stderr__, "src = %r" % value repldict[key] = self.compileExpression(value), key in i18nattrs for key in i18nattrs: if key not in repldict: From fdrake@acm.org Wed May 22 20:48:39 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 22 May 2002 15:48:39 -0400 Subject: [ZPT] CVS: Zope3/lib/python/Zope/TAL - TALGenerator.py:1.52.16.3.4.5 Message-ID: <200205221948.g4MJmd704400@cvs.baymountain.com> Update of /cvs-repository/Zope3/lib/python/Zope/TAL In directory cvs.zope.org:/tmp/cvs-serv4389/lib/python/Zope/TAL Modified Files: Tag: fdrake-tal-i18n-branch TALGenerator.py Log Message: Remove some debugging prints that were commented out. Update a comment. Add back a line that was accidentally removed during the initial attempt to add I18N support -- this now passes the existing unit tests. === Zope3/lib/python/Zope/TAL/TALGenerator.py 1.52.16.3.4.4 => 1.52.16.3.4.5 === def replaceAttrs(self, attrlist, repldict): # Each entry in attrlist starts like (name, value). - # Result is (name, value, action, expr) if there is a + # Result is (name, value, action, expr, xlat) if there is a # tal:attributes entry for that attribute. Additional attrs # defined only by tal:attributes are added here. # @@ -542,7 +542,6 @@ if attrsubst or i18nattrs: if attrsubst: repldict = parseAttributeReplacements(attrsubst) - #print >>sys.__stderr__, "emitStartElement", name, `repldict` else: repldict = {} if i18nattrs: @@ -552,8 +551,6 @@ # Convert repldict's name-->expr mapping to a # name-->(compiled_expr, translate) mapping for key, value in repldict.items(): - #if key == 'src': - # print >>sys.__stderr__, "src = %r" % value repldict[key] = self.compileExpression(value), key in i18nattrs for key in i18nattrs: if key not in repldict: @@ -562,6 +559,7 @@ repldict = {} if replace: todo["repldict"] = repldict + repldict = {} self.emitStartTag(name, self.replaceAttrs(attrlist, repldict), isend) if optTag: self.pushProgram() From chrisw@nipltd.com Thu May 23 12:53:37 2002 From: chrisw@nipltd.com (Chris Withers) Date: Thu, 23 May 2002 12:53:37 +0100 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT References: <20020522213130.GA7312@dman.ddts.net> Message-ID: <3CECD841.C556C521@nipltd.com> dman wrote: > > 1) ZPT doesn't expand TAL statements inside an HTML comment If that's true, that strikes me as incorrect... cheers, Chris From fdrake@acm.org Thu May 23 14:17:56 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 May 2002 09:17:56 -0400 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT In-Reply-To: <3CECD841.C556C521@nipltd.com> References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> Message-ID: <15596.60420.900317.882778@grendel.zope.com> dman wrote: > 1) ZPT doesn't expand TAL statements inside an HTML comment Chris Withers writes: > If that's true, that strikes me as incorrect... Chris, What makes you think that? Why would something *inside* a comment get expanded? I'd be very surprised myself. Is it simply that DTML does it differently, or do you think there's a functional problem with not expanding commented-out TAL/METAL constructs? Should it not be possible to include comments about TAL constructs (with examples) in page templates? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From chrisw@nipltd.com Thu May 23 15:01:18 2002 From: chrisw@nipltd.com (Chris Withers) Date: Thu, 23 May 2002 15:01:18 +0100 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> <15596.60420.900317.882778@grendel.zope.com> Message-ID: <3CECF62E.829ABD32@nipltd.com> Hi Fred :-) "Fred L. Drake, Jr." wrote: > > What makes you think that? Why would something *inside* a comment get > expanded? I'd be very surprised myself. Well, comments are sent to browsers, so are their contents. For me, that makes them fair game for interpolation. Who knows? Maybe you want some debugging: ...which you don't want to be visible for users? > Is it simply that DTML does it differently, or do you think there's a > functional problem with not expanding commented-out TAL/METAL > constructs? Should it not be possible to include comments about TAL > constructs (with examples) in page templates? Well, there's two things that I guess are getting mixed here? HTML comments - which I think should be expanded TAL/METAL comments - which shouldn't be expanded. I usually do the latter as: This code stinks, I should fix it some time ;-) cheers, Chris From jim@zope.com Thu May 23 19:01:23 2002 From: jim@zope.com (Jim Fulton) Date: Thu, 23 May 2002 14:01:23 -0400 Subject: [ZPT] CVS: Zope3/lib/python/Zope/TAL - TALInterpreter.py:1.63.10.7 Message-ID: <200205231801.g4NI1NI28932@cvs.baymountain.com> Update of /cvs-repository/Zope3/lib/python/Zope/TAL In directory cvs.zope.org:/tmp/cvs-serv26429/lib/python/Zope/TAL Modified Files: Tag: Zope-3x-branch TALInterpreter.py Log Message: This all started with wanting to be able to use url;view in a ZPT path. :) That lead me to: - Massive traversal refactoring. Namespace handling is now centralized in Zope.App.Traversing. - ZPT refactoring, including some renaming that touches pretty much everything. :) - The application specific ZPT support was moved into Zope.App.PageTemplate. - To get page template files (for use in views): from Zope.App.PageTemplate import ViewPageTemplateFile - Fixed up security so that ZPT expressions only have access to safe builtins and so that modules namespace does imports safely. - Got ZPTPage working! - renaming url to absolute_url and got absolute_url to work in paths. - Cleaned up the (as yet unused) RestrictedInterpreter module in Zope.Security. In particular, changed to use a separate RestrictedBuiltins module. === Zope3/lib/python/Zope/TAL/TALInterpreter.py 1.63.10.6 => 1.63.10.7 === self.program = program self.macros = macros - self.engine = engine + self.engine = engine # Execution engine (aka context) self.Default = engine.getDefault() self.stream = stream or sys.stdout self._stream_write = self.stream.write @@ -446,6 +446,16 @@ else: self.insertXMLStructure(text, repldict) bytecode_handlers["insertStructure"] = do_insertStructure + + +# XXX There is a bug in the dance between TALInterpreter and TALES. +# TALInterpreter expects contexts to also be engines. When someone +# inserts structure, the structure can, apparently have TAL, because +# the TAL compiler is used. If there was TAL, it would try to use the +# engine, which is a context, to compile expressions found. The TALES +# context is not a compiler. Is this a YAGNI? + + def insertHTMLStructure(self, text, repldict): from HTMLTALParser import HTMLTALParser From fdrake@acm.org Thu May 23 22:47:04 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 May 2002 17:47:04 -0400 Subject: [ZPT] why is default false? Message-ID: <15597.25432.285248.121317@grendel.zope.com> Does anyone remember why default is a false value? It should be possible to conditionally set an attribute using something like: ... I'm sure there was a specific reason for it to be false, but I sure don't remember what, and can't find it in the old project Wiki. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From dman@dman.ddts.net Thu May 23 23:03:39 2002 From: dman@dman.ddts.net (dman) Date: Thu, 23 May 2002 17:03:39 -0500 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT In-Reply-To: <3CECF62E.829ABD32@nipltd.com> References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> <15596.60420.900317.882778@grendel.zope.com> <3CECF62E.829ABD32@nipltd.com> Message-ID: <20020523220339.GA17117@dman.ddts.net> --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 23, 2002 at 03:01:18PM +0100, Chris Withers wrote: | Hi Fred :-) |=20 | "Fred L. Drake, Jr." wrote: | >=20 | > What makes you think that? Why would something *inside* a comment get | > expanded? I'd be very surprised myself. I wasn't terribly surprised by this, but I agree with Chris wrt to how it should behave. | Well, comments are sent to browsers, so are their contents. For me, | that makes them fair game for interpolation. |=20 | Who knows? Maybe you want some debugging: |=20 | |=20 | ...which you don't want to be visible for users? This is precisely what I was trying to do :-). | > Is it simply that DTML does it differently, or do you think there's a | > functional problem with not expanding commented-out TAL/METAL | > constructs? Should it not be possible to include comments about TAL | > constructs (with examples) in page templates? |=20 | Well, there's two things that I guess are getting mixed here? |=20 | HTML comments - which I think should be expanded |=20 | TAL/METAL comments - which shouldn't be expanded. |=20 | I usually do the latter as: |=20 | | This code stinks, I should fix it some time ;-) | I didn't know about the "tal:comment" tag. =20 -D --=20 After you install Microsoft Windows XP, you have the option to create user accounts. If you create user accounts, by default, they will have an account type of administrator with no password. -- bugtraq =20 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjztZzsACgkQO8l8XBKTpRTZxQCeKqzIiK3/K0iBvwG7Lh3K2qUY KFgAn2b53vmHgUShXTcNA42s/saErirt =Umm/ -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From fdrake@acm.org Thu May 23 22:58:06 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 May 2002 17:58:06 -0400 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT In-Reply-To: <20020523220339.GA17117@dman.ddts.net> References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> <15596.60420.900317.882778@grendel.zope.com> <3CECF62E.829ABD32@nipltd.com> <20020523220339.GA17117@dman.ddts.net> Message-ID: <15597.26094.126533.620538@grendel.zope.com> dman writes: > | > | This code stinks, I should fix it some time ;-) > | > > I didn't know about the "tal:comment" tag. Read the example carefully -- there isn't a tal:comment element defined by TAL; he's relying on the behavior of condition="", and probably made a typo and meant tal:condition="". -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry@wooz.org Thu May 23 22:58:46 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Thu, 23 May 2002 17:58:46 -0400 Subject: [ZPT] Re: why is default false? References: <15597.25432.285248.121317@grendel.zope.com> Message-ID: <15597.26134.447518.337706@anthem.wooz.org> I'll point out that I was playing around with the Zope Book's section on ZPT and I tried to write this: -------------------- snip snip -------------------- ...

blah

-------------------- snip snip -------------------- This fails to DWIM because the Python expression in the tal:attributes always evaluates to nothing. /That's/ because default is false. :( So I ended up with the following: -------------------- snip snip --------------------

blah

-------------------- snip snip -------------------- which works, but which I don't like . Changing Default to a true value (in lib/python/TAL/DummyEngine.py and Products/PageTemplates/TALES.py) sees to do what I want, and doesn't cause failures in the test suite. -Barry From evan@4-am.com Thu May 23 23:58:58 2002 From: evan@4-am.com (Evan Simpson) Date: Thu, 23 May 2002 17:58:58 -0500 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> <15596.60420.900317.882778@grendel.zope.com> <3CECF62E.829ABD32@nipltd.com> <20020523220339.GA17117@dman.ddts.net> <15597.26094.126533.620538@grendel.zope.com> Message-ID: <3CED7432.9020901@4-am.com> Fred L. Drake, Jr. wrote: > dman writes: > > | > > | This code stinks, I should fix it some time ;-) > > | > > > > I didn't know about the "tal:comment" tag. > > Read the example carefully -- there isn't a tal:comment element > defined by TAL; he's relying on the behavior of condition="", and > probably made a typo and meant tal:condition="". True, the condition="" does the work, but it's fine as written. He's taking advantage of the fact that TAL will treat attributes of any tag in the 'tal' namespace as implicitly belonging to the namespace. If your favorite tools tolerate it, you can therefore write stuff like: ...(much text omitted)...

Widget #42 is called Foo ...and the made-up tag name acts as a sort of mini-comment. It can certainly help at the end of a set of nested blocks to see "" instead of "

The Message

PythonLabs at Zope Corporation From barry@wooz.org Fri May 24 16:59:05 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Fri, 24 May 2002 11:59:05 -0400 Subject: [ZPT] Re: why is default false? References: <15597.25432.285248.121317@grendel.zope.com> <15597.26134.447518.337706@anthem.wooz.org> <15598.25182.652500.336282@grendel.zope.com> Message-ID: <15598.25417.755297.431934@anthem.wooz.org> >>>>> "Fred" == Fred L Drake, Jr writes: >> Changing Default to a true value (in >> lib/python/TAL/DummyEngine.py and >> Products/PageTemplates/TALES.py) sees to do what I want, and >> doesn't cause failures in the test suite. Fred> These changes have now been checked in for both the Zope 2 Fred> trunk and Zope 3. Cool! Thanks Fred. -Barry From fdrake@acm.org Fri May 24 17:26:53 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 24 May 2002 12:26:53 -0400 Subject: [ZPT] Re: [Zope] returning an HTML comment from ZPT In-Reply-To: <3CEDFF8C.EE380FD8@nipltd.com> References: <20020522213130.GA7312@dman.ddts.net> <3CECD841.C556C521@nipltd.com> <15596.60420.900317.882778@grendel.zope.com> <3CECF62E.829ABD32@nipltd.com> <20020523220339.GA17117@dman.ddts.net> <15597.26094.126533.620538@grendel.zope.com> <3CEDFF8C.EE380FD8@nipltd.com> Message-ID: <15598.27085.880796.89940@grendel.zope.com> Chris Withers writes: > No, I didn't, check the parser you wrote ;-) Gosh, Chris, that was just *ages* ago! Can't we ignore all code more than a month old? ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mlilly@inkwellmedia.net Mon May 27 22:39:09 2002 From: mlilly@inkwellmedia.net (Mark A. Lilly) Date: Mon, 27 May 2002 14:39:09 -0700 Subject: [ZPT] how to eliminate redundancy in forms?? Message-ID: <009101c205c6$ef0ec020$0201a8c0@lala> Hi, I have an HTML form for adding tasks. I want to use the same form for editing existing tasks. I am attempting to avoid having two INPUT elements --one for adding and one for editing. So i have this code: The task variable is populated by returning the 0'th instance from a ZCatalog Collection based on task_id. If it is an Add (hence there is no task to find in the Catalog), i return from the getTask() script an empty list. The tal:condition checks to see if task/task_name exists. If it doesn't, i want to set the value of the input to the words 'Add Task'. Problem is, this doesn't work. The task.task_name inside the python test function fails on the Add, because there is no task instance with a field called task_name --i get an "AttributeError on task_name". It works when there is a task returned. Question: how do i set this up? I want only one which is reused for adding/editing. Otherwise, i have to duplicate tons of code. Suggestions? Thanks, mark From matt@zigg.com Wed May 29 20:45:54 2002 From: matt@zigg.com (Matt Behrens) Date: Wed, 29 May 2002 15:45:54 -0400 Subject: [ZPT] CVS: Zope/lib/python/TAL - DummyEngine.py:1.30.18.1 Message-ID: <200205291945.g4TJjse19492@cvs.baymountain.com> Update of /cvs-repository/Zope/lib/python/TAL In directory cvs.zope.org:/tmp/cvs-serv18366/lib/python/TAL Modified Files: Tag: zigg_unix-install-control-config-branch DummyEngine.py Log Message: Merge in HEAD (except setup.py... gotta chat about that one) :-) === Zope/lib/python/TAL/DummyEngine.py 1.30 => 1.30.18.1 === from TALDefs import NAME_RE, TALESError, ErrorInfo -Default = [] +class Default: + pass +Default = Default() name_match = re.compile(r"(?s)(%s):(.*)\Z" % NAME_RE).match From matt@zigg.com Wed May 29 20:45:52 2002 From: matt@zigg.com (Matt Behrens) Date: Wed, 29 May 2002 15:45:52 -0400 Subject: [ZPT] CVS: Zope/lib/python/Products/PageTemplates - TALES.py:1.29.18.1 ZopePageTemplate.py:1.38.10.1 Message-ID: <200205291945.g4TJjqi19466@cvs.baymountain.com> Update of /cvs-repository/Zope/lib/python/Products/PageTemplates In directory cvs.zope.org:/tmp/cvs-serv18366/lib/python/Products/PageTemplates Modified Files: Tag: zigg_unix-install-control-config-branch TALES.py ZopePageTemplate.py Log Message: Merge in HEAD (except setup.py... gotta chat about that one) :-) === Zope/lib/python/Products/PageTemplates/TALES.py 1.29 => 1.29.18.1 === class Default: '''Retain Default''' - def __nonzero__(self): - return 0 Default = Default() _marker = [] === Zope/lib/python/Products/PageTemplates/ZopePageTemplate.py 1.38 => 1.38.10.1 === dtpref_cols='50', dtpref_rows='20'): """Change editing preferences.""" + # The

can have dimensions expressed in percentages;
+        # strip the percent sign so int() below won't fail
+        if dtpref_cols[-1:] == "%":
+            dtpref_cols = dtpref_cols[:-1] or '50'
+        if dtpref_rows[-1:] == "%":
+            dtpref_rows = dtpref_rows[:-1] or '20'
         szchh = {'Taller': 1, 'Shorter': -1, None: 0}
         szchw = {'Wider': 5, 'Narrower': -5, None: 0}
         try: rows = int(height)

From luislavena@hotmail.com  Thu May 30 05:58:11 2002
From: luislavena@hotmail.com (Luis Lavena)
Date: Thu, 30 May 2002 01:58:11 -0300
Subject: [ZPT] using tal:attributes with <option> select and ZSQL.
Message-ID: <OE58jRpdO7vRfOYw03W00004bb8@hotmail.com>

Hello, some comparing isn't working, been trying tis a few ours and can't
get it to work, have checked and compared the code with other working
tal:attributes, but didn't work...

here is the code snippet:

<td>
                <select class="marcotxt"
name="params.idgrillasenales:int:record" size="1"
tal:condition="listacanales">
                  <tal:dummy tal:repeat="item listacanales">
                  <option value="1" tal:attributes="selected
python:item.idgrillasenales == params['idgrillasenales'];value
item/idgrillasenales" tal:content="item/nombrecanal">Canal
                  UNO</option>
                  </tal:dummy>
                </select>
              </td>

I have been trying to use tal:repeat to fill a <select> with options, based
on that the value of each option will be item.idgrillasenales and the
content of it will be item.nombrecanal.

Until that, the add page everything works Ok, but the problem raises on the
modify page, where is supposed that the list will pre-select the already
stored and choosed value, but it didn't.

have tried:

tal:attributes="select python:path('item/idgrillasenales') ==
path('params/idgrillasenales')"
tal:attributes="select python:item['idgrillasenales'] ==
params['idgrillasenales']"

but don't work either.

listacanales is a zsqlmethod, and params is a dict returned from a PyScript
which parses the current record info.

Any ideas?

Thanks in advance,

Luis Lavena

From Geir B�kholt <geirh@funcom.com>  Thu May 30 08:51:57 2002
From: Geir B�kholt <geirh@funcom.com> (Geir B�kholt)
Date: Thu, 30 May 2002 09:51:57 +0200
Subject: [ZPT] using tal:attributes with <option> select and ZSQL.
In-Reply-To: <OE58jRpdO7vRfOYw03W00004bb8@hotmail.com>
References: <OE58jRpdO7vRfOYw03W00004bb8@hotmail.com>
Message-ID: <1391282161270.20020530095157@funcom.com>

on or about, Thursday, May 30, 2002, we have reason to believe that
Luis Lavena wrote something along the lines of :

LL> Hello, some comparing isn't working, been trying tis a few ours and can=
't
LL> get it to work, have checked and compared the code with other working
LL> tal:attributes, but didn't work...

[snip]

LL> have tried:

LL> tal:attributes=3D"select python:path('item/idgrillasenales') =3D=3D
LL> path('params/idgrillasenales')"
LL> tal:attributes=3D"select python:item['idgrillasenales'] =3D=3D
LL> params['idgrillasenales']"

LL> but don't work either.

don't work in which way =3F
Do you get an error , or just no selected options.

LL> listacanales is a zsqlmethod, and params is a dict returned from a PySc=
ript
LL> which parses the current record info.

- if i assume you just get no selected options:

perhaps this could work =3F
tal:attributes=3D"selected python:item.idgrillasenales =3D=3D params['idgri=
llasenales']"

if i run into unexpected behaviour when doing comparizations like this
, i try to print both variables being compared in the value of the
select , so that it is simple to see the problem:

tal:attributes:value=3D"string:${item/idgrillasenales}/${params/idgrillasen=
ales}"

also make sure both items being compared are of the same type.. Much
frustration can be had by trying to compare integers and strings:

tal:attributes=3D"selected python:int(item.idgrillasenales) =3D=3D
int(params['idgrillasenales'])"

--=20
Geir B=E6kholt                      web-developer
geirh@funcom.com             funcom oslo | webdev-team