I initially tried to get Apache 2.0.50's ErrorDocument to work, but I
wasn't able to pass a parameter to it. (ErrorDocument 500
/cgi-bin/main.cgi?mode=error didn't work, for some reason ...) So, I
wanted to trap Perl runtime errors.
Your suggestion of an error run-mode is orthogonal to my goal,
On 2004-08-23, Kinyon, Rob [EMAIL PROTECTED] wrote:
I initially tried to get Apache 2.0.50's ErrorDocument to work, but I
wasn't able to pass a parameter to it. (ErrorDocument 500
/cgi-bin/main.cgi?mode=error didn't work, for some reason ...) So, I
wanted to trap Perl runtime errors.
Your
Mark Stosberg wrote:
On 2004-08-23, Kinyon, Rob [EMAIL PROTECTED] wrote:
Thanks for the response. Your counter-points are sound. While I
understand your proposal would be backwards compatible, I have concerns
that it could promote what I think is poor application design-- sending
un-trapped perl
I'm working on an application that has a report generation mode that
generates a report as an Excel spreadsheet that is then sent to the
client. I can think of several ways to do this, but the idea I'm
currently toying with is having my CGI::App exec a separate script that
generates the report.
Tim,
In the past, I've done report-generation offline - usually triggered by a
cron job, or something else. Write it to a pre-determined location, and
then if I'm using CGI::Application, it's soley for the purposes of either
access control, or to add the new file in a list of downloadable
I have implemented a die handler for a group of
modules that I have integrated. Just like I wanted
them to all use the same config file and object, I
wanted them to die the same way.
This proved trickier than it sounds given mod_perl's
special way of diing - using the Apache exit function.
Michael Peters wrote:
Mark Stosberg wrote:
On 2004-08-23, Kinyon, Rob [EMAIL PROTECTED] wrote:
Thanks for the response. Your counter-points are sound. While I
understand your proposal would be backwards compatible, I have concerns
that it could promote what I think is poor application design--
I think it would be a good idea to have this as part of C::A, mostly due to the
reasons tha Cees sited; that it is very simple to understand and use once it has been
written, but it is not necessaraly obvious before it is written.
I do find it interesting that most programmers that use C::A
Use Excel::Template - it takes the exact same data structure as
HTML::Template. The only changes needed are:
1) The content-type
2) The module you're using (Excel::Template vs. HTML::Template)
That's about it. :-)
If you have any questions, let me know. I'm the author of E::T (as well
as
I would change that slightly. What I have is the following:
my $body;
eval {
if ($self-can($rmeth)) {
$body = $autoload_mode ? $self-$rmeth($rm) : $self-$rmeth();
}
else {
$body = eval { $autoload_mode ? $self-$rmeth($rm) :
$self-$rmeth() };
die Error
On 2004-08-23, Tim Howell [EMAIL PROTECTED] wrote:
I'm working on an application that has a report generation mode that
generates a report as an Excel spreadsheet that is then sent to the
client. I can think of several ways to do this, but the idea I'm
currently toying with is having my
Rob --
On 2004-08-23, Kinyon, Rob [EMAIL PROTECTED] wrote:
I would change that slightly. What I have is the following:
my $body;
eval {
if ($self-can($rmeth)) {
$body = $autoload_mode ? $self-$rmeth($rm) : $self-$rmeth();
}
else {
$body = eval {
On Mon, 23 Aug 2004 09:48:36 -0700, Tim Howell wrote:
Hi Tim
You probably have enough ideas to go on by now, but I might as well
throw in another.
Firstly a warning re MS Excel. By default, it splits on commas even
when those commas are inside quotes. My users put up with that.
I output CSV
Mark Stosberg wrote:
On 2004-08-23, Tim Howell [EMAIL PROTECTED] wrote:
I'm working on an application that has a report generation mode that
generates a report as an Excel spreadsheet that is then sent to the
client. I can think of several ways to do this, but the idea I'm
currently toying with
14 matches
Mail list logo
