Chiamare un metodo da un altro controller

Saluti a tutti, ho cominciato da poco con rails e molte cose sono ancora
poco chiare. Mi chiedevo se era possibile chiamare un metodo
“nome_metodo” in un controller B da un controller A: eseguendo alcune
ricerche ho trovato 2 soluzioni:

  • dichiarare il metodo nomeMetodo nel controller B e dichiararlo come
    helper in application.rb
  • fare tutto quanto in application.rb (dichiararlo e renderlo helper)

Per esempio, è possibile fare così?

controller A < ApplicationController
def metodoA
[…]
@risultato = B.nomeMetodo
[…]
end
end

Vorrei definitivamente dare una risposta completa a questo mio dubbio
con ogni possibilità . Grazie in anticipo a tutti, saluti

nicola

Il giorno 20 agosto 2009 14.25, Nicola N.[email protected] ha
scritto:

Saluti a tutti, ho cominciato da poco con rails e molte cose sono ancora
poco chiare. Mi chiedevo se era possibile chiamare un metodo
“nome_metodo” in un controller B da un controller A

in linea di massima i metodi dei controller sono fatti per essere
invocati da rails, o come action, cioè in risposta a una request, o
come filtri (before, after etc.).

se B.nome_metodo è un’action di B, potresti ad esempio fare un
redirect. è improbabile che il comportamento giusto sia restituire da
A lo stesso output di B.nome_metodo, perché in teoria A e B
rappresentano due risorse diverse.

se invece B.nome_metodo è un metodo di utilità, cioè fa una certa
operazione che ti è necessario richiamare in più posti, allora non
dovrebbe essere un metodo di B, ma di qualche altra classe. per
decidere quale, dovrei saperne di più: se è un’operazione sui dati è
probabile che vada dichiarato dentro un model; altrimenti, forse
dovresti creare un modulo da qualche parte.

dicci di
più.

pietro

Ti consiglio di dichiararli in ApplicationController, in modo da
sfruttare
l’ereditarietà per rendere disponibili i tuoi metodi in tutti i
controller.
Il segno di minore “<” indica questo tipo di relazione tra quella classe
e
ControllerA.
Nel caso il numero di metodi dovesse proliferare ti consiglio di creare
un
modulo apposito in lib/ e di includerlo.

Perché ti serve dichiarare i metodi come helper? Questa macro serve a
rendere disponibile un metodo tra controller e view, non tra diversi
controller.

Luca

Vi ringrazio per le risposte, vedo che c’è molto più da tirare in ballo.
Scarto il metodo helper, ne basterebbe uno protected nella sopraclasse
quindi.

Per spiegare il tutto parto un po’ da lontano: il controller B è un
SessionsController. Quando un utente vuole effettuare il login, va nella
pagina /sessions/new: qui inserisce i dati, che passano al metodo
create, il quale li prende dal POST, se non ho capito male, li legge e
crea una nuova sessione per l’utente.

Fin qui tutto ok

Il controller A è uno UsersController che gestisce gli utenti
registrati. In particolare consente di recuperare una
password smarrita: se uno vuole recuperarla, seguendo il link su una
mail, vorrei che effettuasse il login in automatico (un’azione in
UsersController) e venisse rediretto a edit di Users.

Il pallino mi è venuto quando pensavo a come creare una sessione da
UsersController, senza fare del lavoro che dovrebbe essere fatto da
SessionsController e senza spostare il tutto nella sopraclasse per
mantenere le cose separate.

Leggendo le vostre risposte mi viene in mente di mettere un link ad
un’azione in SessionsController nella mail, che fa un redirect ad
un’azione di UsersController (edit). Avete altre idee?

Vi ringrazio per l’attenzione ed il tempo,

Nicola

Ciao Nicola,
come avrai notato non è facilmente attuabile una soluzione
poiché,concettualmente, quello che stai cercando di fare va contro la corretta
progettazione di una struttura MVC.

Potresti chiarire meglio cosa vuoi fare ed il motivo di questa esigenza?
Senz’altro c’è una soluzione più efficace.

– Simone

2009/8/20 Nicola N. [email protected]

controller A < ApplicationController

nicola

Posted via http://www.ruby-forum.com/.


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


Simone C.

Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Nick: weppos | Skype: weppos

Fammi capire se ho afferrato abbastanza: tu dici di creare un modello
che gestisca le sessioni senza doverlo associare ad una tabella nel
database (quindi se non ho capito male gli ActiveRecord sono quelli con
db associato) così da poterlo usare da dove voglio.

Fin’ora consideravo il modello strettamente associato alle tabelle,
quindi solo quando ne avevo una creavo il modello associato, e questo mi
vincolava. Mi fa piacere che non sia così, mi sembrava troppo limitato
in quel modo…

Vi ringrazio per avermi indirizzato con le vostre domande e consigli,
specialmente quest’ultima risposta, che anche se non risolve il problema
(penso di sì) mi ha fatto capire altre cose più importanti.

Nicola

Il giorno 20 agosto 2009 18.16, Nicola N.[email protected] ha
scritto:

Leggendo le vostre risposte mi viene in mente di mettere un link ad
un’azione in SessionsController nella mail, che fa un redirect ad
un’azione di UsersController (edit). Avete altre idee?

credo di aver capito il problema. una soluzione consiste nello
spostare gran parte della logica per la creazione di una sessione da
SessionsController a un model, ad esempio Session (che sia basato su
ActiveRecord o no non ha importanza).

l’idea sarebbe:

controllers/sessions_controller.rb

class SessionsController < ApplicationController

def create
… # eventuali controlli vari
session = Session.new params[:session]
… # altro
end

end

controllers/users_controller.rb

class UsersController < ApplicationController

def un_action_che_vuole_creare_una_session

session = Session.new dativari

end

end

models/session.rb

class Session
def initialize datinecessari
… # qui avviene quello che deve avvenire
end
end

in generale è preferibile spostare quanta più logica possibile dal
controller al (ai) model.

alcuni esempi (che per me sono stati) illuminanti:
http://railscasts.com/episodes/119-session-based-model
http://railscasts.com/episodes/121-non-active-record-model

pietro

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs