Sam Tregar writes:
> > Is this patch against 2.3 or a previous version?
> Yup, 2.3.
Thanks.
> > 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( )'.
>
> Well, it's possible that some cases where load_tmpl() would have failed in
> the past will now succeed. I doubt that will cause much trouble though
> since I doubt people have code in production that can't find its
> templates! A pathological case involving intentionally failing
> load_tmpl()s and eval{} is possible...
I hope the ratio of people who have code in production that can't find it's
templates to people who use load_tmpls() in eval{} with the intention of
failing is about 1:1. Both seem of madness to me ;)
> > My only question would be about setting an array-ref using 'tmpl_path(
> > )' to fill the 'PATH=>' argument to 'load_tmpl( )'.
>
> That might be useful, although it's just as easy to do:
>
> $self->load_template('foo.tmpl', path => ['bar/baz', '/bif/bing']);
>
> The patch goes way out of its way to make sure this still works, even if
> you also set TMPL_PATH.
That's good to hear. However (forgive my repeating) :
> $self->load_template('foo.tmpl', path => ['bar/baz', '/bif/bing']);
or> $self->load_template('foo.tmpl', path => @tmpl_dirs);
I currently use the 'or>' method. I think it is less than perfect, for a
couple of reasons: I'm repeating myself, I'm using some type of global
(since the population of @tmpl_dirs occurs in 'setup( )', but could be
used anywhere) and if I'm doing this why would we even bother with
'tmpl_path( )' in the first place?
My CGI::Applications are given a configuration file, part of which helps
them find the templates they need. I'd like them to look in their own
directory first, then in 'application' (which to me means a big group of
cgi::applications connected by configuration) template directory and
finally in the server's application directory.
I want to do this so that I can: (1) ensure that every template I could
need will be found in some valid, if only the default, form, (2) let
interface designers override, cgi::application-by-cgi::application if
necessary, individual interface components and HTML elements (kinda like
HTML sub-classing.)
I'd like to store that path within the CGI::Application object if possible,
so that all the configuration type - stuff is done in 'setup( )' (which is
where it belongs, obviously.)
As far as I know, if I remain unable to pass an array-reference of paths
into a function like 'tmpl_path( )' I'll have to continue doing less
graceful things.
However, I am not fully aware (at least I doubt it) of the additional
difficulties posed by the functionality of handling array references. It
would make sense that if 'tmpl_path( )' used the 'path=>' argument in
'load_tmpl( )' calls instead of prepending, it would be trivial to have the
'tmpl_path( )' call convert any scalar(reference) into an array of only 1
element?
> > Why isn't this patch part of the main tree? Has it somehow offended someone
> > ;)
>
> Because Jesse hasn't put it there yet? I don't think anyone had seen it
> before I posted it here. Since I can't think of any good reasons to
> reject it, I imagine it will appear in some future release...
Let's just role all those changes in 'cgiapp_prerun( )' and this patch into
2.4!
Yea baby! Drop me a line if I can help somehow,
--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]
