Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Hi! Mostly the same here. I like it for testing and the only reason I can think of why it should be disabled is that you want to avoid setting params specific for your template. I kind of like the strict behavior on a second way: it remind me of use strict with scopes 'n stuff, but that may be just a subjective preference. Hth, Alex -Ursprüngliche Nachricht- Von: cgiapp-boun...@lists.erlbaum.net [mailto:cgiapp-boun...@lists.erlbaum.net] Im Auftrag von r...@savage.net.au Gesendet: Mittwoch, 11. November 2009 03:30 An: CGI Application Betreff: Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl Hi Mark Quoting Mark Stosberg m...@summersault.com: To proceed, I'd like to hear at least a small chorus of voices claiming that the they use the die_on_bad_params feature. I always use it, since in testing I want to know immediately if there is a problem. I assume those who don't use it do so in order to avoid having to set every parameter in the template. Is that right? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### Eingehende eMail ist virenfrei. Von AVG überprüft - www.avg.de Version: 9.0.704 / Virendatenbank: 270.14.59/2494 - Ausgabedatum: 11/10/09 08:38:00 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
On Tue, 2009-11-10 at 20:56 -0500, Mark Stosberg wrote: To proceed, I'd like to hear at least a small chorus of voices claiming that the they use the die_on_bad_params feature. I use it all the time as an alternative to an if-then-else: if a piece of content is not to be displayed, I just dont define its template variable. But from the tone of your and following messages, I sense that I am doing something Seriously Bad (TM). If that is the case, I would be happy to hear reasons. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
.. I don't know how many people use die_on_bad_params, so I don't know how worth it it is to modify the core. .. I use it exclusively, under the assumption that, like 'use strict', it is just best practice, may make my code faster and less error-ridden, and may endow me with good looks and untold riches. I have no scientific basis for the above assumptions. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --- Assertions are politics; backing up assertions with evidence is science === Sent from Madison, Wisconsin, United States # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
On 11/11/2009 10:46 AM, P Kishor wrote: I use it exclusively, under the assumption that, like 'use strict', it is just best practice, But a real question I have is, should designers (who are the ones creating these, or at least that's one of it's benefits is that they can) be burdened with strict when the environment they operate in (HTML, CSS) is inherently not strict. may make my code faster I seriously doubt this. Especially if your code has to do lots of $tmpl-query() stuff to make sure that a variable is present before doing a $tmpl-param(). and less error-ridden, The only error I know that this catches is a misspelling on the programmer's side. Which I'll admit is a real problem. But in most of my cases, it's a problem that's easily seen because the data does not show up where it should. and may endow me with good looks and untold riches Maybe if you rub Sam Tregar's belly. But I'd be careful, he's got a mean right hook :) -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
On Wed, 11 Nov 2009 02:30:21 + r...@savage.net.au wrote: Hi Mark Quoting Mark Stosberg m...@summersault.com: To proceed, I'd like to hear at least a small chorus of voices claiming that the they use the die_on_bad_params feature. I always use it, since in testing I want to know immediately if there is a problem. I assume those who don't use it do so in order to avoid having to set every parameter in the template. Is that right? As a standard part of our toolkit, we make all of our config variables always available to the template, with a cfg_ prefix appended to their name. So, the designer knows for instance she has the option to put !-- tmpl_var cfg_root_uri -- in the template, but it is not required on every page. If we need to precisely test the template, we can use a simple regex match to check that tokens appear in the file, our we can use html_tmpl_class() and HTML::Template::Dumper for a more formal approach. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer m...@summersault.com Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Hi Michael Quoting Michael Peters mpet...@plusthree.com: On 11/11/2009 10:46 AM, P Kishor wrote: I use it exclusively, under the assumption that, like 'use strict', it is just best practice, But a real question I have is, should designers (who are the ones creating these, or at least that's one of it's benefits is that they can) be burdened with strict when the environment they operate in (HTML, CSS) is inherently not strict. This is a pathetic argument! Just because X is non-strict does not justify refusing to use strict in Y, when the whole point of strictness is to help improve software reliability. I.e. it's not a case of less strictness is better, but rather, more is - without being fanatical of course... Strictness is not the burden, bugs are :-). # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Hi Michael Looking back at all of my projects that use HTML::Template I can honestly say that die_on_bad_params has caused more problems then it's fixed for me. It's not an argument against reliability but rather for it. If a valid template change causes an ISE (rather than just an invalid display) I'd say your software is less reliable. You now need a developer to fix what was supposed to be a design problem. Oh. I go by the fact that at least 99% of the template problems I've caught by testing, i.e. before putting the template into production. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
This is a pathetic argument! If die_on_bad_params makes it harder for designers to use and less like the tools they are used to using, how can that be a pathetic argument. Just because X is non-strict does not justify refusing to use strict in Y, when the whole point of strictness is to help improve software reliability. Looking back at all of my projects that use HTML::Template I can honestly say that die_on_bad_params has caused more problems then it's fixed for me. It's not an argument against reliability but rather for it. If a valid template change causes an ISE (rather than just an invalid display) I'd say your software is less reliable. You now need a developer to fix what was supposed to be a design problem. That ist he argument I always hear from people not using strict when getting the advice to use strict. Of course, if no strict was used, using strict causes problems, e.g. by aborting for each non declared variable. But that is not the point. The point is, to avoid errors and bugs and unvorseen behavior by using strict in the first place. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
I don't know how many people use die_on_bad_params, so I don't know how worth it it is to modify the core. I have never used die_on_bad_params with HTML::Template. At least two of the mostly-API-compatible projects choose not to support enabling the option: HTML::Template::Compiled has the feature disabled and has no plans to implement it. http://search.cpan.org/~tinita/HTML-Template-Compiled-0.94/lib/HTML/Template/Compiled.pm#MISSING_FEATURES HTML::Template::Pro also has the feature disabled and it can't be changed. http://search.cpan.org/~viy/HTML-Template-Pro-0.92/lib/HTML/Template/PerlInterface.pod#new() To proceed, I'd like to hear at least a small chorus of voices claiming that the they use the die_on_bad_params feature. Mark -- http://mark.stosberg.com/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Hi Mark Quoting Mark Stosberg m...@summersault.com: To proceed, I'd like to hear at least a small chorus of voices claiming that the they use the die_on_bad_params feature. I always use it, since in testing I want to know immediately if there is a problem. I assume those who don't use it do so in order to avoid having to set every parameter in the template. Is that right? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Hi Mark!
How would your propose to deal with the HTML::Template-like modules
that do not pass the isa HTML::Template test but are generally
compatible?
Could we test for the features we need instead of the classes they
come from?
Right, of course - that makes much more sense. Maybe we could use
'$class-can(query)' instead of '$class-isa(HTML::Template)'.
I'm thinking that each plugin that wanted to pass template parameters
would do something like this:
## hooked via load_tmpl
sub my_load_tmpl_callback {
my ($c, $ht_params, $tmpl_params, $tmpl_file) = @_;
my $template_class = $c-html_tmpl_class;
eval require $template_class;;
# for HTML::Template and compatible templating
# systems, don't add params here, add them in
# the loaded_html_template callback instead
# detect HTML::Template - compatibility by presence
# of a 'query' method
return if eval { $template_class-can('query') };
$tmpl_params-{'my_param'} = 'some_value';
}
## hooked via loaded_html_tmpl
sub my_html_template_loaded_callback {
my ($c, $ht_params, $tmpl_params, $tmpl_file, $tmpl_obj) = @_;
my $template_class = $c-html_tmpl_class;
eval require $template_class;;
# skip if not HTML::Template or compatible,
# because we should have already added params under
# the load_tmpl callback
# detect HTML::Template - compatibility by presence
# of a 'query' method
return unless eval { $template_class-can('query') };
if (!exists $ht_params-{'die_on_bad_params'}
or $ht_params-{'die_on_bad_params'}) {
return unless $tmpl_obj-query(
name = 'my_param',
);
}
$tmpl_obj-param('my_param' = 'some_value');
}
Problems I see with this approach:
1) html_tmpl_class being used contrary to its original purpose.
Returning 'Petal' or 'Template' or 'Template::Toolkit' from this
attribute seems weird, since it's named 'html_tmpl...' and none
of these other templating systems are related to HTML::Template
at all. Maybe this isn't a big deal.
At the very least, to support a mix of templating systems,
plugins like CAP::TT and CAP::AnyTemplate should probably only
set this attribute for the duration of the 'load_tmpl' hook, e.g.
my $saved_class = $c-html_tmpl_class;
$c-html_tmpl_class('Template');
$self-call_hook('load_tmpl', ... );
$c-html_tmpl_class($saved_class);
2) What happens if another templating system provides a 'query'
method that does something completely different from what
HTML::Template's 'query' does?
3) Plugin code complexity. While this approach does reduce the code
that plugins have to include, it's still a lot of code to write
(and test) just to add a template parameter. It's also pretty
tricky and fragile for a standard API. Maybe it could be wrapped
up into its own CAP::AddTemplateParams plugin with a simpler
API?
A plugin that wanted to add template parameters would do
something like this:
use CGI::Application::Plugin::AddTemplateParams;
sub import {
my $caller = scalar(caller);
if ($caller-can('add_callback')) {
$caller-add_callback(
'add_template_params' = \_add_tmpl_parms
);
}
}
## hooked via add_template_params
sub _add_tmpl_parms {
my ($c, $tmpl_params) = @_;
$tmpl_params-{'my_param'} = 'some_value';
}
Michael
--
Michael Graham ma...@the-wire.com
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
Michael -- Here's a new proposal for solving the multiple template parsing problem when die_on_bad_params is enabled. Add another callback to CGI::Application: loaded_html_tmpl This gets called with the newly created template object before it gets returned to the user. CAP::AnyTemplate and CAP::TT would not call this hook. Plugins wishing to automatically pass variables to templates would do the following: * hook the 'load_tmpl' callback - if html_tmpl_class isa 'HTML::Template' then return. - Otherwise, add parameters to $tmpl_params * hook the 'loaded_html_template' callback - return unless html_tmpl_class isa 'HTML::Template' - check $ht_params for die_on_bad_params (default to 1) - if die_on_bad_params is enabled, use HTML::Template's query method to determine whether or not it is safe to add the parameter. - if it is safe, add the parameter via $tmpl-param(); I don't know how many people use die_on_bad_params, so I don't know how worth it it is to modify the core. However, this hook would improve performance for users of die_on_bad_params when using plugins that automatically add template values, and it would greatly simplify the code required in each of these plugins. How would your propose to deal with the HTML::Template-like modules that do not pass the isa HTML::Template test but are generally compatible? Could we test for the features we need instead of the classes they come from? Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer m...@summersault.com Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
