[cgiapp] RunmodeDeclare and ValidateRM incompatibility?

[Richard Jones]

In the following example code, which uses CAP::RunmodeDeclare for 
runmode handling:

#-----------------------------------------------------------------------
runmode edit ($id) {
   my $errs = shift;

   $id || return $self->error('no id passed to edit'); # warn 'id:'.$id;

   my $data = $self->model->get_some_data($id);

   [ .. ]
   return $self->tt_process($errs);
}

#-----------------------------------------------------------------------
runmode update ($id) {
   # if param 'id' passed, return error to edit():
   my $error_rm = $id ? 'edit' : 'default';

   my $dfv = $self->check_rm( $error_rm, '_update_validate_profile' )
   || return $self->dfv_error_page;

   [ .. ]
}

A url of '/myapp/update/1' via CA::Dispatch calls the 'update' runmode, 
which captures the param '1' into the var $id. All works as advertised.

But if validation in update() fails, the 'update' runmode is required to 
return the dfv error page for 'edit', but it doesn't, instead a fatal 
error results from the consequence of edit() capturing the value of dfv 
errors in $id, which then kills the model method as it tries to execute 
an sql statement using the dfv errors hashref instead of an id value.

The problem seems to be that, according to the docs, RunmodeDeclare will 
capture variables passed as $self->baz(1, "me") as well as from the 
query object. So 'edit ($id)' means $id will capture anything passed 
into the rm. What seems odd is that the dfv errors hashref is also 
captured in the first arg shifted from @_:

runmode edit ($id) {
   my $errs = shift;

   warn Dumper $id; # contains the dfv errors hashref
   warn Dumper $errs; # also contains the dfv errors hashref !!

   [ .. ]
}

Of course it all works fine if I switch back to conventional runmode 
handling, or to AutoRunmode.

It seems amazing that I haven't encountered this before - presumably 
none of my RunmodeDeclare-based form-handling methods ever failed form 
validation before.
-- 
Richard Jones