On 2004-08-26, Kinyon, Rob <[EMAIL PROTECTED]> wrote:
> ------_=_NextPart_001_01C48B6F.A54FA8DE
> Content-Type: text/plain;
>       charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> I've attached a tar.gz of all the files I added and/or changed. I'm not
> sure of what format things are supposed to be in, so I just pulled all
> the new/modded files together in one directory and tar/gz'ed them up.
>
> Changed:
>       lib/CGI/Application.pm
>       MANIFEST
>       Changes
> New:
>       t/10errormode.t
>       test/TestApp11.pm
>       test/TestApp12.pm
>
> I've marked this version as 3.23 in Application.pm, if that's ok.

Rob,

Here's some feedback on this. First a point of administrivia:

I find the easiest patch submissions to work with are in the "unified
diff" format. In this case, you could generate one easily by using 
copies of the altered and unaltered directory tries:

diff -r --unified unaltered_dir altered_dir >my_patch.txt

Below is my own patch to your work to change a couple of things:

- I took out setting the default for error_mode(), since it's documented
  not to have one.

- I updated the documentation to reflect the fact that error_mode will
  be treated exactly like a normal run mode. Like other run modes, you
  are welcome to explicitly die and exit early if you want to. 

I also have a general discussion point about the logic. Should we really
"eval"  the error_mode(), and trap it's death? I thought some of
the point of it was allowing the user to "die in their own special way".
If we eval it, the options are limited.

What do others think? 

        Mark

-- 
http://mark.stosberg.com/ 

--- error_patch/Application.pm  Thu Aug 26 08:15:40 2004
+++ error_patch_modified/lib/CGI/Application.pm Thu Aug 26 19:17:53 2004
@@ -31,7 +31,6 @@
        $self->header_type('header');
        $self->mode_param('rm');
        $self->start_mode('start');
-       $self->error_mode('my_error_handler');

        # Process optional new() parameters
        my $rprops;
@@ -985,8 +984,8 @@
 croak().

 If the runmode dies for whatever reason, run() will see if you have set a
-value for error_mode(). If you have, run() will call that method and the
-data returned is print()'ed to STDOUT and to the browser.
+value for error_mode(). If you have, run() will call that method, the same
+way a run mode is normally invoked.

 =back

@@ -1019,7 +1018,7 @@
                my $self = shift;
                $self->tmpl_path('/path/to/my/templates/');
                $self->start_mode('putform');
-               $self->error_mode('my_error_handler');
+               $self->error_mode('my_error_rm');
                $self->run_modes({
                        'putform'  => 'my_putform_func',
                        'postdata' => 'my_data_func'
@@ -1556,12 +1555,10 @@

 =item error_mode()

-    $webapp->error_mode('my_error_handler');
-
-The error_mode contains the name of a method.  It may or may not be a runmode.
-There is no default error_mode.  The method here will be used if the runmode
-that was run fails with a runtime error.
+    $webapp->error_mode('my_error_rm');

+The error_mode contains the name of a runmode to call in the event that
+the run mode call fails C<eval>. There is no default.

 =item tmpl_path()




---------------------------------------------------------------------
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]

Reply via email to