[cgiapp] RunmodeDeclare and ValidateRM incompatibility?

[Rhesa Rozendaal]

Richard Jones wrote:
> Richard Jones wrote:
> 
>> OK, first thoughts (without actually trying it), are that "runmode edit 
>> ($errs, $id)" would work OK for the error return from update(), but not 
>> when edit() is called from the query - as /myapp/edit/1 - since the 
>> value of '1' would get taken into $errs, leaving $id undef. No?
> 
> Actually, contrary to my initial expectation, it does seem to work. 
> Calling runmode edit ($errs, $id) with /myapp/edit/1 puts the value of 1 
> into $id, and $errs is undef. This, I imagine, is a 'feature' :)

Assuming you use something like CA::Dispatch (which you did mention in your 
OP), and a rule like:

   :app/:rm/:id

then yes, since CA::D puts that id in $self->param('id'). It uses that same 
label. And CAP::RD uses that label too through the variable names in the 
signature.


> Returning an error from update() also populates $errs with the error 
> hashref, and $id with the previous value of '1'. Very nice, and it means 
> I can still use CAP::RD with ValidateRM.
> 
> So I wondered what would happen if put a few more vars in the runmode 
> edit signature (?), like runmode edit ($foo, $bar, $errs, $id) { .. }


If you keep in mind that this gets translated internally to:

   sub edit {
     my $self = shift;
     my ($foo, $bar, $errs, $id) = @_;


then none of the following should be surprising :)


> On first call to edit from the form - /myapp/edit/1 - I get:
> 
> $VAR1 = undef;
> $VAR1 = undef;
> $VAR1 = undef;
> $VAR1 = '1';
> 
> but the error return from update() gives this:
> $VAR1 = {
>            'error_foo' => '« missing',
>            'dfv_errors' => 1
>          };
> $VAR1 = undef;
> $VAR1 = undef;
> $VAR1 = '1';
> 
> So the first var gets the error hashref and the fourth one gets the id. 
> Seems odd, but in practice it's not a problem as (hopefully) I wouldn't 
> do anything as silly in a real app.


The hashref goes into the first var, because it's being passed in 
positionally. The fourth variable gets the id from the query, because it's 
named $"id" in the signature. It's still a normal method call, so 
$self->edit(1,2,3,4) would result in $foo=1, $bar=2, $errs=3, $id=4. It's only 
when you don't supply arguments that the query param fallback comes into play.
Of course, with dfv you're going to see a mix of that, and that makes it a bit 
harder to figure out what's going on.

HTH,
Rhesa