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]
