Ron Savage wrote:
Hi Folks
On Thu, 2009-06-18 at 01:00 +0200, Rhesa Rozendaal wrote:
Richard Jones wrote:
Richard Jones wrote:
[snip scary code]
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.
Surely this is a maintenance nightmare!
>
And what happens if someone else has to patch this sort of stuff?
Does the problem really lie with the adoption of RunmodeDeclare in the
first place?
I don't think so ;)
I'd suggest, Richard, you seriously consider ditching it, for the sake
of sanity and simplicity, at least.
That's a little harsh, considering CAP::RD is my module :(
I'd rather suggest that if you use CAP::RD and CAP::ValidateRM together, then
don't use a signature on your run modes, and fetch query params the old way.
That way you don't mix up method arguments and query params.
So like this:
runmode edit {
my $errs = shift;
my $id = $self->query->param('id');
...
This way, you still get run mode registration and $self for free.
Or only declare positional arguments:
runmode edit ($errs) {
my $id = $self->query->param('id');
...
I tend to only use the signature for query params when I only expect one or
two form variable anyway.
But keep CGI::Application::Dispatch. You're on a winner there.
Definitely.
##### 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/ ##
## ##
################################################################
