It seems to me that this might be best served using the strategy design pattern pattern.
eg create a few plug-ins objects that get loaded based on explicitly stating the strategy to be used to interpret INCLUDE_PATH. The objects would all have a single method that takes a file plus the include path and interprets them both together to return the relevant data. But what's inside the object is what changes things. Strategy design pattern helps when you have a common well-defined task (ie traversing include path) but there are many ways of doing it. eg you just mentioned - and +, but I could also think that depth first and breadth first are also mechanisms. Someone may want to write their own that deliberately skips certain directory suffix/prefix names. or how about based on locale directories etc... Anyway, if it were just as simple as +, - I would say go for including it in the main code base but if it turns out that there are a lot of different ways of doing the including then I would suggest looking at the strategy pattern to implement this. At 10:34 PM 10/30/2001, Andy Wardley wrote: >On Tue, Oct 30, 2001 at 08:56:54AM -0500, darren chamberlain wrote: > > > Doesn't Apache::Template do this too? > > > > I submitted a patch a few weeks (months?) back that added that > > fucntionality. > >Yes, sorry, I think I'm sitting on it. > >I like the idea of being able to search up and down the INCLUDE_PATH in >various different ways. In fact, I like it so much, I want to try and >fit it into the TT core (e.g. Template::Provider). That way, we all >get to use it and it becomes available for free in Apache::Template. > >I've been reading over Chuck's email, and also Darren's email from back >in June when he first raised this issue (sorry it's taken so long for >me to get around to it). > >Darren said: > > * For historical reasons, our HTML developers require that > files that are INCLUDEd or PROCESSed be searched for in a > tree-walking manner, starting with the directory of > $r->filename and ascending to /. This has the effect of > including the closest copy of files declared in TT2PreProcess > and TT2PostProcess, which works out very well for using a > single set of header and footer files for an entire site, > while having section specific navigation bars and features > that get included without having to specify paths and the > like. > >Chuck said: > > * In order to do this, each template remembers where it was > loaded from, and sets its working directory to that directory. > Templates loaded without any leading path qualifiers, which > normally causes INCLUDE_PATH to be searched in TT2 are searched > for as if INCLUDE_PATH were the current directory and every > directory above it (up to an APP_ROOT config setting that is. > Also, templates loaded with an absolute path are treated as > relative to APP_ROOT, making the whole tree relocatable. > >I was thinking about allowing certain modifier metacharacters on the >end of an INCLUDE_PATH element which activate this kind of behaviour. >For example, > > INCLUDE_PATH = /foo:/bar+ > >If the main template is 'abc/def/ghi.tt2' which gets resolved as >'/foo/abc/def/ghi.tt2' and includes a directive like [% INCLUDE xyz %] >then it should look for: > > /foo/xyz > /bar/xyz > /bar/abc/xyz > /bar/abc/def/xyz > >In other words, the '+' indicates that the provider should walk down >from /bar adding elements of the main template's path until a match >is found. > >To walk up the path, you would use '-'. So for the same, example as >above, the INCLUDE_PATH > > INCLUDE_PATH = /foo:/bar- > >would try to find > > /foo/xyz > /bar/abc/def/xyz > /bar/abc/xyz > /bar/xyz > >Note that in both cases, the provider doesn't ever search above the >root of the INCLUDE_PATH element (e.g. /foo or /bar). I think it's >important that we keep it that way and limit such use to the ABSOLUTE >and RELATIVE options. > >I'm slightly concerned that this might be a bit cryptic and may cause >problems on the offchance that someone really does have a '+' or '-' >at the end of their path. Other suggestions welcome. > >Another thought is that it would be nice for the provider/document to >be able to find all possible matches so that we can introduce the >concept of pseudo-inheritance between template components. Currently, >[% component %] always gives the Template::Document for the current >template component, and so [% component.super %] (or something like that) >could be the next template that would have matched after this one >(e.g. the template of the same name one of the parent directories). > >Thoughts? Comments? Suggestions? > > >A > > > >_______________________________________________ >templates mailing list >[EMAIL PROTECTED] >http://www.template-toolkit.org/mailman/listinfo/templates __________________________________________________ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
