Re: [Nms-cgi-devel] Welcome

[Jonathan S. <gel...@ge...>]

On Tue, 13 Nov 2001, Dave Cross wrote:
> From: Jonathan Stowe <gel...@ge...>
>
> > and added CGI::Carp in those places where the script
> > might die() this will at least produce something
> > moderately less confusing than a plain 500 in the event
> > of failure
>
> I don't like this idea. I think that web servers give vanilla
> 500 errors for a good reason. The more information a user gets
> from an error message then the more information they have about
> the workings of the script and the more chance they have of cracking
> the site.
>
> I'm happy to have CGI::Carp included in the scripts and used
> for development and debugging - but I'd like it commented out
> of anything checked into CVS.
>

I've got a better idea:

use CGI::Carp qw(fatalsToBrowser set_message);

use vars qw($DEBUGGING);

BEGIN
{
   $DEBUGGING = 1;

   $error_handler = sub
                    {
                      my ($mesg) = @_;
                      print "text/html\n\n";
                      print "<strong>Something nasty happened</strong>";

                      print "Perl said : $message" if $DEBUGGING;
                    }

    set_message($error_handler);
}

I'm not sure when that feature came about :)

Then you get the best of both worlds :)  It has to be borne in mind that
someone installing the application and configuring it is likely to find
themselves debugging their install environment - it would be nice to be
able to tell them to just alter the $DEBUGGING variable to display
suitable diagnostics - not that I'm subscribed to the support list ;-}

> > - I think in the long term it would be best to come up
> > with a slightly different and more configurable strategy
> > that can be used consistently across the programs.
>
> Agreed.
>

With the above we can postpone that awhile although someone might want to
look at making some standard niceness we can use across the whole , er,
suite ;-}

> > I think something that we ought to be looking at in the
> > programs is introducing better ways of doing things - it
> > is not absolutely necessary that we emulate the original
> > programs down to the strange methods of storage (for
> > instance) if they are being deployed in a green field site
> > that has not yet been tainted with Matt's scripts.
>
> But don't forget, that we are supposed to be creating _drop-in_
> replacements for MSA. I see a lot our users being people who
> have Matt's scripts in place who want to move to something "better"
> (for some meaning of the word). It's therefore important that
> we can deal with all of Matt's baroque interface ideas.
>

You started typing that before you finished reading the (albeit overlong)
sentence didn't you :)


> > You will for instance see in 'ffa.pl' the variable
> > $emulate_matts_ffa : although not completely implemented
> > yet when this is switched off the program will store its
> > data in a flat file and generate the HTML page on the fly
> > rather than updating the HTML page directly as it does
> > now.  The guestbook and wwwboard should have this option
> > as well although we do have to retain compatibility with
> > Matt's peculiar storage mechanisms if we are to hope to
> > encourage to upgrade to our programs :)  I thought I had
> > started doing this with the guestbook but I can't find
> > the code anywhere :(
>
> Agreed. Maybe rename the variable to $emulate_matts_code and
> use the same one in all scripts. The default should, of course,
> be on.
>

done.

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |