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
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,
> 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?
Look! Up in the sky! It's TWITTY-PHYSICIAN!
(random hero from isometric.spaceninja.com)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -