Re: autoflush behavior for subrequests

Sorry for the late reply on this...

On Thu, 16 Sep 2004, Jonathan Swartz wrote:

> Subrequests are not well defined in general. They sit somewhere in the
> nether region between component calls and separate requests, and
> everyone expects something a little different from them. :)
>
> In my experience, most people use subrequests for "internal redirects",
> and this is how they expect (or would like) them to work:

I think the other major use for subrequests is as normal components but
with autohandler content wrapping.  The expect behavior for that would
be:

> 1. Any current contents of the parent buffer are cleared.

Definitely would *not* want that to happen, but it's easy enough to do a
$m->clear_buffer (or not) before the subrequest.

> 2. The out_method of the subrequest is the same as the out_method of the
> parent.

I would want the output of the subrequest should go through
the parent's <%filter> sections, etc.

Are you saying the output should skip the parent's buffers entirely for
the internal_redirect style?

(I think it optimizes that way in the absence of <%filter> etc.)

> 3. autoflush or manual flush_buffers take effect immediately.

Yes.

> 4. If the subrequest returns successfully, the parent aborts (so as not
> to generate any more output) with the return value (if any) of the
> subrequest.

Definitely not.  Again, it is simple to call $m->abort (or not) after
the subrequest.

> 5. If the subrequest aborts, the parent aborts with the aborted value.

Yes.  Will this happen automatically if we don't catch the exception?

> 6. If the subrequest dies with an error, the error gets handled in the
> same way as if the parent had generated it.

Yes.

> Perhaps we should have a $m->internal_redirect() that uses $m->subexec()
> underneath but guarantees the above behavior.

Seems like a good idea to me.

> Other people try to use subrequests as mere glorified component calls
> with dhandlers and autohandlers turned on. (This seems rarer because,
> for one thing, you've got to deal with the double content wrapping
> problem.) Because this use case is less frequent, we don't have to worry
> as much about the default subrequest behavior supporting it.

I can imagine cases where the subrequest should be isolated from the main
request, so that flushes and clears don't affect the main request.
But it doesn't need to be the default behavior, as long as we document how
someone would do that.

~ John Williams


> Dave Rolsky wrote:
>
> > So in fixing a bug related to this I realized that there are cases where
> > the behavior of a subrequest with autoflush (or when it calls
> > flush_buffer) really isn't well defined.
> >
> > There are two questions to consider:
> >
> > 1. Should a subreauest which calls $self->flush_buffer be flushing the
> >    parent request?
> >
> > Right now it does, but I'm not sure that's right.  Maybe the subrequest
> > should really be isolated if the parent does not have autoflush on.
> >
> > 2. Given a parent with autoflush on, and a subreq which explicitly turns
> >    it off, what do we expect to happen?  Right now the output gets flushed
> >    anyway, because the child's default out_method will end up calling
> >    print() on the parent, which will then flush.
> >
> > Is this correct?  Again, if the subrequest should be totally isolated then
> > it's not correct.



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php