Re: [Zope] Architectural decisions
I don't know of a "definitive listing" but try to have as a rule of thumb to never use getattr or hasattr in TAL. If you find yourself doing so you know you've gone to far without refactoring into python scripts. The most advanced luxury I afford myself in TAL is python:test() or python:path() You can also make it a habit to set aside Python scripts in a certain fashion just to support your TAL. You could for example name all the python scripts something like "evaluateEnvironment_4tal" and then be able to do something like this in TAL. <div tal:condition="here/evaluateEnvironment_4tal">foo bar</div> Peter Ben Last (Zope) wrote:
From: Peter Bengtsson [mailto:mail@peterbe.com] <h2 tal:content="python:path('here/%s/environment'%request['partner'])">
Beautifully elegant, Peter, thanks :) Now I shall write 100 times; "I must remember to invoke Python more often..." And thanks to Matt also for the python script reference.
Something I'm finding *slightly* annoying is the mix of Python semantics in Zope. In some places, one uses: object['attributeName'] ...and in others: getattr(object, 'attributeName') ...depending, of course, on the type of object with which one is provided. In one Python script I had, one container appeared to work the first way and another the second. ZPT seems to work it out every time. Is there a definitive listing of what things are treatable as dicts and which as objects?
ben
-- Peter Bengtsson, http://www.peterbe.com
On Mon, May 24, 2004 at 11:44:02PM +0100, Peter Bengtsson wrote:
Something I'm finding *slightly* annoying is the mix of Python semantics in Zope. In some places, one uses: object['attributeName'] ...and in others: getattr(object, 'attributeName') ...depending, of course, on the type of object with which one is provided. In one Python script I had, one container appeared to work the first way and another the second. ZPT seems to work it out every time. Is there a definitive listing of what things are treatable as dicts and which as objects?
If you're talking about ObjectManagers (Folders, Portal Folders and the like), it's good to be aware that if getattr(foofolder, 'bar') uses implicit acquisition; but foofolder['bar'] does not, it only looks in foofolder's sub-objects. -- Paul Winkler http://www.slinkp.com
Paul Winkler If you're talking about ObjectManagers (Folders, Portal Folders and the like), it's good to be aware that if getattr(foofolder, 'bar') uses implicit acquisition; but foofolder['bar'] does not, it only looks in foofolder's sub-objects. It was exactly an ObjectManager that was giving me trouble, and that explains a good hour's worth of odd behaviour I experienced yesterday! Thanks, Paul.
ben
From: Peter Bengtsson [mailto:mail@peterbe.com] I don't know of a "definitive listing" but try to have as a rule of thumb to never use getattr or hasattr in TAL. Thanks, Peter, but in that case, how do you do traversal of the general containment hierarchy to locate something whose name you have in a variable?
ben
Ben Last wrote:
From: Peter Bengtsson [mailto:mail@peterbe.com] I don't know of a "definitive listing" but try to have as a rule of thumb to never use getattr or hasattr in TAL.
Thanks, Peter, but in that case, how do you do traversal of the general containment hierarchy to locate something whose name you have in a variable?
<tal:x define="testvar string:someobjectname;" replace="here/folder/?testvar"/> Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
From: Chris Withers [mailto:chris@simplistix.co.uk] <tal:x define="testvar string:someobjectname;" replace="here/folder/?testvar"/> Wow, that's neat; saves a good many python: invocations. Thanks, Chris. As far as I can see that's not covered in any of the ZPT documentation or tutorials that I've pored through (and there seems to be nothing in the TAL Spec 1.4). Is that new, or just obscure?
ben
On Tue, 25 May 2004 16:28:14 +0100 "Ben Last" <ben@benlast.com> wrote:
From: Chris Withers [mailto:chris@simplistix.co.uk] <tal:x define="testvar string:someobjectname;" replace="here/folder/?testvar"/> Wow, that's neat; saves a good many python: invocations. Thanks, Chris. As far as I can see that's not covered in any of the ZPT documentation or tutorials that I've pored through (and there seems to be nothing in the TAL Spec 1.4). Is that new, or just obscure?
ben I might mention that ZSQL results can be stored using tal:define, as well. Here, it is not so much about avoiding python: calls, as it is about avoiding expensive calls, and/or extraneous methods. Although, I often find it increases readability, as well.
Example: <body tal:define="sqlres container/my_sql_method"> <table> <tr tal:repeat="rows sqlres"> <td tal:content="rows/name1"></td> ... </tr> </table> <p><span tal:replace="python:len(sqlres)"> rows were found.</p> </body> Jim Penny
Ben Last wrote:
Wow, that's neat; saves a good many python: invocations. Thanks, Chris. As far as I can see that's not covered in any of the ZPT documentation or tutorials that I've pored through (and there seems to be nothing in the TAL Spec 1.4). Is that new, or just obscure?
"undocumented" ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
From: Chris Withers [mailto:chris@simplistix.co.uk] <tal:x define="testvar string:someobjectname;" replace="here/folder/?testvar"/> Wow, that's neat; saves a good many python: invocations. Thanks, Chris. As far as I can see that's not covered in any of the ZPT documentation or tutorials that I've pored through (and there seems to be nothing in the TAL Spec 1.4). Is that new, or just obscure?
ben
participants (6)
-
Ben Last -
Ben Last (Zope) -
Chris Withers -
Jim Penny -
Paul Winkler -
Peter Bengtsson