> A while back I posted to this list (June 6, 2001: COMPILE_DIR > and TEMPLATE_DIR) a suggestion for cutting out some of the top > level directories when saving compiled templates. This was so > if all of your include paths shared the same higher directory > structure: > > /home/useracct/var/project1/templates > /home/useracct/var/project1b/data/templates > > under the compile directory you set you'd only get > > COMPILE_DIR/project1/templates > COMPILE_DIR/project1b/data/templates > > instead of > > COMPILE_DIR/home/useracct/var/project1/templates > COMPILE_DIR/home/useracct/var/project1b/data/templates
As a simple fix, why don't you set just COMPILE_EXT and not COMPILE_DIR? Then the compiled templates will be written into the same directory as the source template? This does create some clutter in your source directories (and requires write permission), but does avoid generating orphan compiled templates if you rename any of your directories. Trimming the common part of the include paths helps solve your problem, but could still cause naming conflicts if different tt instances used the same COMPILE_DIR but different include paths. I like the idea of Randal's cache naming hook. The cache naming hook could then use things like MD5(path) plus a uniqueness check, device+inode numbers (not on winXX?), etc. As an aside, it would be a minor patch to allow COMPILE_DIR to be relative. This would mean relative to the source directory of each template, allowing you to put all the compiled templates in a sub-directory (eg: tt_cache or .tt_cache) below each source directory. This would avoid cluttering the source directory and avoid the long path names in the absolute cache. Craig
