Re: $m->redirect() problem

> >   * $m->flush_buffer meant "try to flush as much output as possible out
to
> > the client, but make no guarantees about internal buffers"
> >   * $m->clear_buffer meant "clear all buffers, even that content which
is
> > stuck in an scomp or <%filter> buffer"
>
> 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".
If you accept the definition of flush_buffer and clear_buffer that I
suggested above,
it is consistent.

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 = '';

> 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?

Jon



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