Mike Friedman wrote: > A desire for a CAP::ErrorPage is listed on the "wanted plugins" page ( > http://cgiapp.erlbaum.net/cgi-bin/cgi-app/index.cgi?PluginsWanted). > > Is anybody currently working on it? > > If not, I may take a whack at it this weekend, as I have use for such a > plugin. But I don't want to start if someone's got something in the works.
Mike, Thanks for helping. I'm not aware that anyone else is working on it. I think I created that suggestion long ago. Below is my "real world" "error" routine I use for this case for reference. Feel free to adjust as needed or ignore. It makes a reference to another un-published technique we use here, which involves automatically generating a '<base href="">' tag to use with Templates. Here's why that's useful. We use Dreamweaver to manage static files and out application templates, and that works really well. However, Dreamweaver constructs relative links and image paths based on where the file is stored on the file system. The relative paths are really nice, but the location of the file on the file system often has little to do with how is served through a URL. So to keep all the path references from breaking, we construct a <base href=""> tag that matches where the file is stored on the file system, and then insert it through through a template token. What's extra nice about this system is that we can include this token a Dreamweaver template that is also used on static pages, where it will be ignored as a comment. Because this is part of our standard CGI::App-based framework, link and path issues between static and dynamic parts of the site always work as seamlessly as possible. But with all that said, I'm not sure the tmpl_path() hack below necessarily belongs in a more widely used solution. I can also tell you from real world use of this: - I never use the 'debug' solution here. I end up just looking at the server logs. Consider removing this part. We already have a "DebugScreen" plugin. - I would consider excluding the "contact_email" too. I think automatically adding config variables to the template should be in a separate plugin. (We do that, too). Speaking of the things we do here at Summersault-- if you happen to be near Richmond, Indiana, we're hiring: http://www.summersault.com/about/careers.html Mark sub error { my $self = shift; my %args = ( debug => $DEBUG, tmpl => 'error.html', @_ ); # This is a hack to make our base href value turn out in a way # that is more likely to be correct. # What happens is that is when an error is thrown, a tmpl_path # may have been set. HTML::Template is smart enough to look for error.html # and find it in the root of the tree, but our base href calculator doesn't # cope with multiple template paths. # So, we set the tmpl_path to the root directory, where error.html is. # Schwew. # We are careful to put the value back how we found it after we are done with it here! my @path_to_restore = $self->tmpl_path(); $self->tmpl_path(''); my $tmpl = $self->load_tmpl($args{tmpl}); $self->tmpl_path(@path_to_restore); if ($args{debug}) { my ($package, $file, $line, $sub) = (caller(2))[0,1,2,3]; $args{debugging_text} = "Package: $package<BR> File: $file <BR>Line: $line <BR> Subroutine: $sub<P>" .$self->query->Dump; } $args{page_title} = $args{title}; $tmpl->param(%args,contact_email=> $self->cfg('CONTACT_EMAIL')); return $tmpl->output; } --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
