This patch is great. I have always been a little confused as to why the TMPL_PATH used some type of prepending logic. I think this patch adds synergy to the two module's relationship.
> Here's a patch that sets TMPL_PATH using the HTML::Template path option > rather than prepending it using a string. This removes the restriction > that all paths must end in $ENV{IFS}. Also, it allows the TMPL_PATH > setting to coexist with other potential search paths for templates > (i.e. $ENV{HTML_TEMPLATE_ROOT} and any path settings provided to > load_tmpl()). Is this patch against 2.3 or a previous version? > I don't think this will break any existing code but it does constitute a > change in functionality. Can anyone think of a case where this would be > the wrong behavior? Well, what is the difference? Almost none as far as I can see from HTML::Template, it seems to act about the same using 'tmpl_path( )'. My only question would be about setting an array-ref using 'tmpl_path( )' to fill the 'PATH=>' argument to 'load_tmpl( )'. Obviously, everyone loves DRY (Don't Repeat Yourself) but when I try to use the 'PATH=>' argument to give the C:A a hierarchy of template directories (component, application, server in my case) you're repeating yourself or using a global var (or some other construct you have to repeat.) In my ideal CGI::Application, we load our template path in setup( ) one time (our list of template paths) and CGI::Application / HTML::Template work out which files and from where. > The patch can be applied with "patch -p1 < path.diff" in the > CGI-Application directory. Why isn't this patch part of the main tree? Has it somehow offended someone ;) -- Cory --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]