[cgiapp] CAD::Server strangeness

[Richard Jones]

George Hartzell wrote:
> Richard Jones writes:
>  > Well I've managed to narrow it down a bit - the problem was caused by 
>  > defining the path/to/templates twice - once in TMPL_PATH => [ 
>  > $path_to_templates ] in my Dispatch \%args_to_new hashref, and again in 
>  > the webapp.cfg tt_config TEMPLATE_OPTIONS. As I can't avoid passing 
>  > path/to/cfg in args_to_new, the fix is of course to omit TMPL_PATH.
>  > 
>  > I suspected this might be the case from the very simple demo app I put 
>  > together for you (mailed separately), where I could see that the first 
>  > request after server-start generated 2 '/path/to/templates' entries, the 
>  > second request generated 4, third request generated 8, then 16, 32, etc. 
>  > With my own app, the multiplication came much faster - the first request 
>  > generated 8 '/path/to/templates' entries, second generated 64, and I 
>  > didn't count the 3rd but would predict it was 512. There's probably a 
>  > simple reason for this, but it's not that I've defined path/to/templates 
>  > 8 times in my App!
>  > 
>  > However, the curious thing is - afaict, there is only one definition of 
>  > path/to/templates in the demo app (and that's in the Dispatcher not the 
>  > WebApp), so I've mailed it to you so you can investigate the phenomenon. 
>  > Failure to include TMPL_PATH in the demos' Dispatcher is fatal as the 
>  > WebApp can't find the templates, confirming that there is only a single 
>  > source of templates path info. My guess is that the problem lies in the 
>  > definition of TMPL_PATH in args_to_new() in the Dispatcher rather than 
>  > in the webapps' config file. I'd also take a guess that it's something 
>  > pretty simple to trace if you're handy with perl -d.
> 
> So....
> 
> There are at least a couple of problems conspiring here.
> 
> The simple one is in your demo app.  When one subclasses
> CGI::Application::Dispatch and overrides dispatch_args, one needs to
> make sure that it has the same semantics as what it's replacing.  In
> particular, it needs to return a complete set of dispatch arguments
> including a table entry.  One easy way is to just call
> $self->SUPER::dispatch_args to get an initial hash ref then override
> the fields you'd like to change.  

Something like the following?

sub dispatch_args {
     my $c = shift;
	
     my $args = $c->SUPER::dispatch_args;
	
     # override default with %args
     $args->{$_} = $args{$_} for keys %args; # warn Dumper $args;
	
     return $args;
}

Seems to do the required thing - $args contains all the necessary 
params, but I'm still getting duplicated TMPL_PATH args if I include it 
in dispatch_args. Possibly as I haven't yet done this (?):

> It should probably also do something
> intelligent with its own argument, which is hash of args that was
> passed in to the call to dispatch().

Not sure what 'intelligent' means here.

[...]

> So, what should be changed:
> 
>   1) Richard should change his dispatch_args() method so that it
>      matches the semantics of the one he's overriding.  In its current
>      form we've seen that it's problematic with ::Server and it won't
>      work at all under fastcgi using the fastcgi tricks discussed here
>      recently.

Done, but possibly not correctly as it still exhibits TMPL_PATH 
duplication. Temporary fix is to omit TMPL_PATH from dispatch_args and 
rely on it being defined in app.cfg file.

[...]

>    3) I think that CGI::Application::Dispatch::dispatch is being too
>       clever/helpful/broken in how it handles dispatch_args.  In
>       particular, if someone calls dispatch with a hash that contains an
>       args_to_new hash which in turn contains a TMPL_PATH array ref, then
>       dispatch() ends up duplicating that array's values.
> 
> Number 2) above is the quickest fix to the problem.  Mark?
> 
> Number 1) will be necessary once number 2) is in place and is already
> necessary if you want to run under fastcgi.
> 
> Number 3) seems to be a problem that no one has had yet but it's
> lurking.

Isn't that exactly what I've seen in my app though? Thanks for your help 
with this btw. Hopefully CAD & CADS end up improved as as result.