> 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.
The principal reason most people want to vary the include path is to allow for overriding based on context, which enables things like co-branding or varying the presentation for areas of your site. In the eToys setup, when displaying things in the book section of the site we would set the include path so that it would do a depth-first search of something like /templates/products/book/partner_id/, allowing us to override the generic header with a header specific to the book section, and the generic book header with a co-branded version. (Okay, we never used the co-branding stuff, but the groundwork was all there.) This path was set up by the mod_perl handler, which would decide what the current context was. In other words, the include path contains information about the context, which individual templates shouldn't be allowed to mess up. To me, what you're doing sounds like a symptom of doing things in templates that you should be doing in your perl program. Yes, it is how SSI includes work, but that's because they didn't have handy concepts like an include path. > 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). I've never been happy with Mason's inheritance stuff. It's not intuitive enough, and doesn't allow for the kind of simple overrides that I mentioned above. Why would you need to explicitly specify a parent? Why wouldn't it be obvious from your directory structure? Embperl's inheritance system (which works like what I described) makes more sense to the average HTML coder. Knowing as little as I do about your application, what I'm saying may be completely off the mark. Take my advice with a pound of salt. It just sounds like you may be going to a lot of trouble to support things that could be handled in a simpler way. - Perrin
