Forum: Italian Ruby user group evitare duplicazione di codice.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2009-04-29 17:16
(Received via mailing list)
Ho una action nel controller X che mi restituisce un elenco in base a
dei parametri inviati da un form.
In questo controller ho un before_filter :foo.
Nella view di un altro controller ho un altro form, anch'esso mi deve
restituire una lista in base a dei parametri e poiche' la lista e'
quasi la stessa il form richiama l'action del controller X.
Pero' non dovrebbe eseguire il before filter se tale action viene
chiamata dal form di questa view.
E' possibile fare in modo di sapere da dove proviene una richiesta per
poter evitare che la before_filter venga eseguita?
72e0b3f5418bfcf47488918109068c4c?d=identicon&s=25 Andrea Cuius (q_rails)
on 2009-04-29 17:22
(Received via mailing list)
dovresti avere l' opzione :unless da usare con il before filter
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2009-04-29 17:24
(Received via mailing list)
2009/4/29 Andrea (Q) <q@ptumpa.com>:
> dovresti avere l' opzione :unless da usare con il before filter

:unless cosa.....fammi un esempio.
72e0b3f5418bfcf47488918109068c4c?d=identicon&s=25 Andrea Cuius (q_rails)
on 2009-04-29 17:27
(Received via mailing list)
before_filter :do_it, :unless => i_do_not_read_the_doc

def i_do_not_read_the_doc
  return true if brain.empty?
end

o qualche cosa del genere

:]
72e0b3f5418bfcf47488918109068c4c?d=identicon&s=25 Andrea Cuius (q_rails)
on 2009-04-29 17:28
(Received via mailing list)
cmq leggiti la doc che nn mi ricordo bene.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2009-04-29 17:51
(Received via mailing list)
2009/4/29 Andrea (Q) <q@ptumpa.com>:
> cmq leggiti la doc che nn mi ricordo bene.

Si, ok ma.....l'action del controller X viene chiamata da un form di
una view del controller Y.
Dovrei controllare, se e' possibile, da chi e' stata chiamata tale
action, ...........se il controller X, al quale appartiene, oppure se
viene chiamata dal controller Y.
E' possibile o faccio prima ad impostare un campo hidden e fare il
controllo su tale campo?
36f352bc8c234dbde21cb30e89767824?d=identicon&s=25 Luigi Panzeri (Guest)
on 2009-04-29 18:05
(Received via mailing list)
Il giorno 29/apr/09, alle ore 17:15, Mauro ha scritto:

> Ho una action nel controller X che mi restituisce un elenco in base a
> dei parametri inviati da un form.
> In questo controller ho un before_filter :foo.
> Nella view di un altro controller ho un altro form, anch'esso mi deve
> restituire una lista in base a dei parametri e poiche' la lista e'
> quasi la stessa il form richiama l'action del controller X.
> Pero' non dovrebbe eseguire il before filter se tale action viene
> chiamata dal form di questa view.
> E' possibile fare in modo di sapere da dove proviene una richiesta per
> poter evitare che la before_filter venga eseguita?


Puoi aggirare il problema in modo più elegante imho.

Non richiamare l'action del controller X, ma metti un metodo apposito
dell'altro controller e per evitare di duplicare codice metti la
logica condivisa in una funzione di controllers/application.rb (da
cui entrambi derivano), oppure nella classe del modello appropriato
(es. se generi una lista di profili, allora forse ci starebbe un
metodo di classe del modello Profile).
72e0b3f5418bfcf47488918109068c4c?d=identicon&s=25 Andrea Cuius (q_rails)
on 2009-04-29 18:59
(Received via mailing list)
restful authentication fa una cosa del genere

  def store_location
       session[:return_to] = request.request_uri
     end
7de465f222e6a9c7fe658e370d0bfe05?d=identicon&s=25 Paolo Montrasio (pmontrasio)
on 2009-04-30 08:30
Luigi Panzeri wrote:
> Non richiamare l'action del controller X, ma metti un metodo apposito
> dell'altro controller e per evitare di duplicare codice metti la
> logica condivisa in una funzione di controllers/application.rb (da
> cui entrambi derivano), oppure nella classe del modello appropriato
> (es. se generi una lista di profili, allora forse ci starebbe un
> metodo di classe del modello Profile).

Concordo, è meglio non mischiare troppo i controller altrimenti si fa
una spaghettata di URL e seguire il codice dopo qualche settimana
diventa difficile :-)

E' anche bene mettere quanta più logica possibile nei modelli e tenere i
controller il più vuoti possibile per cui propendo per la seconda
soluzione.

Nota a margine: a partire da Rails 2.3 controllers/application.rb non
esiste più ed è sostituito da controllers/application_controller.rb
(basta fare il rename).

Paolo
This topic is locked and can not be replied to.