Jesse Sheidlower wrote:
> On Mon, Nov 29, 2004 at 11:33:04PM +0000, Simon Flack wrote:
>
>>Maypole doesn't use temp directories for anything yet. I think we need to
>>provide a way of passing configuration options to the view object, and
>>possibly set some sensible defaults, perhaps:
>>
>> COMPILE_EXT => '.ttc'
>> COMPILE_DIR => File::Spec->tmpdir (or perhaps, leave this undef)
>>
>>As I understand it, TT won't die if it can't compile() the template.
>>
>>It'd be nice to be able to pass other template options to the view object,
>>such as DEFAULT, TRIM, EVAL_PERL, etc. OTOH, you can always subclass M::V::TT
>>if you have special requirements.
>
>
> I agree that this would be a useful addition. In most of my applications
> now I'm subclassing M::V::TT solely in order to provide a PLUGIN_BASE,
> and this feels to me like the sort of thing that should be possible with
> a configuration variable. Overriding seems excessive, even though I
> acknowledge it's not the biggest problem.
Yes, those sorts of options should be configurable with M::V::TT.
However, I think there are times where it's easier to subclass than to
try and accomodate everything you can do with TT. For example, in an app
I'm writing, I add to %Template::Stash::LIST_OPS...
use base 'Maypole::View::TT';
use Template::Stash;
sub template {
my $self = shift;
local $Template::Stash::LIST_OPS{sort_by_rank} = \&sort_by_rank;
local $Template::Stash::LIST_OPS{sort_by_name} = \&sort_by_name;
...
$self->SUPER::template(@_);
}
I suppose I could have just added methods to my CDBI classes to return
lists sorted on different columns, but it's purely presentational, so
the view looks like the logical place to handle it.
Aside from the fact that I may be missing a much simpler way of doing
this in TT, it looks like a valid case for subclassing M::V::TT.
OTOH, the view object is around for the lifetime of your Maypole
application. With CGI::Maypole, that's a single request, and with
Apache::MVC, it's for the lifetime of the apache child process. So we
could give each view object its own Template object (rather than sharing
them for all Maypole apps). If the view exposes the TT object, then you
can set all kinds of things in MyApp::init(), including a custom
Template::Stash.
And/or the common Template constructor options could be configurable via
the application config, e.g.:
MyApp->config->view_opts({
TRIM => 1,
DEFAULT => '404.tt',
COMPILE_DIR => '/home/simonf/tmp',
PLUGIN_BASE => ['MyApp::View'],
...
});
I'm just thinking aloud. Comments are welcome.
Simon
_______________________________________________
maypole-dev mailing list
maypole-dev at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole-dev
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT