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
##### 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/ ##
## ##
################################################################
