Modello MVC che significa tenere separati modelli viste e controller
all’atto della scrittura del codice.
Conseguentemente se in una vista, ho una select collection di questo
tipo: <%= f.collection_select :sector_id, Sector.find(:all), :id,
:descrizione %> sto chiamando un modello da una vista.
E’ piu’ giusto invece <%= f.collection_select :sector_id, @sectors,
:id, :descrizione %> mentre nel controller avro’ all’interno di un
metodo @sectors=Sector.find(:all).
E’ il corretto modo di procedere?
2009/2/5 Mauro [email protected]
Modello MVC che significa tenere separati modelli viste e controller
all’atto della scrittura del codice.
Conseguentemente se in una vista, ho una select collection di questo
tipo: <%= f.collection_select :sector_id, Sector.find(:all), :id,
:descrizione %> sto chiamando un modello da una vista.
E’ piu’ giusto invece <%= f.collection_select :sector_id, @sectors,
:id, :descrizione %> mentre nel controller avro’ all’interno di un
metodo @sectors=Sector.find(:all).
E’ il corretto modo di procedere?
Certo.
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Currently writing “Ruby on Rails for Microsoft Developers” for Wrox.
On Thu, Feb 5, 2009 at 2:09 PM, Carlo P. [email protected]
wrote:
E’ giusto. E come regola “aggiuntiva” cerca di avere i controller il
più possibile semplici, mentre la “logica” dell’applicazione mettila
nei modelli (che sono generalmente più facili da testare…).
Vedo il tuo “Fat models, skinny controllers” e rilancio con il consiglio
di
evitare di utilizzare troppe variabili d’istanza all’interno di
un’azione.
Ma soprattutto bisogna rendere locale ogni variabile nel controller che
non
necessiti d’essere usata dalla view. 
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Follow me on Twitter: http://twitter.com/acangiano
Currently writing “Ruby on Rails for Microsoft Developers” for Wrox.
E’ giusto. E come regola “aggiuntiva” cerca di avere i controller il
più possibile semplici, mentre la “logica” dell’applicazione mettila
nei modelli (che sono generalmente più facili da testare…).
Il 5 febbraio 2009 18.35, Mauro [email protected] ha scritto:
Non posso che condividere profondamente 
Non voglio metterla sul “filosofico” ma non esiste una distinzione
netta tra il “giusto” e “sbagliato” in questo contesto. Se la tua
applicazione è semplice, probabilmente va benissimo come hai fatto.
In altri casi è preferibile avere buona parte della logica applicativa
(le c.d. busines rules) nei modelli, e lasciare ai controller la sola
gestione dell’interazione con il client (qualcuno suggerisce di avere
controller non più lunghi di 15 LOC…).
Progetti interessanti? Vedi qualsiasi cosa su github fatta in Rails
per farti un’idea (altro suggerimento: impari molto di più leggendo il
codice che non una guida…)
Buon lavoro!
Il 6 febbraio 2009 10.31, Daneel O. [email protected] ha
scritto:
Carlo P. wrote:
E’ giusto. E come regola “aggiuntiva” cerca di avere i controller il
pi� possibile semplici, mentre la “logica” dell’applicazione mettila
nei modelli (che sono generalmente pi� facili da testare…).
Uhm… io ho i modelli praticamente vuoti (a parte l’indicazione delle
relazioni tra tabelle), mentre sui controller c’è praticamente tutto
quello che deve fare… sbaglio io? Ho l’applicazione talmente piccola
che va bene così? Altro?
Non è che ci sia da qualche parte un progettino in rails non troppo
complesso (ma neanche troppo semplice) per capire come fare le cose
nella maniera giusta? Finora ho trovato guide o troppo semplicistiche o
che davano molte cose per scontate, forse non ho guardato quelle giuste?
Il 6 febbraio 2009 10.31, Daneel O. [email protected] ha
scritto:
Uhm… io ho i modelli praticamente vuoti (a parte l’indicazione delle
relazioni tra tabelle), mentre sui controller c’è praticamente tutto
quello che deve fare… sbaglio io? Ho l’applicazione talmente piccola
che va bene così? Altro?Non è che ci sia da qualche parte un progettino in rails non troppo
complesso (ma neanche troppo semplice) per capire come fare le cose
nella maniera giusta? Finora ho trovato guide o troppo semplicistiche o
che davano molte cose per scontate, forse non ho guardato quelle giuste?
torno a consigliare i railscasts, ora non ricordo gli episodi esatti,
ma ci sono molti esempi.
un motivo per piazzare la logica (ad esempio le query complicate) nel
model invece che nel controller è la convenienza di avere funzioni
autodocumentate: metti che un’action del controller è parecchio lunga
ed elaborata; o la seppellisci di commenti, oppure è codice write
only, che tra un po’ di tempo non avrai più il coraggio di tentare di
decifrare.
invece, nel model puoi creare dei metodi ad hoc, il cui nome documenta
già il codice.
magari nel controller hai un if seguito da una roba lunghissima, una
query piena di condizioni, include, etc., che serve, che so, a
controllare se l’editore ha pubblicato almeno un libro di un autore o
un’autrice il cui coniuge fa l’attore.
ecco, quel find potrebbe stare in un metodo di Publisher (o Editor, fa
tu):
class Publisher < ActiveRecord::Base
has_many :books
…
def has_published_an_author_married_to_an_actor_or_actress?
…
end
end
così ora nel tuo controller trovi:
if @editor.has_published_an_author_married_to_an_actor_or_actress?
…
end
stessa cosa quando fai una serie di operazioni per modificare un
record, che so, calcoli matematici o altro; se i calcoli li piazzi in
un metodo del model, con un nome esplicativo, così il controller
diventa molto leggibile e in più, quando leggi il codice, puoi
scegliere se semplicemente guardare il funzionamento generale o se
scendere nel dettaglio di come vengono fatte le varie operazioni,
leggendo la definizione dei metodi che fanno cose strane.
pietro
Mauro wrote:
2009/2/6 Pietro G. [email protected]:
torno a consigliare i railscasts, ora non ricordo gli episodi esatti,
ma ci sono molti esempi.I railscast sono interessanti pero’ in alcuni esempi ho visto molto
spesso nelle viste richiamare direttamente i modelli, del tipo
Sector.find(:all)
Credo che sia abbastanza soggettivo, io uso molto spesso i model
all’interno delle viste ma evito cose che ti obbligano a rincorrerle.
Esempio, nel model concentro le condizioni:
class Technology < ActiveRecord::Base
belongs_to :part
…
named_scope :engined, :conditions => {:part_id => 1}
named_scope :old, :conditions => {:part_id => 2}
end
e nella view posso usare:
<%= collection_select(:technology, :id, Technology.engined, :id, :name,
{:prompt => true}) %>
se devo cambiare una condizione lo faccio una sola volta e non rischio
dimenticanze e nella view uso il model, mi permette di alleggerire il
controller.
passare dal controller, secondo me ha significato se devo farci qualcosa
di più complesso, filtri ecc.
2009/2/6 Pietro G. [email protected]:
torno a consigliare i railscasts, ora non ricordo gli episodi esatti,
ma ci sono molti esempi.
I railscast sono interessanti pero’ in alcuni esempi ho visto molto
spesso nelle viste richiamare direttamente i modelli, del tipo
Sector.find(:all)