Re: bug with subrequests and MasonX::Request::WAS

Incidentally, if use subrequests as internal redirects (as I was), it 
works fine with that line never executing; but if you use subrequests as 
glorified component calls, you wouldn't want it to create a whole new 
session.

A similar thing happens with every plugin that has a start-request hook 
- should you execute the hook for a subrequest or not? It really depends 
on the caller's intention in creating a subrequest.

All I can say is "bleah".

Jon

Jonathan Swartz wrote:
> The big check-in triggered a bug in MasonX::Request::WithApacheSession 
> and subrequests. Its new() method looks like:
> 
> sub new
> {
>     my $class = shift;
> 
>     $class->alter_superclass( $HTML::Mason::ApacheHandler::VERSION ?
>                               'HTML::Mason::Request::ApacheHandler' :
>                               $HTML::Mason::CGIHandler::VERSION ?
>                               'HTML::Mason::Request::CGI' :
>                               'HTML::Mason::Request' );
> 
>     my $self = $class->SUPER::new(@_);
> 
>     return if $self->is_subrequest;
> 
> That last line is incorrectly returning undef. I think you want "return 
> $self".
> 
> The reason this never came up before is because in the stable branch, we 
> only set parent_request (which is_subrequest checks) after the request 
> is created. In HEAD, parent_request is part of the params to the request 
> constructor, so is_subrequest will be true.
> 
> Actually this bug would be triggered currently with a 
> subrequest-inside-a-subrequest-inside-a-request. :)
> 
> So we'll need to fix this before releasing 1.3.
> 
> Jon
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl