Progressive rendering

Hi,

A while back I released a gem [1] to enable progressively rendering
views (a.k.a., "the #flush method").

Having heard interest from some rails-core members, I was hoping to
start work on a Rails 3.1 integration, but a recent tweet from DHH
suggests there's been some work (or at least thought) on this. What's
the status on this feature? Can I lend a hand shaping or implementing
it?

[1] http://github.com/oggy/template_streaming

Thanks,
George

http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/

Yup, read it. Thanks. :slight_smile:

Hey folks!

I've been chatting a bit with Yehuda about his recent post on
automatic flushing (http://yehudakatz.com/2010/09/07/automatic-
flushing-the-rails-3-1-plan/), and I wanted people's ideas about how
the API should work and what the new API should be called. I'm gonna
write some tests/code/docs and send it to Yehuda (or any other
committer who cares to look it over). There's a good chance that what
I write won't be useable, but hopefully it'll at least be
inspiring. :slight_smile:

Anyway, I kinda like "provide", but I like "final_content_for"
better. Mostly, I feel like the call to this method should *finalize*
the content for that key, meaning you could do something like this:

content_for :foo, "bar"
final_content_for :foo, "baz"

Then if you called "content_for :foo" or "final_content_for :foo"
again, Rails would raise an exception. Calling "yield :foo" would
output "barbaz".

Otherwise, content_for and provide (or whatever it ends up being
called) could be kept entirely separate, though I feel that could be
somewhat confusing for people, but maybe I'm wrong (?).

What are people's thoughts re: name and re: behavior wrt content_for
and the new, automatic-flushing api?

-Steve

PS: The main reason I want to get this nailed down is so I can work on
this content_for/action caching patch I submitted awhile back.

Anyway, I kinda like "provide", but I like "final_content_for"
better. Mostly, I feel like the call to this method should *finalize*
the content for that key, meaning you could do something like this:

content_for :foo, "bar"
final_content_for :foo, "baz"

Then if you called "content_for :foo" or "final_content_for :foo"
again, Rails would raise an exception. Calling "yield :foo" would
output "barbaz".

Otherwise, content_for and provide (or whatever it ends up being
called) could be kept entirely separate, though I feel that could be
somewhat confusing for people, but maybe I'm wrong (?).

What are people's thoughts re: name and re: behavior wrt content_for
and the new, automatic-flushing api?

It would be awesome to have it working as you described. +1.

About naming and api; how about:

content_for :foo, "bar"

and then:

content_for :foo, "baz", :flush => true
or
content_for :foo, "baz", :finalize => true
or
content_for :foo, "baz", :freeze => true

Robert Pankowecki

I like that! :finalize => true works for me (I'd rather not make the
API expose the reason for the API)

Sounds great! Good idea, Robert! :slight_smile:

Thanks,

Steve