[cgiapp] [patch] CAP::MessageStack + CAP::FormState

[Alex]

Hi!

CGI::Application::Plugin::HTCompiled does set up tmpl_class already. For
CAP::HTDot, I'll have to create the same patch as for CAP::HTCompiled:
changing the way it can be used while keeping backward compatibility +
setting up tmpl_class.

And yes, die_on_bad_params is not good for looking for HTML:T:emplate,
you're right. We first have to look for it via tmpl_class (which, if always
setting is our consense), and then evaluate it. The later check for
die_on_bad_params is only a performance issue, as we don't need the check if
we don't care about template variable declaratoion.

Btw, HTML::Template::Compiled is HTML::Template derived but exactly not the
same (e.g. die_on_bad_params and associate is not implemented) and should
therefore set up another tmpl_class.

Regards, Alex

-----Ursprüngliche Nachricht-----
Von: cgiapp-bounces at lists.openlib.org
[mailto:cgiapp-bounces at lists.openlib.org] Im Auftrag von Michael Graham
Gesendet: Dienstag, 20. Oktober 2009 04:48
An: cgiapp at lists.openlib.org
Betreff: Re: [cgiapp] [patch] CAP::MessageStack + CAP::FormState


> a) hours
> I'll try to do spend the hours this weekend.

Cool!

> c) AnyTemplate
> I'm not shure if I didn't get it wrong, but doesn't CAP::AnyTemplate 
> must know, what templating engine (is that really the term for it?) is 
> used when calling the load_tmpl hook?

Sure, AnyTemplate can do this.  My point was that I didn't know if it is
better to change every template-related plugin (CAP::TT, CAP::AnyTemplate,
etc.), or whether it is better to change every plugin that sets template
params (CAP::FormState, CAP::MessageStack, etc.).

It seems like the consensus is to change every template-related plugin.

In addition to CAP::TT and CAP::AnyTemplate there are the following
template-related plugins that call the load_tmpl hook:

  CGI::Application::Plugin::HTDot
  CGI::Application::Plugin::HTCompiled

But, they're both HTML::Template based though, so maybe they don't need to
be changed?


> d) die_on_bad_params option defaults to true That's true. But as this 
> behavior is deterministic, we can safely assume that if 
> die_on_bad_params is not present, or not 0, it is 1, can't we?

My point was only that we can't use the presence of die_on_bad_params as a
substitute for figuring out the template class.


Michael


--
Michael Graham <magog at the-wire.com>

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################