Parziali, scope e :locals

Community IT
1

Ciao,
in rails 1.2 il modo consigliato per creare i form è usare “form_for”
e poi indicare con l’url e il metodo HTTP quello che deve succedere.
(Se non ho capito male.)
In altre parole il che corrisponde a “create” è diverso dal
form che fa un “update”. Il primo è un POST e il secondo un PUT.
Quindi, se voglio usare un partial condiviso per create/update,
questo
deve escludere il “form_for”.
Se chiamo form_for con un block - com’è kosher fare - il codice erb
nel partial non vive nello stesso scope del block (e perché no???),
ma
devo usare il parametro :locals nella chiamata a “render”.
Quindi, questo funziona:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form”, :locals => {:f => f}%>
<% end %>

E questo invece no:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form” %>
<% end %>

Sono solo io, o questo è un comportamento anti-DRY e anti-ruby??? il
“render(:partial)” vive nel block di “form_for()” e dovrebbe usare lo
stesso scope. Mi sembra proprio brutto dover usare :locals…
:frowning:

2

Il giorno 13/dic/06, alle ore 15:26, david ha scritto:

Anche io sono incorso in questo problema, ma l’ho trovato un’aggiunta
utile perché in questo modo posso passare altre variabili al blocco e
rendere i partials un pò più indipendenti dal contesto.

3

Non bellissimo, ma per evitarmi il :local, io uso @f anziche’ f.

<% form_for :customer, @customer, :url => { :action => “create” } do
|@f| %>
<%= render :partial => ‘form’ %>
<%= submit_tag ‘Create’ %>
<% end %>

david wrote:

Ciao,
in rails 1.2 il modo consigliato per creare i form è usare “form_for”
e poi indicare con l’url e il metodo HTTP quello che deve succedere.
(Se non ho capito male.)
In altre parole il che corrisponde a “create” è diverso dal
form che fa un “update”. Il primo è un POST e il secondo un PUT.
Quindi, se voglio usare un partial condiviso per create/update,
questo
deve escludere il “form_for”.
Se chiamo form_for con un block - com’è kosher fare - il codice erb
nel partial non vive nello stesso scope del block (e perché no???),
ma
devo usare il parametro :locals nella chiamata a “render”.
Quindi, questo funziona:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form”, :locals => {:f => f}%>
<% end %>

E questo invece no:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form” %>
<% end %>

Sono solo io, o questo è un comportamento anti-DRY e anti-ruby??? il
“render(:partial)” vive nel block di “form_for()” e dovrebbe usare lo
stesso scope. Mi sembra proprio brutto dover usare :locals…
:frowning:

4

Ok, mica dico che :locals va rimosso, ma una chiamata effetuata dentro
un block, dovrebbe ben vivere nello scope del block, no? Continua a
parere parecchio brutto…
:-/
Giovanni I. wrote:

 Il giorno 13/dic/06, alle ore 15:26, david ha scritto:
 Anche io sono incorso in questo problema, ma l'ho trovato
 un'aggiunta utile perché in questo modo posso passare altre
 variabili al blocco e rendere i partials un pò più indipendenti dal
 contesto.

    Sono solo io, o questo è un comportamento anti-DRY e
 anti-ruby??? il
    "render(:partial)" vive nel block di "form_for()" e dovrebbe
 usare lo
    stesso scope. Mi sembra proprio brutto dover usare :locals...

 _______________________________________________
 Ml mailing list
 [1][email protected]
 [2]http://lists.ruby-it.org/mailman/listinfo/ml

–
“Remember, always be yourself. Unless you suck.” - Joss Whedon

References

  1. mailto:[email protected]
  2. http://lists.ruby-it.org/mailman/listinfo/ml
5

Wow! Pure quello è orrendissimo!
:slight_smile:
Ma come fa a funzionare? E’ una variabile di classe che nasce/muore
solo nel block??? Aiuto… E’ una classvariable del controller,
giusto?
Che confusione…
Massimo wrote:

Non bellissimo, ma per evitarmi il :local, io uso @f anziche’ f.

<% form_for :customer, @customer, :url => { :action => “create” } do
|@f| %>
<%= render :partial => ‘form’ %>
<%= submit_tag ‘Create’ %>
<% end %>

david wrote:

Ciao,
in rails 1.2 il modo consigliato per creare i form è usare “form_for”
e poi indicare con l’url e il metodo HTTP quello che deve succedere.
(Se non ho capito male.)
In altre parole il che corrisponde a “create” è diverso dal
form che fa un “update”. Il primo è un POST e il secondo un PUT.
Quindi, se voglio usare un partial condiviso per create/update,
questo
deve escludere il “form_for”.
Se chiamo form_for con un block - com’è kosher fare - il codice erb
nel partial non vive nello stesso scope del block (e perché no???),
ma
devo usare il parametro :locals nella chiamata a “render”.
Quindi, questo funziona:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form”, :locals => {:f => f}%>
<% end %>

E questo invece no:

<% form_for :channel, @channel, :url => channel_path(@channel), :html =>
{:meth
od => :put} do |f| %>
<%= render :partial => “form” %>
<% end %>

Sono solo io, o questo è un comportamento anti-DRY e anti-ruby??? il
“render(:partial)” vive nel block di “form_for()” e dovrebbe usare lo
stesso scope. Mi sembra proprio brutto dover usare :locals…
:frowning:

_______________________________________________________________________

Ml mailing list
[1][email protected]
[2]http://lists.ruby-it.org/mailman/listinfo/ml

–
“Remember, always be yourself. Unless you suck.” - Joss Whedon

References

  1. mailto:[email protected]
  2. http://lists.ruby-it.org/mailman/listinfo/ml
6

On 12/13/06, david [email protected] wrote:

Ma come fa a funzionare? E’ una variabile di classe che nasce/muore
solo nel block???

Sembra di si`.

Aiuto… E’ una classvariable del controller,

Instance variable.

giusto?

Per aggiungere qualcosa al rumore, se ho capito bene, le instance
variables sono visibili nelle views, ma le class variables ( @@foo,
per esempio) non lo sono. Se mi ricordo bene, e quasi meglio pensare al @ come una specie di identificatore, invece di pensare a regole di classi e visibilita di variabili.

–
David N. Welton

Linux, Open Source Consulting