Non hai neanche guardato il codice? Cos'è leggi l'ultimo post inserito e scrivi?Originariamente inviato da k.b
Quando gli interrogativi non hanno senso, si. Che significa "spostare il codice di notifica dentro inizializza, appesantendo la funzione"? Quale codice di notifica? Cos'e' "inizializza"? Quale funzione?
Ma comunque, me lo fai un esempio di model che chiama il controller o no?
Originariamente inviato da Grino
Non hai neanche guardato il codice? Cos'è leggi l'ultimo post inserito e scrivi?
ma tu hai un controller legato ad un solo model? oO quindi che controller è? Non è un controller per gestire richieste dell'utente, ma un controller per gestire operazioni sul singolo model?
cioè una cosa del tipo addUtenteToUserGroup te non la puoi fare così, perchè non hai un controller che gestisca un model utente, un model UserGroup, e magari il model usersTogroups in caso di many-many? quindi ci credo che non ci capiamo
IP-PBX management: http://www.easypbx.it
Old account: 2126 messages
Oldest account: 3559 messages
Ah non avevo capito che c'erano esempi nel codice sopra. Ora l'ho letto e molto semplicemente non vedo il motivo per cui Notifica() debba essere chiamato dal model. A parte il problema concettuale, non fai altro che legare model e controller piu' di quanto necessario: se lo stesso model deve essere usato da piu' controller, allora tutti quei controller devono avere il metodo Notifica(). Per quanto mi riguarda, un model non dovrebbe avere la minima idea di come sia fatto un controller.
Il controller gestisce le logiche del programma. E' quell'oggetto deputato a prendere decisioni ed agire di conseguenza. Questo significa che un controller1 puà fare uso di un model1, un model2 ed un model3.Originariamente inviato da Santino83_02
ma tu hai un controller legato ad un solo model? oO quindi che controller è? Non è un controller per gestire richieste dell'utente, ma un controller per gestire operazioni sul singolo model?
cioè una cosa del tipo addUtenteToUserGroup te non la puoi fare così, perchè non hai un controller che gestisca un model utente, un model UserGroup, e magari il model usersTogroups in caso di many-many? quindi ci credo che non ci capiamo
Io posso stabilire di avere un controller dedicato per ogni view ed il relativo model. Se un domani verrai a metterci le mani trovaerai un controller che decide, un model che agisce sui dati e un viewer che visualizza.
Io posso stabilire di avere più controller, discendenti di un controller genitore, che ridefiniscono i metodi del padre. Ogni controller può interagire con più view, dato che il controller passa se stesso come parametro, e lo stesso controller può interagire con più model che potranno invocare il metodo "notifica" del controller chiamante, qualunque esso sia.
I metodi offerti sono sempre gli stessi, quindi gli oggetti interagiscono comodamente consapevoli di potersi poggiare gli uni agli altri rispetto a tali metodi.
Il nome model della classe è solo per far capire, ma ovviamento si poteva chiamare modelPippo, discendente di modelGenerico che ridefinisce le funzioni del padre, o se preferisci, implementa l'interfaccia (su cui PHP è lacunoso, quindi parliamo di ereditarietà) comune ai model ovvero "aggiorna" e "leggi".
Il view da parte sua può estendersi come il model purchè i suoi eredi implementino o ridefinisceno se necessario il metodo seleziona.
Alla fine di tutto però, entrambi sappiamo che, quando ci toccherà mettere mano al codice, che sia tuo o mio, avremo il model legato ai dati, in controller che decide con le sue routine invocate tramite richiesta dell'utente (ma non spiegiamo come l'utente, non il programmatore, faccia a scegliere la routine da lanciare altrimenti si apre un altro capitolone) e la routine di notifica che incorpora le eccezzioni sollevate dal model. Infine il viewer che, leggendo dal model, ci mostra la pagina.
Il programma si comporta in modo bizzarro... subito apriamo il controllerXXX piuttosto che il controllerZZZ;
il programma salva male i dati? Apriamo il modelYYY o il modelKKK
vogliamo modificare l'aspetto finale? Diamo uno sguardo al viewrFFF
Questa se permetti è una sciocchezza. Il model conosce il controller quel tanto che basta per intergire con quest'ultimo! Sono scatole nere che comunque espongono dei metodi, altrimenti come interagirebbero gli oggetti? Col pensiero?Originariamente inviato da k.b
Ah non avevo capito che c'erano esempi nel codice sopra. Ora l'ho letto e molto semplicemente non vedo il motivo per cui Notifica() debba essere chiamato dal model. A parte il problema concettuale, non fai altro che legare model e controller piu' di quanto necessario: se lo stesso model deve essere usato da piu' controller, allora tutti quei controller devono avere il metodo Notifica(). Per quanto mi riguarda, un model non dovrebbe avere la minima idea di come sia fatto un controller.
In più dato che un model lancia un certo tipo di notifica in realtà ci sarà un controllerX capace di reagire approriatamente alle notifiche dello specifico modelX. Tutti i controller che fanno uso e abuso di modelX non faranno altro che esse figli, più appropriatamente discendenti, di model X.
Quindi avremo ControllerX genitore di ControllerXA e ControllerXB.
se ControllerXA lancia la sua chiamata di aggiornamento al modelX, il modelX invocherà la notifica. Se è stata ridefinita, esaurite le possibilità gestite dallo specifico notifica del ControllerXA, questi invocherà il caro paparino parent::Notifica che gli toglie le casatagne dal fuoco. Se non l'ha ridefnita comunque partirà il Notifica del padre capace di gestire la cosa e tutto torna.
Il model in effetti non sa niente del controller se non che gli può demandare i problemi che ha tramite una bella richiesta in carta da bollo che io chiamo Notifica.
L'esempio didattico non va bene perchè nel viewer, che invoca la lettura dati da perte del model, manca la possibilità al model di chiedere aiuto ad un controller in caso di problemi. Questo è un grosso difetto del codice di prima, comunque risolvibile... ma quel codice è solo a scopo didattico per introdurre all'argomento.
No mi spiace ma non permetto, perche' quello che dici e' contrario al concetto di OOP.Originariamente inviato da Grino
Questa se permetti è una sciocchezza.
Tu sostanzialmente dici che se io Classe A voglio usare Classe B, allora devo implementare i metodi che Classe B richiede che io abbia? Ma stiamo scherzando? Cioe' io pubblico una classe model e chi la usa non solo deve conoscere l'interfaccia pubblica della mia classe, ma deve anche implementare dei particolari metodi nella classe in cui utilizza la mia? Stai creando dipendenze dove non ce ne devono essere.
Il model non estende il controller, non ne eredita nulla e quindi non ha motivo di sapere come sia fatto. Il controller chiama un metodo del model, quello esegue quello che deve eseguire e fornisce una risposta. In base a questa risposta il controller agira' come crede (notificando l'utente, o facendo qualsiasi altra cosa sia ritenuta opportuna). Fine. Notificare l'utente, chiamare una view e roba del genere, non e' il mestiere del model.
Per quanto provi a spiegarti, riesci a non capire che stai implementeando un modello basato su tre entità che interagiscono fra loro con regole precise, quindi è normaleOriginariamente inviato da k.b
No mi spiace ma non permetto, perche' quello che dici e' contrario al concetto di OOP.
Tu sostanzialmente dici che se io Classe A voglio usare Classe B, allora devo implementare i metodi che Classe B richiede che io abbia?
1) che model e viewer sappiano che il controller accetta delle notifiche
2) che il controller sappia che il viewer accetta una selezione e il model un aggiornamento
3) che il viewer sappia che il controller accetta notifiche
Vuoi vedere queste tre classi come se fossero entità separate ma non lo sono, perchè sono tutte figlie di una superclasse chiamata MCV
No, non e' normale. Il pattern MVC non prevede interazione diretta tra model e controller. Vedi: http://en.wikipedia.org/wiki/Model%E...0%93ControllerOriginariamente inviato da Grino
Per quanto provi a spiegarti, riesci a non capire che stai implementeando un modello basato su tre entità che interagiscono fra loro con regole precise, quindi è normale
Ovviamente in ambito webapp la presenza dell'observer (o altra tecnica equivalente) perde di senso visto che l'applicazione e' stateless e funziona a richieste singole.
Oppure mettiamola così... sto dicendo che se tu classe A vuoi essere un controller e tu classe B vuoi esser un model, entrambe dovete implementare le interfacce necessarie. Mai sentito parlare di interfacce? Quelle, per ora, mal iplementate da PHP.Originariamente inviato da k.b
No mi spiace ma non permetto, perche' quello che dici e' contrario al concetto di OOP.
Tu sostanzialmente dici che se io Classe A voglio usare Classe B, allora devo implementare i metodi che Classe B richiede che io abbia? Ma stiamo scherzando? Cioe' io pubblico una classe model e chi la usa non solo deve conoscere l'interfaccia pubblica della mia classe, ma deve anche implementare dei particolari metodi nella classe in cui utilizza la mia? Stai creando dipendenze dove non ce ne devono essere.
Il model non estende il controller, non ne eredita nulla e quindi non ha motivo di sapere come sia fatto. Il controller chiama un metodo del model, quello esegue quello che deve eseguire e fornisce una risposta. In base a questa risposta il controller agira' come crede (notificando l'utente, o facendo qualsiasi altra cosa sia ritenuta opportuna). Fine. Notificare l'utente, chiamare una view e roba del genere, non e' il mestiere del model.
Altrimenti cara classe A non puoi definirti controller e cara classe B non puoi definirti model!
Permessi di invio
Rispondi quotando