[cgiapp] RunmodeDeclare and ValidateRM incompatibility?

[Rhesa Rozendaal]

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.