Re: [cgiapp] ANNOUNCE: AnyTemplate 0.10_02 developer release and RFC

[Michael Graham <suppressed>]

Michael - thanks for the feedback!

> >     * is the ability to override C::A's built-in 'load_tmpl' method too
> >       dangerous a feature?
>
> I don't think so. It's extremely well documented that overriding
> load_tmpl() is par for the course. You module is a plugin/mix-in so it's
> not only allowed to add behavior, but change existing behavior. I would
> also think it allows other plugins to use load_tmpl() without having to
> guess what templating engine is being used.

I guess what worries me about load_tmpl() (and for that matter the whole
AnyTemplate configuration system) is that all the magic and sugar only
work up to a point.

Developers still need to choose the type of templates they want to use,
and different apps and plugins need to make different choices.

For instance, I doubt that plugin authors are going to want to ship
three complete sets of templates with each plugin they make.  More
likely they'll stick to their favourite template engine and leave
conversion to other template formats as an "exercise for the reader".

So for two different plugins there will be two different 'default'
template types.  For instance, when I say load_tmpl(), I wan't
HTML::Template.  But when you say load_tmpl(), you want Petal, etc.

If we each just set up the default type in template->config, then we get
conflicts:

    package My::Plugin;
    $self->template->config(
        type => 'HTMLTemplate',
    );
    ...
    my $template = $self->load_tmpl('filename.html');


    package Your::Plugin;
    $self->template->config(
        type => 'Petal',
    );
    ...
    my $template = $self->load_tmpl('filename.html');


Unfortunately, this fails rather spectacularly; both calls to
load_tmpl() will try to load Petal templates.  This is because
Your::Plugin config clobbers My::Plugin's config.


I've suggested that plugin authors resolve this by using AnyTemplate's
named configs feature:

    package My::Plugin;
    $self->template(__PACAKGE__)->config(
        type => 'HTMLTemplate',
    );
    ...
    my $template = $self->template(__PACKAGE__)->load;


    package Your::Plugin;
    $self->template(__PACAKGE__)->config(
        type => 'Petal',
    );
    ...
    my $template = $self->template(__PACKAGE__)->load;

This does keep everything straight, but it's a royal pain to use.  Plus,
it doesn't work at all for $self->load_tmpl(), since there's no way to
select a config (or a type) with that method.

I guess the options are:

    A) document the issues and forget about it
    B) throw an error when one config clobbers another
    C) make the 'default' config more magical:
       * make config store the configuration in the current class
       * make load, fill and process walk the @ISA tree looking for the
         nearest config


Option (A) is the current state of affairs.

Option (C) would probably work and it would probably not be as
dangerously automagical as it looks.  It does have the advantage of
"just working" out of the box.


Michael


--
Michael Graham <suppressed>



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed