On Tue, Jul 29, 2003 at 07:23:36PM -0300, Leonardo Rochael Almeida wrote:
But right now the choice between adding or not the proposed TALES extensions is a choice between having to explain what all those python concepts mean before or after the poor template guy got confused why certain things don't work as expected:
* Why must I use a tal:define="something here/getSomeObject" and later a tal:content="something/someAttribute" instead of just tal:content="here/getSomeObject/someAttribute".
you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive).
* Why does tal:content="request/form/items" don't get me the "items" object that I'm expecting
you lost me there.
In order to get to the ideal world Paul wants (and that I want too), maybe we need to restrict the things that TALES can navigate. That would mean we'd need to chose between TALES path navigating dictionary keys or attribute access, but not both.
Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']).
Also, paths would not be able to call anything in the last segment.
eh? so tal:content="here/some_method" would no longer work? I don't really understand your proposal I'm afraid.
On the other hand, we'd need to give python scripters the necessary tools, ex. before ZPT, I used to find it VERY anoying that I had to use the mapping attribute in DTML tags just because I couldn't create MyBrain objects thru python. PythonScripts should be able to generate the same kind of objects that ZCatalog and ZSQL queries generate.
Not sure what you mean. You want to wrap Brains around something other than ZSQL results? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's TWITTY-PHYSICIAN! (random hero from isometric.spaceninja.com)