So...... if I create my own style of "fatalsToBrowser".
Is that possible to do in this way :

Make PrintContentT.pm, which is just a simple sub to print the
Content-type:blah.... but pushing a contenttype =>1 to %ENV.

At all the other CGI scripts, use PrintContentT.pm to print the header,
instead, and PrintContentT, it check if exists of contentype. If exists,
won't priint the header again, else, print the header.....

Is that Okay .... logically ?

TIA


----- Original Message ----- 
From: "Wiggins d'Anconia" <[EMAIL PROTECTED]>
To: "LI NGOK LAM" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 30, 2003 8:20 AM
Subject: Re: How does CGI.pm handles Content-type: text/html\n\n ?


> LI NGOK LAM wrote:
> > I have read throught the CGI::Carp::fatalsToBrowser.......
> > not quite understand all, but I wonder how does this script
> > handles the "Content-type: text/html\n\n"......
> > So in the some case s(such as warnings) this header line won't re-print
?
> >
>
> Read the docs or the source? Remember this is open source and in this
> case the module is Perl so don't forget you can have a look there too.
>
> Essentially the module caches the warnings, etc. until either you
> explicitly request they be printed, or until a simulated 'die' (a
> "fatalToBrowser") is called at which time if there are warnings and you
> asked for them they are also printed.
>
> I assume from looking at the source there is no way to prevent a double
> header print on a 'die' after a header, except just don't do it.
> theoretically anything coming after the header is printed shouldn't call
> die anyways, to me that would be an uncaught/unhandle exception which
> shouldn't happen, that is what testing is for :-)...
>
> http://danconia.org
>
> On warnings from the docs:
>
> "MAKING WARNINGS APPEAR AS HTML COMMENTS
>
>
> It is now also possible to make non-fatal errors appear as HTML
> comments embedded in the output of your program.  To enable this
> feature, export the new "warningsToBrowser" subroutine.  Since sending
> warnings to the browser before the HTTP headers have been sent would
> cause an error, any warnings are stored in an internal buffer until
> you call the warningsToBrowser() subroutine with a true argument:
>
>
>     use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
>     use CGI qw(:standard);
>     print header();
>     warningsToBrowser(1);
>
>
> You may also give a false argument to warningsToBrowser() to prevent
> warnings from being sent to the browser while you are printing some
> content where HTML comments are not allowed:
>
>
>     warningsToBrowser(0);    # disable warnings
>     print "<script type=\"text/javascript\"><!--\n";
>     print_some_javascript_code();
>     print "//--></script>\n";
>     warningsToBrowser(1);    # re-enable warnings
>
>
> Note: In this respect warningsToBrowser() differs fundamentally from
> fatalsToBrowser(), which you should never call yourself!"
>
>
>
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to