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.

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

Reply via email to