On Mar 6, 2004, at 3:07 AM, Alex Martelli wrote:
If there is any possibility at all that the templates-author (a web designer separate from the programmer who codes the logic behind the templates) may want to get to such other data suppliers, "hidden" by the current mechanism, then I have to code render methods that know how to get their own data.
You could also write a render method that retrieves the root data (the page), and remembers it as IData. Then any data directive inside will use the Page as the container and call one of its data_ methods. I would consider this a horrible hack, but it will work; a path solution for directive() would be much cleaner.
I have indeed experimented, with my adapter still in place and print statements in said adapter to track when it's called; the number of occurrences has dropped from many dozens to just a couple in a typical rendering pass -- real progress, but still a LITTLE to go.
I'm not sure I understand. The function will be called exactly once per render of the associated tag. Anything else is a bug.
It seems to me that, while a syntax to explicitly access "overridden names" (of data suppliers) is helpful in some corner cases, the fundamental mechanism should still be "if a name has not been overridden it's still accessible" -- by analogy with OO programming, and also with CSS mechanics (the latter may be more accessible to my target audience -- template authors who are fundamentally web designers, rather than programmers).
In programming, the set of local names is generally not dynamic. With data, like this, it is. Think of the result of a data_users. The user names can be anything. It would be extremely dangerous to do '<span data="usernames"><span data="title">' expecting the page's data_title method to be called -- what if a user was later created with username 'title'?
new_data = IContainer(said_data).get('new_name')
Minor correction -- that is IContainer(said_data).child('new_name').
Guess I'll try to play with these concepts in my copious spare time and see if I can grasp enough of the remembrance and lookup mechanisms to implement a sandbox version of this. Any suggestions of where to focus in the nevow sources?
The policy is implemented completely in the short function "nevow.accessors.DirectiveAccessor". You could use things like context.locate(inevow.IData, depth=numDotDots+1) to search go up the context stack, or context.locate(inevow.IResource) to support an initial '/'. James