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' :)
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) { .. }
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.
--
Richard Jones
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
