Re: ANNOUNCE: AnyTemplate 0.10_02 developer release and RFC

Michael Graham wrote:
> 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.

I guess I was thinking of the simplest of cases where a plugin might
call load_tmpl() and just use the API that's magically the same. If
plugin authors include templates that need to be used, then it'll be up
to them to make sure they're using the right engine... Maybe setup a
separate config instance.

> 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".

I agree. Maybe this isn't so dangerous cause the plugin author would
describe what template engine is supported 'out of box' and just use
load_tmpl(). If the author's load_tmpl does something different than the
plugin wants, it's up to the user to port the templates and put them
where he wants them.

I think that most plugin authors who need to ship templates will try to
limit their template functionality to what AnyTemplate supports to
increase the usability of the plugin.

> 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.

[snip]

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

Yeah, I think that's a good way. But it doesn't cover the instance where
a plugin might be designed to just work with whatever template engine
the user has. Which is why load_tmpl() is nice, because it doesn't
assume anything.

[snip]

> 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.

[snip]

> 
> 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.

I think A is fine for now. We probably shouldn't worry too much about
this until someone actually has the problem. It's easier to solve if
there's a real use-case. And if it doesn't come up, then we continue
with a simpler API/code base :)

-- 
Michael Peters
Developer
Plus Three, LP


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