tag:old.nabble.com,2006:forum-13612Nabble - Perl - Cgi-Application2009-12-07T12:25:08ZFor discussion of the use and development of the CGI::Application module, and related systems. CGI::Application is a framework for building web-based applications in Perl.tag:old.nabble.com,2006:post-26683537CAP::RateLimit question -- REMOTE_IP2009-12-07T12:25:08Z2009-12-07T12:25:08ZMark RajcokI'm looking at CAP::RateLimit and I have a question about REMOTE_IP. My
<br>apache server doesn't have that environment variable defined (nor is
<br>REMOTE_USER defined for my app -- so the remote user is not being
<br>identified. REMOTE_ADDR is defined.) How does one get REMOTE_IP to be
<br>defined?
<br><br>REMOTE_IP is not on this (old?) CGI reference page:
<br><a href="http://hoohoo.ncsa.illinois.edu/cgi/env.html" target="_top" rel="nofollow">http://hoohoo.ncsa.illinois.edu/cgi/env.html</a><br><br>-- Mark
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26653221Re: CAP::Security::CSRF -- useful?2009-12-04T22:01:24Z2009-12-04T22:01:24ZMark RajcokTo complete this one-man dialogue, the code below seems to work well, but I
<br>had to change the if statement to
<br> if(defined $self->{'__DFV_RESULT'}) {
<br>to guard against a scenario where CAP::ValidateRM is loaded, but neither
<br>check_rm() nor validate_rm() was called (i.e., ValidateRM was not used to
<br>validate the form). In this scenario, dfv_results() calls 'die' -- not
<br>good.
<br><br>I assume this is a bit chummy -- a module shouldn't be looking at another
<br>module's "private" data -- but there is no method in CAP::ValidateRM that
<br>indicates if check_rm() or validate_rm() was called.
<br><br>I ended up writing my own CSRF Plugin. It borrows some good ideas from
<br>ProtectCSRF in that it uses attribute handlers and adds the hidden form
<br>field to the HTML. If I ever decide to put it up on CPAN, maybe then I'd
<br>ask Mark S. to add a new method to CAP::ValidateRM.
<br><br>-- Mark
<br><br>On Thu, Dec 3, 2009 at 9:29 PM, Mark Rajcok <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653221&i=0" target="_top" rel="nofollow">mrajcok@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> A possible solution: the postrun callback for ProtectCSRF runmodes could
<br>> be enhanced to detect that ValidateRM was used, and that there were errors
<br>> on the form. Something like this:
<br>>
<br>> if($self->can('dfv_results')) { # hmm, using CAP::ValidateRM
<br>> my $r = $self->dfv_results;
<br>> if($r->has_missing or $r->has_invalid) {
<br>> # the form has errors, assume we need to generate an new CSRF
<br>> token:
<br>> # ... code here to generate a new token and add it to the HTML
<br>> ...
<br>>
</div><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26637385Re: CAP::Security::CSRF -- useful?2009-12-03T19:24:48Z2009-12-03T19:24:48ZMark RajcokHi Cosimo,
<br>Since I use CAP::Config::Simple, $self->config() won't work in my app. Your
<br>comment caused me to go look at what other CSRF modules do.
<br>CAP::ProtectCSRF does this:
<br><br>my @words = ('A'..'Z', 'a'..'z', 0..9, '/', '.');
<br>my $salt = join "", @words[ map { sprintf( "%d", rand(scalar @words) ) } 1..2 ];
<br>my $csrf_id = sha1_hex($salt . time . $$ . rand(10000));
<br><br>and a similar Catalyst module, Catalyst::Controller::RequestToken, does
<br>this:
<br><br>my $digest = _find_digest();
<br>my $seed = join( time, rand(10000), $$, {} );
<br>$digest->add($seed);
<br>my $token = $digest->hexdigest;
<br><br>I did modify my module to add some more randomness.
<br>Thanks for the suggestion.
<br><br>-- Mark
<br><br>On Sun, Nov 29, 2009 at 8:46 AM, Cosimo Streppone <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26637385&i=0" target="_top" rel="nofollow">cosimo@...</a>>wrote:
<br><div class='shrinkable-quote'><br>> In the token generation, I would try to be less predictable,
<br>> and inject a secret string coming from a config file, something like:
<br>>
<br>> my $token = sha1_base64( join '/',
<br>> $self->config('csrf-seed'),
<br>> $self->session->param('_SESSION_ID'),
<br>> time
<br>> );
<br>>
<br>> So even if you know that a specific app is made with CGI::Application
<br>> and it uses CSRF protection, you have lower chances of
<br>> predicting the exact sha1 hash that will be generated.
<br>>
</div><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26637019Re: CAP::Security::CSRF -- useful?2009-12-03T18:29:16Z2009-12-03T18:29:16ZMark RajcokA possible solution: the postrun callback for ProtectCSRF runmodes could be
<br>enhanced to detect that ValidateRM was used, and there were errors on the
<br>form. Something like this:
<br><br> if($self->can('dfv_results')) { # hmm, using CAP::ValidateRM
<br> my $r = $self->dfv_results;
<br> if($r->has_missing or $r->has_invalid) {
<br> # the form has errors, assume we need to generate an new CSRF
<br>token:
<br> # ... code here to generate a new token and add it to the HTML
<br>...
<br><br>I'm not sure if a new token should be generated, or the existing one should
<br>be (re)used. At a minimum, the hidden field with the token needs to be
<br>added to the HTML again.
<br><br>For CA apps that don't use ValidateRM, we could add a new method to
<br>CAP::ProtectCSRF that would set some kind of flag so that the postrun
<br>callback would know to generate a token and add it to the HTML. The app
<br>developer would have to remember to call it though -- it wouldn't happen
<br>behind the scenes like above. Something like this:
<br><br>sub create_check : Runmode :ProtectCSRF {
<br> my $self = shift;
<br> # check the form without using my ValidateRM
<br> $self->add_csrf_id_to_html();
<br> # and maybe $self->generate_csrf_token();
<br> # ... code to re-generate the original form with errors ...
<br>} <--- the postrun callback/hook would do the real work, if the flag was
<br>set
<br><br>Comments?
<br>-- Mark
<br><br>On Thu, Dec 3, 2009 at 1:16 AM, Mark Rajcok <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26637019&i=0" target="_top" rel="nofollow">mrajcok@...</a>> wrote:
<br><br>> Anyone see a solution to this problem? (other than abandoning attribute
<br>> handlers and requiring functions like create() above to explicitly call
<br>> _publish_csrf_id() and _add_csrf_id())
<br>>
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26621534Re: CAP::Security::CSRF -- useful?2009-12-02T22:16:25Z2009-12-02T22:16:25ZMark RajcokI tried using CAP::ProtectCSRF and ran into a problem.
<br>The plugin uses attribute handlers, which work great when a form is
<br>initially displayed -- postrun callback _add_csrf_id() is magically called
<br>to add the token (as a hidden field) to the HTML form, based on the
<br>"PublishCSRFID" attribute being present:
<br><br>sub create : Runmode :PublishCSRFID {
<br> my ($self, $errs) = @_;
<br> my $t = $self->load_tmpl('request_form.html');
<br>...
<br> $t->output
<br>} # <------ _add_csrf_id() gets called
<br><br>sub create_check : Runmode :ProtectCSRF {
<br> my $self = shift;
<br> my $dfv_results = $self->check_rm('create', Request::dfv_create_rules)
<br>||
<br> return $self->check_rm_error_page; # <----- _add_csrf_id() does
<br>not get called
<br>...
<br>}
<br><br>If there is a problem with the form, check_rm_error_page() calls create()
<br>and the form will be redisplayed to the user with errors, but the postrun
<br>callback does not get executed, so the HTML form will not have the hidden
<br>field with the token. Trying to submit a corrected form then fails with a
<br>CSRF error, since there is no CSRF token in the submitted form.
<br>(I suppose this is a ProtectCSRF bug, since I don't think I'm doing anything
<br>odd here.)
<br><br>Anyone see a solution to this problem? (other than abandoning attribute
<br>handlers and requiring functions like create() above to explicitly call
<br>_publish_csrf_id() and _add_csrf_id())
<br><br>The above may boil down to this general issue/question: if a plugin
<br>installs a (say prerun) callback for (say) rm2, and rm1 calls rm2 directly,
<br>is there any way to force the callbacks to be executed for rm2 (without
<br>using a redirect)? For example:
<br><br>sub rm1 { # does not require authentication
<br> ...
<br> $self->rm2; # <--- no callbacks are executed for rm2 -- sometimes that's
<br>a problem
<br>}
<br>sub rm2 { # requires authentication and uses a prerun callback to enforce it
<br>...
<br>}
<br><br>-- Mark
<br><br>On Sat, Nov 28, 2009 at 10:08 PM, Mark Rajcok <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26621534&i=0" target="_top" rel="nofollow">mrajcok@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> I should have searched CPAN some more first:
<br>> <a href="http://search.cpan.org/perldoc?CGI::Application::Plugin::ProtectCSRF" target="_top" rel="nofollow">http://search.cpan.org/perldoc?CGI::Application::Plugin::ProtectCSRF</a><br>>
<br>>
<br>> On Sat, Nov 28, 2009 at 6:21 PM, Mark Rajcok <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26621534&i=1" target="_top" rel="nofollow">mrajcok@...</a>> wrote:
<br>>
<br>>> I want to guard against multiple form submissions (reload, resubmit, etc.)
<br>>> and CSRF in my app:
<br>>>
<br>>
<br>>
</div><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26619975Re: [PATCH] C::A::Plugin::PageBuilder bug #484982009-12-02T18:15:19Z2009-12-02T18:15:19ZSteve Bertrand-2Steve Bertrand wrote:
<br>> CGI::Application::Plugin::PageBuilder bug #48498.
<br>>
<br>> The following patch allows the Plugin to pass tests, install correctly
<br>> and work properly on perl-5.10.1,
<br><br>Hi all,
<br><br>I'm readying a project that I want to up to the CPAN, in which
<br>CAP::PageBuilder is intrinsic to it.
<br><br>I have not heard back from the developer regarding the patch. How would
<br>one go about having the patch integrated (or at least investigated) in
<br>this case?
<br><br>Steve
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26562183Re: CAP::Security::CSRF -- useful?2009-11-29T05:46:12Z2009-11-29T05:46:12ZCosimo StrepponeIn data 29 novembre 2009 alle ore 00:21:13, Mark Rajcok
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26562183&i=0" target="_top" rel="nofollow">mrajcok@...</a>> ha scritto:
<br><div class='shrinkable-quote'><br>> I want to guard against multiple form submissions (reload, resubmit,
<br>> etc.)
<br>> and CSRF in my app:
<br>> <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" target="_top" rel="nofollow">http://en.wikipedia.org/wiki/Cross-site_request_forgery</a><br>> <a href="http://www.perlmonks.org/?node_id=606832" target="_top" rel="nofollow">http://www.perlmonks.org/?node_id=606832</a><br>> I hacked up a simple plugin. Do you think it would be useful? or might
<br>> something like this already exist?
<br>>
<br>> [...]
<br>>
</div><br>> # generate a new token for this new form
<br>> my $token = sha1_base64($self->session->param('_SESSION_ID') . time);
<br><br>Hi,
<br><br>I think the idea is really good.
<br>In the token generation, I would try to be less predictable,
<br>and inject a secret string coming from a config file,
<br>something like:
<br><br> my $token = sha1_base64( join '/',
<br> $self->config('csrf-seed'),
<br> $self->session->param('_SESSION_ID'),
<br> time
<br> );
<br><br>So even if you know that a specific app is made with CGI::Application
<br>and it uses CSRF protection, you have lower chances of
<br>predicting the exact sha1 hash that will be generated.
<br><br>--
<br>Cosimo
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26559029Re: CAP::Security::CSRF -- useful?2009-11-28T19:08:56Z2009-11-28T19:08:56ZMark RajcokI should have searched CPAN some more first:
<br> <a href="http://search.cpan.org/perldoc?CGI::Application::Plugin::ProtectCSRF" target="_top" rel="nofollow">http://search.cpan.org/perldoc?CGI::Application::Plugin::ProtectCSRF</a><br><br>On Sat, Nov 28, 2009 at 6:21 PM, Mark Rajcok <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26559029&i=0" target="_top" rel="nofollow">mrajcok@...</a>> wrote:
<br><br>> I want to guard against multiple form submissions (reload, resubmit, etc.)
<br>> and CSRF in my app:
<br>>
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26557947CAP::Security::CSRF -- useful?2009-11-28T15:21:13Z2009-11-28T15:21:13ZMark RajcokI want to guard against multiple form submissions (reload, resubmit, etc.)
<br>and CSRF in my app:
<br> <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" target="_top" rel="nofollow">http://en.wikipedia.org/wiki/Cross-site_request_forgery</a><br> <a href="http://www.perlmonks.org/?node_id=606832" target="_top" rel="nofollow">http://www.perlmonks.org/?node_id=606832</a><br><br>I hacked up a simple plugin. Do you think it would be useful? or might
<br>something like this already exist?
<br><br>package CGI::Application::Plugin::Security::CSRF;
<br>use strict;
<br>use warnings;
<br>use base 'Exporter';
<br>use CGI::Application;
<br>use CGI::Application::Plugin::Session;
<br>use Digest::SHA1 qw(sha1_base64);
<br><br>use vars qw($VERSION @EXPORT);
<br>@EXPORT = qw(csrf_insert_token csrf_attack);
<br>$VERSION = '1.0';
<br><br>sub csrf_insert_token {
<br> my ($self, $token_name, $tmpl) = @_;
<br> if($self->query->param('csrf_token')) {
<br> # reuse the token that was submitted with the form; don't generate a
<br>new one
<br> } else {
<br> # generate a new token for this new form
<br> my $token = sha1_base64($self->session->param('_SESSION_ID') .
<br>time);
<br> # TBD: below, what if the app is not using HTML::Template ??
<br> $tmpl->param(csrf_token => $token);
<br> $self->session->param($token_name => $token);
<br> }
<br>}
<br>sub csrf_attack {
<br> my ($self, $token_name) = @_;
<br> if( ($self->query->request_method ne 'POST') # ensure the form was
<br>POSTed
<br> || ($self->session->param($token_name) ne
<br>$self->query->param('csrf_token')) ) {
<br> return 1
<br> }
<br> $self->session->clear($token_name);
<br> return 0
<br>}
<br>1;
<br><br>Example usage:
<br><br>sub edit_account_form : Runmode {
<br> my $self = shift;
<br> my $errs = shift; # created by edit_check()
<br> my $t = $self->load_tmpl('account_form.html');
<br>...
<br> $t->param(rm => 'edit_check');
<br> $self->csrf_insert_token('edit_account_token', $t); <<-------------
<br> $t->param($errs) if $errs;
<br> $t->output
<br>}
<br>#------------------------------------------------------------------------------
<br>sub edit_check : Runmode {
<br> my $self = shift;
<br> my $dfv_results = $self->check_rm('edit_account_form',
<br>my_dfv_edit_rules) ||
<br> return $self->check_rm_error_page;
<br> if($self->csrf_attack('edit_acount_token')) { <<------------------
<br> return $self->custom_error_page(msg =>
<br> 'It seems you may have been performing a similar operation in
<br>multiple windows'
<br> .' (which is not supported for security reasons),'
<br> .' or you tried to submit or reload the same form twice.');
<br> # or there was a real CSRF attack attempt, in which case no
<br> # one will ever see this error message
<br> }
<br> ...
<br><br>Each HTML form that uses this plugin will need the following hidden field:
<br> <input type="hidden" name="csrf_token" value="<tmpl_var token>" />
<br><br>Current limitations:
<br><br>1. csrf_insert_token() assumes/requires HTML::Template. Can a plugin
<br>determine if a different template system is in use?
<br>If so, the $tmpl argument could be optional, and if it is not present, the
<br>method could return the generated token. The app developer would then need
<br>to use whatever template system method is appropriated to add the token to
<br>the form.
<br><br>2. tokens are stored in the session object. A token is removed on a
<br>successful form submission. They remain otherwise. So tokens could collect
<br>over time, but only if the user visited form pages and did not submit them
<br>successfully. For apps that have a lot of forms that use this plugin, this
<br>could be an issue.
<br><br>3. As the error message implies in the edit_check() rm above, using a fixed
<br>token name like 'edit_account_token' will not allow a user to have two
<br>windows open to the same form and successfully submit both forms. Only the
<br>form that was opened last will succeed. For most apps, I would consider this
<br>a feature, not a bug (i.e., the "older" window becomes stale/unusable). But
<br>for certain apps, maybe this would be a problem.
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26519971[PATCH] C::A::Plugin::PageBuilder bug #484982009-11-25T12:43:49Z2009-11-25T12:43:49ZSteve Bertrand-2CGI::Application::Plugin::PageBuilder bug #48498.
<br><br>The following patch allows the Plugin to pass tests, install correctly
<br>and work properly on perl-5.10.1, on:
<br><br>% uname -a
<br>FreeBSD acct.eagle.ca 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1
<br>08:49:13 UTC 2009
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26519971&i=0" target="_top" rel="nofollow">root@...</a>:/usr/obj/usr/src/sys/GENERIC i386
<br><br>Steve
<br><br><br><br />--- CGI-Application-Plugin-PageBuilder-0.97/lib/CGI/Application/Plugin/PageBuilder.pm 2006-09-15 13:21:26.000000000 -0400
<br>+++ CGI-Application-Plugin-PageBuilder-0.97.good/lib/CGI/Application/Plugin/PageBuilder.pm 2009-11-25 15:30:16.000000000 -0500
<br>@@ -116,7 +116,7 @@
<br> my( $self, $param, $value ) = @_;
<br>
<br> return unless $value;
<br>- ${$self->{__PB_TEMPLATE_LIST}}[$#{@{$self->{__PB__TEMPLATE_LIST}}}]->param( $param, $value );
<br>+ $self->{__PB_TEMPLATE_LIST}->[-1]->param( $param, $value );
<br> return $self->pb_build();
<br> }<br /><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26470053Re: is my app caching db connection ?2009-11-22T14:06:14Z2009-11-22T14:06:14ZMark RajcokThanks to the archives I found this thread related to persistent DB
<br>connections when using CAP::DBH and FastCGI. I changed my cgiapp_init()
<br>code from:
<br> $self->dbh_config(
<br><br>$self->config_param('dsn'),$self->config_param('user'),$self->config_param('password')
<br> ,{PrintError => 0, RaiseError => 0}
<br> );
<br>to:
<br> $self->dbh_config(sub { DBI->connect_cached(
<br><br>$self->config_param('dsn'),$self->config_param('user'),$self->config_param('password')
<br> ,{PrintError => 0, RaiseError => 0}
<br> ); });
<br>and I now get persistent DB connections. Very nice.
<br><br>However, I would prefer if CAP:DBH did this automatically. If I leave my
<br>cgiapp_init() code as it was originally, and instead change DBH to use
<br>connect_cached() instead of connect(), I also get persistent DB
<br>connections. In addition to FastCGI, connect_cached() works with plain CGI
<br>and (according to the DBI documentation) with Apache::DBI.
<br><br>Are there any reasons DBH should not be using connect_cached()?
<br><br>BTW, I have a unit test script that uses Test::WWW::Mechanize to test my
<br>CGI::App application and when I moved over to FastCGI, it ran 11 times
<br>faster -- 12 seconds instead of 130. I should have started to use FastCGI a
<br>long time ago...
<br><br>The CA wiki is still not editable. Is anyone looking into fixing it?
<br><br>On Mon, Jul 28, 2008 at 1:53 PM, Dan Horne <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470053&i=0" target="_top" rel="nofollow">dan.horne@...</a>> wrote:
<br>>
<br>> I believe the way around this is to use the package variable approach Mark
<br>> suggests with a C::A::P::DBH callback. DBI's connect_cached option, is
<br>> designed to handle the stale connection problem (I use DBI directly, but the
<br>> principle is the same):
<br>>
<br>> # Use a callback to create your own handle that is still lazy loaded
<br>> $self->dbh_config(sub { DBI->connect_cached(); });
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26424887Re: UTF-8 output2009-11-19T03:50:03Z2009-11-19T03:50:03ZMike Tonks-2I have the following in my cgiapp_init:
<br><br> binmode STDOUT, ":utf8"; # Explicitly output utf8 - this is critical
<br><br>probably totally wrong, but it works for me...
<br><br><br><br><br>2009/11/4 Michael Lackhoff <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26424887&i=0" target="_top" rel="nofollow">lackhoff@...</a>>:
<div class='shrinkable-quote'><br>> On 04.11.2009 12:19 Cees Hek wrote:
<br>>
<br>>> You mean something like this:
<br>>>
<br>>> __PACKAGE__->add_callback('postrun', sub {
<br>>> my $self = shift;
<br>>>
<br>>> # Make sure the output is utf8 encoded if it needs it
<br>>> if ( $_[0] && ${$_[0]} && utf8::is_utf8(${$_[0]}) ){
<br>>> utf8::encode( ${$_[0]} );
<br>>> }
<br>>>
<br>>> return;
<br>>> });
<br>>>
<br>>> I have that in my CGI::App base class.
<br>>
<br>> As time goes by my base class gets more and more pieces of yours ;-)
<br>>
<br>> Thanks
<br>> -Michael
<br>>
<br>> ##### CGI::Application community mailing list ################
<br>> ## ##
<br>> ## To unsubscribe, or change your message delivery options, ##
<br>> ## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>> ## ##
<br>> ## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>> ## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>> ## ##
<br>> ################################################################
<br>>
<br>>
</div><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26423793Re: CGI::Simple as replacement for CGI not working?2009-11-19T02:19:42Z2009-11-19T02:19:42ZJolly.TallRichard Jones wrote:
<br>> App working fine with default CGI, but decided to see if it works with
<br>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>> rendering the page I get a popup: 'you have chosen to open
<br>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br><br>OK, more info. The app does actually work OK with CGI::Simple, but I'm
<br>using the expression $self->query->url() a lot to generate links within
<br>the app, and when I dump $self->query->url() to stdout, for CGI::Simple
<br>I get this: <a href="http://localhost:8080script/lims_server.pl" target="_top" rel="nofollow">http://localhost:8080script/lims_server.pl</a><br>instead of the correct url (as with CGI.pm): <a href="http://localhost:8080/hmds" target="_top" rel="nofollow">http://localhost:8080/hmds</a><br><br>That appears to be what is causing the problem. If I hover over the urls
<br>generated by the app using CGI::Simple, I get things like
<br><a href="http://localhost:8080/lims_server.pl/user/change_password" target="_top" rel="nofollow">http://localhost:8080/lims_server.pl/user/change_password</a><br>and if I change 'lims_server.pl' to 'hmds' (as generated by CGI.pm) in
<br>the browser address, the page renders fine (but still generates
<br>incorrectly formatted urls).
<br><br>lims_server.pl is the name of the script which starts the development
<br>server on port 8080.
<br><br>my $server = CGI::Application::Server->new();
<br>$server->document_root("$Bin/../static");
<br>$server->entry_points( { '/hmds' => 'LIMS::Dispatch' } ); # CAD class
<br>$server->run;
<br><br>Hope this is more helpful.
<br>--
<br>Richard Jones
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26417094Re: CGI::Simple as replacement for CGI not working?2009-11-18T14:40:26Z2009-11-18T14:40:26ZJolly.TallCees Hek wrote:
<div class='shrinkable-quote'><br>> On Thu, Nov 19, 2009 at 5:59 AM, Richard Jones <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26417094&i=0" target="_top" rel="nofollow">ra.jones@...</a>> wrote:
<br>>> App working fine with default CGI, but decided to see if it works with
<br>>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>>> rendering the page I get a popup: 'you have chosen to open
<br>>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br>>
<br>> I seems like maybe you aren't sending a content type header...
<br>>
<br>> LWP comes with a command line script called GET which is handy for
<br>> fetching pages and looking at headers (there are also useful firefox
<br>> plugins for this too). Try this from your shell:
<br>>
<br>> GET -ed <a href="http://mysite/myapp_server.pl" target="_top" rel="nofollow">http://mysite/myapp_server.pl</a><br>>
<br>> That will dump the response headers to the screen. Check to make sure
<br>> the content-type is correct.
<br>>
<br>> Cheers,
<br>>
</div>Hi Cees,
<br><br>Emulating the url I would use in the browser:
<br>GET -ed <a href="http://localhost:8080/hmds" target="_top" rel="nofollow">http://localhost:8080/hmds</a><br><br>produced:
<br><br>Connection: close
<br>Date: Wed, 18 Nov 2009 22:30:17 GMT
<br>Content-Length: 4920
<br>Content-Type: text/html; charset=ISO-8859-1
<br>Client-Date: Wed, 18 Nov 2009 22:30:17 GMT
<br>Client-Peer: 127.0.0.1:8080
<br>Client-Response-Num: 1
<br>Link: <<a href="http://localhost:8080/css/lims.css" target="_top" rel="nofollow">http://localhost:8080/css/lims.css</a>>; rel="stylesheet";
<br>type="text/css"
<br>Link: </css/autosuggest_inquisitor.css>; charset="utf-8";
<br>media="screen"; rel="stylesheet"; type="text/css"
<br>Link: </css/print.css>; media="print"; rel="stylesheet"; type="text/css"
<br>Set-Cookie: CGISESSID=1459; path=/; expires=Thu, 19-Nov-2009 22:30:17 GMT
<br>Title: HMDS Information Management System
<br><br>I'm not familiar with the output of the GET command-line, but I think
<br>the content-type looks OK (text/html) - no?
<br>--
<br>Richard Jones
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26416947Re: CGI::Simple as replacement for CGI not working?2009-11-18T14:28:29Z2009-11-18T14:28:29ZP Kishor-3On Wed, Nov 18, 2009 at 3:18 PM, Richard Jones <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416947&i=0" target="_top" rel="nofollow">ra.jones@...</a>> wrote:
<div class='shrinkable-quote'><br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416947&i=1" target="_top" rel="nofollow">ron@...</a> wrote:
<br>>> Hi Richard
<br>>>
<br>>>
<br>>> Quoting "Richard Jones" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416947&i=2" target="_top" rel="nofollow">ra.jones@...</a>>:
<br>>>
<br>>>> App working fine with default CGI, but decided to see if it works with
<br>>>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>>>> rendering the page I get a popup: 'you have chosen to open
<br>>>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>>>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br>>>
<br>>> My guess is that when you saved your edits, the execute bit on the
<br>>> file was turned off.
<br>>
<br>> Hi Ron,
<br>>
<br>> Good idea but it can't be that as it's an actively developed app which
<br>> has edits saved many times per day. And in fact I'm using
<br>> CGI::App:Dispatch and CGI::App::Server so the MyApp.pm part (where the
<br>> cgiapp_get_query method sits) isn't executable anyway. Maybe something
<br>> to do with CAD?
</div><br><br>I work everyday with C::A, C::A::D, CGI::Simple. No problem at all.
<br>You will have to give a lot more information to help others debug your
<br>problem, but it does smell of wrong headers/mime type, etc.
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26416507Re: CGI::Simple as replacement for CGI not working?2009-11-18T13:56:16Z2009-11-18T13:56:16ZCees HekOn Thu, Nov 19, 2009 at 5:59 AM, Richard Jones <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416507&i=0" target="_top" rel="nofollow">ra.jones@...</a>> wrote:
<br>> App working fine with default CGI, but decided to see if it works with
<br>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>> rendering the page I get a popup: 'you have chosen to open
<br>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br><br>I seems like maybe you aren't sending a content type header...
<br><br>LWP comes with a command line script called GET which is handy for
<br>fetching pages and looking at headers (there are also useful firefox
<br>plugins for this too). Try this from your shell:
<br><br> GET -ed <a href="http://mysite/myapp_server.pl" target="_top" rel="nofollow">http://mysite/myapp_server.pl</a><br><br>That will dump the response headers to the screen. Check to make sure
<br>the content-type is correct.
<br><br>Cheers,
<br><br>Cees
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26416921Re: CGI::Simple as replacement for CGI not working?2009-11-18T13:18:53Z2009-11-18T13:18:53ZJolly.Tall<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416921&i=0" target="_top" rel="nofollow">ron@...</a> wrote:
<div class='shrinkable-quote'><br>> Hi Richard
<br>>
<br>>
<br>> Quoting "Richard Jones" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416921&i=1" target="_top" rel="nofollow">ra.jones@...</a>>:
<br>>
<br>>> App working fine with default CGI, but decided to see if it works with
<br>>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>>> rendering the page I get a popup: 'you have chosen to open
<br>>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br>>
<br>> My guess is that when you saved your edits, the execute bit on the
<br>> file was turned off.
</div><br>Hi Ron,
<br><br>Good idea but it can't be that as it's an actively developed app which
<br>has edits saved many times per day. And in fact I'm using
<br>CGI::App:Dispatch and CGI::App::Server so the MyApp.pm part (where the
<br>cgiapp_get_query method sits) isn't executable anyway. Maybe something
<br>to do with CAD?
<br>--
<br>Richard Jones
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26415608Re: CGI::Simple as replacement for CGI not working?2009-11-18T12:56:55Z2009-11-18T12:56:55ZRon SavageHi Richard
<br><br><br>Quoting "Richard Jones" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26415608&i=0" target="_top" rel="nofollow">ra.jones@...</a>>:
<br><br>> App working fine with default CGI, but decided to see if it works with
<br>> CGI::Simple using the cgiapp_get_query() override. But instead of
<br>> rendering the page I get a popup: 'you have chosen to open
<br>> myapp_server.pl which is a Perl script ... what should Firefox do with
<br>> this file'. I can't fathom where the problem lies. Anyone been there before?
<br><br>My guess is that when you saved your edits, the execute bit on the
<br>file was turned off.
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26413636CGI::Simple as replacement for CGI not working?2009-11-18T10:59:14Z2009-11-18T10:59:14ZJolly.TallApp working fine with default CGI, but decided to see if it works with
<br>CGI::Simple using the cgiapp_get_query() override. But instead of
<br>rendering the page I get a popup: 'you have chosen to open
<br>myapp_server.pl which is a Perl script ... what should Firefox do with
<br>this file'. I can't fathom where the problem lies. Anyone been there before?
<br>--
<br>Richard Jones
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26393752multi-threading2009-11-17T09:10:59Z2009-11-17T09:10:59ZNP BamberI would have thought it would be more scaleable to set up a server
<br>process (perhaps POE) with a SOAP or HTTP interface to do the threading.
<br>Another possibility might be AJAX.
<div class='shrinkable-quote'><br>> Message: 2
<br>> Date: Tue, 17 Nov 2009 11:22:59 +0000
<br>> From: Mike Tonks <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26393752&i=0" target="_top" rel="nofollow">fluffymike@...</a>>
<br>> Subject: [cgiapp] Threading Question
<br>> To: CGI Application <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26393752&i=1" target="_top" rel="nofollow">cgiapp@...</a>>
<br>> Message-ID:
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26393752&i=2" target="_top" rel="nofollow">727692630911170322u459084f2yfc98bbc2a8e69925@...</a>>
<br>> Content-Type: text/plain; charset=ISO-8859-1
<br>>
<br>> Hi Folks,
<br>>
<br>> I'm just considering a problem that I think requires a bit of multi-threading.
<br>>
<br>> It's a new one for me so wondered if anyone has advice or experience
<br>> of using threading with CGI::Application.
<br>>
<br>> Scenario is: We have 5 database servers at different sites. We would
<br>> like to create a search function that queries all of the databases.
<br>> The web server is on an intranet and can open connections to all of
<br>> the database servers.
<br>>
<br>> So - I imagine it would be sensible to fire 5 queries on 5 threads,
<br>> and wait for them all to return? Then combine the results in some
<br>> way. The results sets will be fairly small, say no more than 50
<br>> records.
<br>>
<br>> Seems likely to be quicker than to fire one, wait for it, fire
<br>> another, and so on.
<br>>
<br>> Also I guess there could be server issues with the use of multiple threads?
<br>>
<br>> cheers,
<br>>
<br>> mike
<br>>
<br>>
<br>>
<br>>
</div><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26391900Re: Threading Question2009-11-17T07:31:02Z2009-11-17T07:31:02ZKurt LidlOn Tue, Nov 17, 2009 at 11:22:59AM +0000, Mike Tonks wrote:
<br>> I'm just considering a problem that I think requires a bit of multi-threading.
<br>>
<br>> It's a new one for me so wondered if anyone has advice or experience
<br>> of using threading with CGI::Application.
<br><br>I expect that you'll run afoul of DBI's limitation on working
<br>with threaded perl. While it kinda works, the DBI documentation
<br>says that using threads with DBI (even if you work around
<br>the various issues with making it work) isn't recommended for
<br>production environments.
<br><br>> Scenario is: We have 5 database servers at different sites. We would
<br>> like to create a search function that queries all of the databases.
<br>> The web server is on an intranet and can open connections to all of
<br>> the database servers.
<br><br>Why not just open up 5 database handles and execute the queries.
<br>The queries should run in parallel, and you can choose how to
<br>interleave the processsing of the result sets however you want.
<br><br>> Also I guess there could be server issues with the use of multiple threads?
<br><br>There's also the DBIx::Threaded stuff, which spawns off additional
<br>threads and gives you an API for accessing those threads (and the
<br>database handles bound to them), but it all looks pretty scary to me.
<br><br>-Kurt
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26388279Threading Question2009-11-17T03:22:59Z2009-11-17T03:22:59ZMike Tonks-2Hi Folks,
<br><br>I'm just considering a problem that I think requires a bit of multi-threading.
<br><br>It's a new one for me so wondered if anyone has advice or experience
<br>of using threading with CGI::Application.
<br><br>Scenario is: We have 5 database servers at different sites. We would
<br>like to create a search function that queries all of the databases.
<br>The web server is on an intranet and can open connections to all of
<br>the database servers.
<br><br>So - I imagine it would be sensible to fire 5 queries on 5 threads,
<br>and wait for them all to return? Then combine the results in some
<br>way. The results sets will be fairly small, say no more than 50
<br>records.
<br><br>Seems likely to be quicker than to fire one, wait for it, fire
<br>another, and so on.
<br><br>Also I guess there could be server issues with the use of multiple threads?
<br><br>cheers,
<br><br>mike
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26375747can't search or edit the wiki; CGI::Simple difference2009-11-16T09:14:53Z2009-11-16T09:14:53ZMark RajcokI get errors if I try to search or edit the wiki, e.g.
<br> <a href="http://cgi-app.org/index.cgi?action=edit&page_name=CGIpmAlternatives" target="_top" rel="nofollow">http://cgi-app.org/index.cgi?action=edit&page_name=CGIpmAlternatives</a><br><br>I sent email to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26375747&i=0" target="_top" rel="nofollow">webmaster@...</a> but it bounced.
<br><br><br>I wanted to make a note on the wiki about a difference I found between
<br>CGI::Simple and normal CGI.
<br>I'm using apache mod_rewrite and PATH_INFO to get "clean URLs", e.g.
<br> <a href="http://mysite.com/account/edit" target="_top" rel="nofollow">http://mysite.com/account/edit</a><br>turns into a call to account.cgi, and runmode "edit" is executed.
<br><br>I was also guarding against cross site scripting by doing something like the
<br>following
<br>sub edit {
<br> ...
<br> if($self->query->url_param > 0) { error condition, looks like x-site
<br>scripting }
<br><br>With CGI::Simple, the above works.
<br><br>I recently switched over to Fast::CGI and following the wiki instructions
<br> <a href="http://cgi-app.org/index.cgi?FastCGI" target="_top" rel="nofollow">http://cgi-app.org/index.cgi?FastCGI</a><br>I'm no longer using CGI::Simple.
<br><br>The above "if" statement started triggering in my unit test code.
<br><br>url_param() is returning a parameter named "keywords". I finally tracked
<br>this down to "If the script was invoked as an <ISINDEX> script and contains
<br>a string without ampersands (e.g. "value1+value2+value3") , there will be a
<br>single parameter named "keywords" containing the "+"-delimited keywords."
<br><br>I guess this is because I'm using PATH_INFO... not sure. CGI::Simple
<br>doesn't return a "keywords" param, but CGI.pm does.
<br><br>So, the fix is
<br> if($self->query->url_param > 1) { error condition }
<br> # note, param "keywords" is present when using CGI.pm, but not when
<br>using CGI::Simple
<br><br>-- Mark
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26311599Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T16:52:26Z2009-11-11T16:52:26ZAlex-539<div class='shrinkable-quote'>> > This is a pathetic argument!
<br>>
<br>> If die_on_bad_params makes it harder for designers to use and less like
<br>> the tools they are used to using, how can that be a "pathetic" argument.
<br>>
<br>> > Just because X is non-strict does not justify refusing to use strict
<br>> > in Y, when the whole point of strictness is to help improve software
<br>> > reliability.
<br>>
<br>> Looking back at all of my projects that use HTML::Template I can
<br>> honestly say that die_on_bad_params has caused more problems then it's
<br>> fixed for me. It's not an argument against reliability but rather for
<br>> it. If a valid template change causes an ISE (rather than just an
<br>> invalid display) I'd say your software is less reliable. You now need a
<br>> developer to fix what was supposed to be a design problem.
</div><br>That ist he argument I always hear from people not using strict when getting
<br>the advice to use strict. Of course, if no strict was used, using strict
<br>causes problems, e.g. by aborting for each non declared variable. But that
<br>is not the point. The point is, to avoid errors and bugs and unvorseen
<br>behavior by using strict in the first place.
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26310115Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T14:42:44Z2009-11-11T14:42:44ZRon SavageHi Michael
<br><br>> Looking back at all of my projects that use HTML::Template I can
<br>> honestly say that die_on_bad_params has caused more problems then it's
<br>> fixed for me. It's not an argument against reliability but rather for
<br>> it. If a valid template change causes an ISE (rather than just an
<br>> invalid display) I'd say your software is less reliable. You now need a
<br>> developer to fix what was supposed to be a design problem.
<br><br>Oh. I go by the fact that at least 99% of the template problems I've
<br>caught by testing, i.e. before putting the template into production.
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26309950Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T14:30:59Z2009-11-11T14:30:59ZMichael PetersOn 11/11/2009 05:02 PM, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26309950&i=0" target="_top" rel="nofollow">ron@...</a> wrote:
<br><br>> This is a pathetic argument!
<br><br>If die_on_bad_params makes it harder for designers to use and less like
<br>the tools they are used to using, how can that be a "pathetic" argument.
<br><br>> Just because X is non-strict does not justify refusing to use strict
<br>> in Y, when the whole point of strictness is to help improve software
<br>> reliability.
<br><br>Looking back at all of my projects that use HTML::Template I can
<br>honestly say that die_on_bad_params has caused more problems then it's
<br>fixed for me. It's not an argument against reliability but rather for
<br>it. If a valid template change causes an ISE (rather than just an
<br>invalid display) I'd say your software is less reliable. You now need a
<br>developer to fix what was supposed to be a design problem.
<br><br>--
<br>Michael Peters
<br>Plus Three, LP
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26309502Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T14:02:59Z2009-11-11T14:02:59ZRon SavageHi Michael
<br><br>Quoting "Michael Peters" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26309502&i=0" target="_top" rel="nofollow">mpeters@...</a>>:
<br><br>> On 11/11/2009 10:46 AM, P Kishor wrote:
<br>>
<br>>> I use it exclusively, under the assumption that, like 'use strict', it
<br>>> is just best practice,
<br>>
<br>> But a real question I have is, should designers (who are the ones
<br>> creating these, or at least that's one of it's benefits is that they
<br>> can) be burdened with "strict" when the environment they operate in
<br>> (HTML, CSS) is inherently not "strict".
<br><br>This is a pathetic argument!
<br><br>Just because X is non-strict does not justify refusing to use strict
<br>in Y, when the whole point of strictness is to help improve software
<br>reliability.
<br><br>I.e. it's not a case of less strictness is better, but rather, more is
<br>- without being fanatical of course...
<br><br>Strictness is not the burden, bugs are :-).
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26306438Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T10:43:48Z2009-11-11T10:43:48ZBugzilla from mark@summersault.comOn Wed, 11 Nov 2009 02:30:21 +0000
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26306438&i=0" target="_top" rel="nofollow">ron@...</a> wrote:
<br><div class='shrinkable-quote'><br>> Hi Mark
<br>>
<br>> Quoting "Mark Stosberg" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26306438&i=1" target="_top" rel="nofollow">mark@...</a>>:
<br>>
<br>> > To proceed, I'd like to hear at least a small chorus of voices
<br>> > claiming that the they use
<br>> > the die_on_bad_params feature.
<br>>
<br>> I always use it, since in testing I want to know immediately if there
<br>> is a problem.
<br>>
<br>> I assume those who don't use it do so in order to avoid having to set
<br>> every parameter in the template. Is that right?
</div><br>As a standard part of our toolkit, we make all of our config variables
<br>always available to the template, with a cfg_ prefix appended to their
<br>name.
<br><br>So, the designer knows for instance she has the option to put
<br><!-- tmpl_var cfg_root_uri -->
<br>in the template, but it is not required on every page.
<br><br>If we need to precisely test the template, we can use a simple regex
<br>match to check that tokens appear in the file, our we can use
<br>html_tmpl_class() and HTML::Template::Dumper for a more formal
<br>approach.
<br><br> Mark
<br><br>--
<br> . . . . . . . . . . . . . . . . . . . . . . . . . . .
<br> Mark Stosberg Principal Developer
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26306438&i=2" target="_top" rel="nofollow">mark@...</a> Summersault, LLC
<br> 765-939-9301 ext 202 database driven websites
<br> . . . . . <a href="http://www.summersault.com/" target="_top" rel="nofollow">http://www.summersault.com/</a> . . . . . . . .
<br><br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26303834Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T08:02:17Z2009-11-11T08:02:17ZMichael PetersOn 11/11/2009 10:46 AM, P Kishor wrote:
<br><br>> I use it exclusively, under the assumption that, like 'use strict', it
<br>> is just best practice,
<br><br>But a real question I have is, should designers (who are the ones
<br>creating these, or at least that's one of it's benefits is that they
<br>can) be burdened with "strict" when the environment they operate in
<br>(HTML, CSS) is inherently not "strict".
<br><br>> may make my code faster
<br><br>I seriously doubt this. Especially if your code has to do lots of
<br>$tmpl->query() stuff to make sure that a variable is present before
<br>doing a $tmpl->param().
<br><br>> and less error-ridden,
<br><br>The only error I know that this catches is a misspelling on the
<br>programmer's side. Which I'll admit is a real problem. But in most of my
<br>cases, it's a problem that's easily seen because the data does not show
<br>up where it should.
<br><br>> and may endow me with good looks and untold riches
<br><br>Maybe if you rub Sam Tregar's belly. But I'd be careful, he's got a mean
<br>right hook :)
<br><br>--
<br>Michael Peters
<br>Plus Three, LP
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26303530Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T07:46:01Z2009-11-11T07:46:01ZP Kishor-3..
<br>>> I don't know how many people use die_on_bad_params, so I don't
<br>>> know how worth it it is to modify the core.
<br>..
<br><br>I use it exclusively, under the assumption that, like 'use strict', it
<br>is just best practice, may make my code faster and less error-ridden,
<br>and may endow me with good looks and untold riches. I have no
<br>scientific basis for the above assumptions.
<br><br><br>--
<br>Puneet Kishor <a href="http://www.punkish.org" target="_top" rel="nofollow">http://www.punkish.org</a><br>Carbon Model <a href="http://carbonmodel.org" target="_top" rel="nofollow">http://carbonmodel.org</a><br>Charter Member, Open Source Geospatial Foundation <a href="http://www.osgeo.org" target="_top" rel="nofollow">http://www.osgeo.org</a><br>Science Commons Fellow, <a href="http://sciencecommons.org/about/whoweare/kishor" target="_top" rel="nofollow">http://sciencecommons.org/about/whoweare/kishor</a><br>Nelson Institute, UW-Madison <a href="http://www.nelson.wisc.edu" target="_top" rel="nofollow">http://www.nelson.wisc.edu</a><br>-----------------------------------------------------------------------
<br>Assertions are politics; backing up assertions with evidence is science
<br>=======================================================================
<br>Sent from Madison, Wisconsin, United States
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26303445Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T07:41:00Z2009-11-11T07:41:00ZGurunandan R. Bhat-2On Tue, 2009-11-10 at 20:56 -0500, Mark Stosberg wrote:
<br><br>> To proceed, I'd like to hear at least a small chorus of voices claiming that the they use
<br>> the die_on_bad_params feature.
<br>>
<br><br><br>I use it all the time as an alternative to an if-then-else: if a piece
<br>of content is not to be displayed, I just dont define its template
<br>variable.
<br>But from the tone of your and following messages, I sense that I am
<br>doing something Seriously Bad (TM). If that is the case, I would be
<br>happy to hear reasons.
<br><br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26301969Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T06:17:17Z2009-11-11T06:17:17ZMichael PetersOn 11/10/2009 08:56 PM, Mark Stosberg wrote:
<br><br>> To proceed, I'd like to hear at least a small chorus of voices claiming that the they use
<br>> the die_on_bad_params feature.
<br><br>I use it sometimes, but grudgingly. If the goal is to separate the
<br>design from the application behind that design, then this feature fails.
<br>My designer has to include everything I pass to him in his template
<br>somewhere. Even if we decide that something isn't necessary any more on
<br>a certain page then he still has to include it or things break.
<br><br>Of course we can update the backend code too, but then you can't update
<br>one without updating the other. It makes phased rollouts difficult. And
<br>if you have several sites with different templates using the same
<br>backend code it gets even worse.
<br><br>--
<br>Michael Peters
<br>Plus Three, LP
<br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26298657Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-11T01:49:17Z2009-11-11T01:49:17ZAlex-539Hi!
<br><br>Mostly the same here. I like it for testing and the only reason I can think
<br>of why it should be disabled is that you want to avoid setting params
<br>specific for your template.
<br>I kind of like the strict behavior on a second way: it remind me of "use
<br>strict" with scopes 'n stuff, but that may be just a subjective preference.
<br><br>Hth, Alex
<br><br>-----Ursprüngliche Nachricht-----
<br>Von: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26298657&i=0" target="_top" rel="nofollow">cgiapp-bounces@...</a>
<br>[mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26298657&i=1" target="_top" rel="nofollow">cgiapp-bounces@...</a>] Im Auftrag von <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26298657&i=2" target="_top" rel="nofollow">ron@...</a>
<br>Gesendet: Mittwoch, 11. November 2009 03:30
<br>An: CGI Application
<br>Betreff: Re: [cgiapp] proposal for new cgiapp hook: loaded_html_tmpl
<br><br>Hi Mark
<br><br>Quoting "Mark Stosberg" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26298657&i=3" target="_top" rel="nofollow">mark@...</a>>:
<br><br>> To proceed, I'd like to hear at least a small chorus of voices
<br>> claiming that the they use
<br>> the die_on_bad_params feature.
<br><br>I always use it, since in testing I want to know immediately if there
<br>is a problem.
<br><br>I assume those who don't use it do so in order to avoid having to set
<br>every parameter in the template. Is that right?
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br>Eingehende eMail ist virenfrei.
<br>Von AVG überprüft - www.avg.de
<br>Version: 9.0.704 / Virendatenbank: 270.14.59/2494 - Ausgabedatum: 11/10/09
<br>08:38:00
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26295823Re: Is C::A::PSGI available?2009-11-10T20:18:50Z2009-11-10T20:18:50ZGurunandan R. Bhat-2Indeed, now it does.
<br>Thanks.
<br><br><br>On Tue, 2009-11-10 at 20:39 -0500, Mark Stosberg wrote:
<br><div class='shrinkable-quote'><br>> On Sat, 07 Nov 2009 10:48:02 +0530
<br>> "Gurunandan R. Bhat" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26295823&i=0" target="_top" rel="nofollow">guru@...</a>> wrote:
<br>>
<br>> >
<br>> > Hi,
<br>> >
<br>> > Is CGI::Application::PSGI available? The link from the Plack website
<br>> > gives a 404.
<br>>
<br>> Are you referring to this link?
<br>>
<br>> <a href="http://search.cpan.org/dist/CGI-Application-PSGI" target="_top" rel="nofollow">http://search.cpan.org/dist/CGI-Application-PSGI</a><br>>
<br>> It works now. Miyagawa wrote the module, but asked me to upload and maintain it.
<br>> I endorse the Plack/PSGI project ( <a href="http://www.plackperl.org/" target="_top" rel="nofollow">http://www.plackperl.org/</a> )
<br>>
<br>> Mark
<br>>
</div><br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>tag:old.nabble.com,2006:post-26295051Re: proposal for new cgiapp hook: loaded_html_tmpl2009-11-10T18:30:21Z2009-11-10T18:30:21ZRon SavageHi Mark
<br><br>Quoting "Mark Stosberg" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26295051&i=0" target="_top" rel="nofollow">mark@...</a>>:
<br><br>> To proceed, I'd like to hear at least a small chorus of voices
<br>> claiming that the they use
<br>> the die_on_bad_params feature.
<br><br>I always use it, since in testing I want to know immediately if there
<br>is a problem.
<br><br>I assume those who don't use it do so in order to avoid having to set
<br>every parameter in the template. Is that right?
<br><br><br>##### CGI::Application community mailing list ################
<br>## ##
<br>## To unsubscribe, or change your message delivery options, ##
<br>## visit: <a href="http://www.erlbaum.net/mailman/listinfo/cgiapp" target="_top" rel="nofollow">http://www.erlbaum.net/mailman/listinfo/cgiapp</a> ##
<br>## ##
<br>## Web archive: <a href="http://www.erlbaum.net/pipermail/cgiapp/" target="_top" rel="nofollow">http://www.erlbaum.net/pipermail/cgiapp/</a> ##
<br>## Wiki: <a href="http://cgiapp.erlbaum.net/" target="_top" rel="nofollow">http://cgiapp.erlbaum.net/</a> ##
<br>## ##
<br>################################################################
<br><br><p>From forum: <a href="http://old.nabble.com/cgiapp%40lists.erlbaum.net-f13613.html" embed="fixTarget[13613]" target="_top" >cgiapp@lists.erlbaum.net</a></p>