Progressive rendering

rubyonrails-core
1

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] GitHub - oggy/template_streaming: Progressive rendering for Rails 2.3.x.

Thanks, George

2

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

3

Yup, read it. Thanks. :slight_smile:

4

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.

5

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

6

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

7

Sounds great! Good idea, Robert! :slight_smile:

Thanks,

Steve