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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ On Tue, Sep 7, 2010 at 5:34 PM, George <george.ogata@gmail.com> wrote:> 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 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yup, read it. Thanks. :) On Tue, Sep 7, 2010 at 10:01 PM, Teng Siong Ong <siong1987@gmail.com> wrote:> http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ > > On Tue, Sep 7, 2010 at 5:34 PM, George <george.ogata@gmail.com> wrote: >> >> 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 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. :) 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. On Sep 7, 7:56 pm, George <george.og...@gmail.com> wrote:> Yup, read it. Thanks. :) > > On Tue, Sep 7, 2010 at 10:01 PM, Teng Siong Ong <siong1...@gmail.com> wrote: > > > > > > > > >http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ > > > On Tue, Sep 7, 2010 at 5:34 PM, George <george.og...@gmail.com> wrote: > > >> 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 > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Ruby on Rails: Core" group. > >> To post to this group, send email to rubyonrails-core@googlegroups.com. > >> To unsubscribe from this group, send email to > >> rubyonrails-core+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >>http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Core" group. > > To post to this group, send email to rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-core?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I like that! :finalize => true works for me (I''d rather not make the API expose the reason for the API) Sent from my iPhone On Oct 10, 2010, at 12:11 PM, Robert Pankowecki <robert.pankowecki@gmail.com> wrote:>> 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 > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Sounds great! Good idea, Robert! :) Thanks, Steve On Oct 10, 2010, at 12:59 PM, Yehuda Katz <wycats@gmail.com> wrote:> I like that! :finalize => true works for me (I''d rather not make the > API expose the reason for the API) > > Sent from my iPhone > > On Oct 10, 2010, at 12:11 PM, Robert Pankowecki > <robert.pankowecki@gmail.com> wrote: > >>> 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 >> >> -- >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.