Re: $m->redirect() problem

On Fri, 29 Aug 2003, Jonathan Swartz wrote:

> > I went and implemented this, but this breaks other things.  For example, a
> > component like this:
> >
> >  foo
> >  % $m->flush_buffer;
> >  bar
> >  % $m->clear_buffer;
> >  baz
> >
> > will do weird things if called via scomp, because now the flush doesn't
> > send anything to the client, but the clear call clears _everything_,
> > meaning that any output generated by the _calling_ component gets cleared!
>
> This is only weird if you expect the flush and clear to operate just within
> the scomp "scope".

No, it means that they operate _differently_ depending on whether or not
the component is inside the scope of an scomp call!

Since, as you pointed out, the decision to use scomp is often made by the
_caller_, it seems problematic that the called component could do two
radically different things based on how it is called, since it has no
control over this.

> If you accept the definition of flush_buffer and clear_buffer that I
> suggested above, it is consistent.

It's consistent only if you know how Mason's internals work.

> I know that in 1.1 we tried hard to handle funny situations like the
> above, but is it really worth it? Are people really using flush_buffer
> and clear_buffer in this way, assuming that they'll always be called
> within an scomp? It seems very dicey. You're essentially using a global
> variable (Mason's output buffer) to do conditional output. The same
> behavior can just as easily, and more readably, be handled with
> temporary buffer:
>
>     output some content into a temporary $buffer, e.g. using scomp
>     oops I didn't want that
>     $buffer = '';

This somewhat defeats the purpose of providing the clear and flush calls
to end users.  If flushing isn't guaranteed to send output to the client,
but clear will _always_ clear _all_ output, then the two can't be used
together, because you _might_ end up trying to do this inside an scomp
call, where it will act weirdly.

> > Instead, for 1.2x, I'd rather just turn $m->redirect into a special case
>
> What would you recommend for people who want to return a 404 result
> with $m->clear_buffer; $m->abort(404)? Or are you suggesting that we
> leave that broken while fixing $m->redirect, which is the more common issue?

Yeah, leave it broken since no one has complained about it.

Alternately, we could make clear_all_buffers public and document that
people should use that when they want to abort with an error.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf