> You did all of that just to get TT to climb the directory tree when > resolving template calls? Why don't you just vary the include path > on each > request? TT already knows how to climb the include path.
Because it varies the include path per-document, not per-request. If /foo/bar/blah.tmpl includes a.tmpl, it will search /foo/bar, /foo/bar, /foo, and / for a.tmpl. When it finds it, it does not change the current directory being searched. If a.tmpl includes /foo/bar/baz/b.tmpl, it does not do this search (this search behavior only happens for relative paths), but if b.tmpl includes c.tmpl, it searches /foo/bar/baz, then /foo/bar, then /foo, then /. When control goes back to a.tmpl, it goes back to searching the same directories that blah.tmpl would have been searching. And that's just a start -- documents will be able to override this behavior using META items (e.g. [% META parent = /path/to/doc %], more mason-like behavior). This is complex searching behavior I'm talking about, but it all boils down to being stateful, controlled largely by properties of the document (but in general, any state, which the context would seem to be responsible for maintaining or at least delegating). In order to do this, the provider has to be made aware of the current state, and the context has to be aware of the current document. Thus my questions about the best approach for this. I don't actually have any intention of hacking the existing INCLUDE_PATH mechanism to do this, and never did, it was just an analogy. __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com
