2015-01-07 12 views
25

Mi sono imbattuto nella funzione di visualizzazione "fornire" oggi. Guardando nel suo manuale sono ancora confuso su come sia diverso da "content_for".Ruby on Rails: fornire vs content_for

fornire (nome, contenuto = nil, & blocco)

Lo stesso content_for ma quando impiegati con vampate di streaming direttamente tornare al layout. In altre parole, se si desidera concatenare più volte allo stesso buffer durante il rendering di un determinato modello, è necessario utilizzare content_for, in caso contrario, utilizzare il comando di fornire per interrompere il layout alla ricerca di ulteriori contenuti.

Domanda 1: questo per me è abbastanza astratto: qualcuno potrebbe dare una spiegazione dando un esempio dimostrativo?

Domanda 2: lavorare con la pipeline di asset, che offre prestazioni migliori e perché?

Grazie!

+2

Hai familiarità con http://api.rubyonrails.org/classes/ActionController/Streaming.html? –

+0

Onestamente, non prima di menzionarlo. Ho appena dato un'occhiata al ref che hai condiviso, ed è eccellente. Mai saputo che per impostazione predefinita Rails carica il modello prima del layout! Quindi lo streaming è il modo per ripristinare questo ordine. Poi..? – Bruce

+0

Ecco come è implementato, il vantaggio principale dello streaming è quello di abilitare parti della pagina (in particolare l'intestazione JS) da riacquisire al browser quando è pronto, piuttosto che attendere l'intera pagina. –

risposta

22

Prima di tutto, cos'è lo streaming? Perché dovresti usarlo?

Lo streaming è un metodo alternativo di rendering delle pagine dall'alto verso il basso (fuori dall'interno). Il comportamento di rendering predefinito è inside-out. Streaming deve essere abilitato nel controller:

class MyController 
    def action 
    render stream: true # Streaming enabled 
    end 
end 

Secondo il documentation:

streaming può essere considerato eccessivo per le azioni leggeri come nuovo o modificare. Il vero vantaggio dello streaming è rappresentato dalle costose azioni che, ad esempio, fanno molte query sul database.

Quindi, se non si sta usando lo streaming, c'è ancora una differenza?

Sì.

La differenza è un modello può definire più blocchi di contenuto chiamando più volte content_for.In questo modo si concatenare i blocchi e passare che per il layout:

# layout.html.erb 
<div class="heading"><%= yield :surprise %></div> 
<div class="body"> 
    <p><%= yield %></p> 
    <p>But it's not very interesting...</p> 
</div> 

# template.html.erb 
<%= content_for :surprise, "Hello" %> 
I've got your content! 
<%= content_for :surprise, ", World!" %> 

# Generated HTML 
<div class="heading">Hello, World!</div> 
<div class="body"> 
    <p>I've got your content!</p> 
    <p>But it's not very interesting...</p> 
</div> 

Dal providenon continuare la ricerca il modello fornito, solo il blocco passato alla prima provide chiamata verrà inviata al modello:

# layout.html.erb 
<div class="heading"><%= yield :title %></div> 

# template.html.erb 
<%= provide :title, "Foo" %> 
<%= provide :title, "bar" %> 

# Generated HTML 
<div class="heading">Foo</div> 
+1

'provide' anche * aggiungi * contenuto in' view_flow'. l'unico modo per sovrascrivere i contenuti per la chiave è usare 'content_for' con l'opzione' flush: true'. – mmtootmm

5

ero curioso di vedere quale fosse la differenza, e come Thong Kuah indicò l'API, all'interno della risposta:

Questo significa che, se si dispone di rendimento: titolo nel layout e si desidera utilizzare lo streaming , dovresti rendere l'intero modello (e infine attivare tutte le query) prima di eseguire lo streaming del titolo e di tutte le risorse, il che uccide lo scopo dello streaming. Per questo motivo Rails 3.1 introduce un nuovo helper chiamato provide che fa lo stesso di content_for ma dice al layout di interrompere la ricerca di altre voci e continuare il rendering.