come gestite gli helpers?
Il default di rails includere tutti gli helper dovunque, il che
potrebbe
portare a clash di nomi.
Questo si pu disattivare globalmente, su versioni recenti di rails,
inserendo in application.rb #do NOT include all the helpers
config.action_controller.include_all_helpers = false
(thx weppos)
Naturalmente questo pu rompere cose, qualora si siano usati metodi di
helper relativi ad altri controller in alcune delle proprie view.
la soluzione includere i moduli degli helper per ogni controller che ne
fa uso, ma magari voi avete un approccio pi pratico / consolidato.
Non mi mai capitato di avere dei clash di nomi negli helper.
Devo dire che ultimamente li uso poco. Ora vanno di moda i presenters,
dove hai la logica di visualizzazione racchiusa in una classe, quindi il
problema del clashing non si pone.
Gli helpers come molte altre cose in Rails sono pratici e comodi da
usare, e come tutte le comodit ti fanno impigrire. In questo caso il
rischio di dimenticare le buone pratiche della programmazione a
oggetti.
Li uso ancora, ma evito attentamente quelle cose tristi tipo includere
un helper in un controller. E quando le cose si fanno complicate
estraggo una classe.
E comunque per evitare il name clashing puoi farti dei namespace negli
helper.
Non mi mai capitato di avere dei clash di nomi negli helper.
Devo dire che ultimamente li uso poco. Ora vanno di moda i presenters,
dove hai la logica di visualizzazione racchiusa in una classe, quindi il
problema del clashing non si pone.
Diciamo che io preferirei aderire alla convenzione di rails riguardo gli
helpers, pi per consistenza che per pigrizia.
Il clashing nei nomi deriva dall’uso di engine che forniscono helper con
nomi un po’ disinvolti. Hanno un namespace, ma venendo inclusi
direttamente
(conf di default) come se non lo avessero all’atto pratico.
Comunque, secondo me, questo un ottimo topic per il ruby day
diciamo che i presenters, pi che una moda, sono una buona soluzione
per risolvere alcuni problemi, soprattutto con i fat models
ultimamente ho avuto una bella discussione filosofica su questo
argomento. avevamo una serie di controllers che dovevano restituire
strutture di dati aggregati e presentarle in html e json.
per evitare i fat models, e riutilizzare pi codice possibile, ci siamo
accordati per una strategia abbastanza semplice:
i view helpers li usiamo prettamente per le views in html, senza
escludere di inserire anche il markup per snellire le viste (aka
dumb-views)
i presenters li utilizziamo per strutturare i dati aggregati, in
questo modo possiamo usarli anche per gli altri formati (es: json)
se un domani si decidesse di eliminare del tutto la parte delle views in
html (magari costruendo una single-page-app), baster eliminare i view
helpers senza troppe preoccupazioni
per il name clashing, basta fare attenzione ai nomi usati per i metodi,
come del resto accade per altre porzioni dell’app
ciao,
A.
Il giorno 22/nov/2012, alle ore 12:52, Fabrizio R. [email protected] ha scritto:
Non mi mai capitato di avere dei clash di nomi negli helper.
Devo dire che ultimamente li uso poco. Ora vanno di moda i presenters, dove hai
la logica di visualizzazione racchiusa in una classe, quindi il problema del
clashing non si pone.
Gli helpers come molte altre cose in Rails sono pratici e comodi da usare, e
come tutte le comodit ti fanno impigrire. In questo caso il rischio di
dimenticare le buone pratiche della programmazione a oggetti.
Li uso ancora, ma evito attentamente quelle cose tristi tipo includere un helper
in un controller. E quando le cose si fanno complicate estraggo una classe.
E comunque per evitare il name clashing puoi farti dei namespace negli helper.
Rispolvero questo thread un po’ datato
Ho dato un’occhiata ai vari suggerimenti, e trovo i cells interessanti.
Non ho però dati in merito alla velocità di questa soluzione, qualcuno
che
li usa estensivamente mi sa dare qualche puntatore?
