OOP e html

[k.b]

Originariamente inviato da Grino
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.

Altrimenti cara classe A non puoi definirti controller e cara classe B non puoi definirti model!

Ma dove sta scritta sta cosa?

Vanno benissimo le interfacce, ma una classe non puo' essere l'interfaccia di quella che la utilizza. Questa cosa si chiama circular dependency. Cito da wiki:

Circular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module.

http://en.wikipedia.org/wiki/Circular_dependency

[Grino]

Originariamente inviato da k.b
No, non e' normale. Il pattern MVC non prevede interazione diretta tra model e controller. Vedi: http://en.wikipedia.org/wiki/Model%E...0%93Controller

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.

http://framework.zend.com/manual/en/...art.intro.html

oops quelli di zend devono essere impazziti ad aver piazzato una zampetta che ritorna dal model al controller.

io quel disegno lo penso così, ma certamente sbaglierò. Con le frecce piene stiamo dicendo che il controller sceglie il suo view ed il suo model. Il view è costretto ad interagire con un model scelto dal controller (riga tratteggiata), così come il model interagisce con il view che lo ha sollecitato. E poi c'è l'oggetto del contendere. cosa significa quella linea tratteggiata dal model al view?

Io penso che il model si trovi suo malgrado a dover rendere conto delle proprie azioni!

se poi non ti piace che lo chiami mvc, anche se i tre elemnti ci sono, lo chiamerò Grino[mvc]

ti piace?

[Santino83_02]

Originariamente inviato da Grino se poi non ti piace che lo chiami mvc, anche se i tre elemnti ci sono, lo chiamerò Grino[mvc]

ti piace?

Chiamalo come ti pare, ma almeno accetta le critiche. lo schema dice che il controller usa e istanzia e "manipola" oggetti di tipo model e view per mettere assieme tutto il pattern

come dicono gli stessi Dei di Zend:

Controller - Controllers bind the whole pattern together. They manipulate models, decide which view to display based on the user's request and other factors, pass along the data that each view will need, or hand off control to another controller entirely

le frecce tratteggiate indicano presumibilmente la chiamata di metodi sugli oggetti e il loro ritorno, come normalmente si effettua

c'è anche l'uso dell'observer come piu o meno dici te:

http://ootips.org/mvc-pattern.html

citato anche dagli stessi zendiani, solo che, come ti è stato detto prima, in un ambiente stateless è una scelta inutile. E cmq li si parla di observer tra view e model, in maniera da modificare il comportamento della view a seconda dello stato del model, non certo tra model e controller.

come dicono bene quelli di zend:

Model - This is the part of your application that defines its basic functionality behind a set of abstractions. Data access routines and some business logic can be defined in the model.

L'interazione tra model e controller è da evitare per il semplice fatto che così facendo leghi il controller col model in maniera molto forte, e probabilmente anche inutile, perchè basterebbe che il model torni un risultato di un'operazione invece di invocare eventi così, a buffo. Questo ti permette poi di poter utilizzare i model in maniera trasparente da qualsiasi altro oggetto, senza bisogno che tale oggetto si registri nel model o implementi un'interfaccia specifica. E soprattutto ti permette di giocare con i model senza legarti a nessuno in particolare.

Se tu vuoi fare un oggetto che NON SIA un controller ma che cmq lavori con dei model, ad esempio per incapsulare una logica di business molto complicata ma usata in molti punti del programma, che fai? devi fare un controller che non sia un controller o cose simili? implementare interfacce inutili? estendere (dio ce ne scampi) altre classi?

cioè lo puoi anche fare, per carità ognuno è genio e inventa i modi che gli tornano piu comodi, solo che quello non è mvc, non è codice disaccoppiato, controller e model fanno piu di quello che devono fare, in particolare il model, e il model è sostanzialmente inutilizzabile da oggetti che non implementano determinate interfacce, quando lo scopo del model è essere usato in maniera trasparente e senza fronzoli.

[k.b]

Originariamente inviato da Santino83_02
L'interazione tra model e controller è da evitare per il semplice fatto che così facendo leghi il controller col model in maniera molto forte, e probabilmente anche inutile, perchè basterebbe che il model torni un risultato di un'operazione invece di invocare eventi così, a buffo. Questo ti permette poi di poter utilizzare i model in maniera trasparente da qualsiasi altro oggetto, senza bisogno che tale oggetto si registri nel model o implementi un'interfaccia specifica. E soprattutto ti permette di giocare con i model senza legarti a nessuno in particolare.

Se tu vuoi fare un oggetto che NON SIA un controller ma che cmq lavori con dei model, ad esempio per incapsulare una logica di business molto complicata ma usata in molti punti del programma, che fai? devi fare un controller che non sia un controller o cose simili? implementare interfacce inutili? estendere (dio ce ne scampi) altre classi?

cioè lo puoi anche fare, per carità ognuno è genio e inventa i modi che gli tornano piu comodi, solo che quello non è mvc, non è codice disaccoppiato, controller e model fanno piu di quello che devono fare, in particolare il model, e il model è sostanzialmente inutilizzabile da oggetti che non implementano determinate interfacce, quando lo scopo del model è essere usato in maniera trasparente e senza fronzoli.

Quoto tutto, specialmente il grassettato. Non c'e' ragione per fare cio'.

[Grino]

Originariamente inviato da k.b
Quoto tutto, specialmente il grassettato. Non c'e' ragione per fare cio'.

Se un controller estende un'altro ed fra le sue attività agisce su un model già gestitio dal padre, il metodo notifica ti permette di invocare il Notifica del padre che si occuperà della gestione. Una return queasto non te lo permette.

Se poi avete del codice migliore da mostrare condividete.

[k.b]

Originariamente inviato da Grino
Se un controller estende un'altro ed fra le sue attività agisce su un model già gestitio dal padre, il metodo notifica ti permette di invocare il Notifica del padre che si occuperà della gestione. Una return queasto non te lo permette.

Se poi avete del codice migliore da mostrare condividete.

Non mi e' chiaro lo scenario

[Grino]

Originariamente inviato da Santino83_02
Chiamalo come ti pare, ma almeno accetta le critiche. lo schema dice che il controller usa e istanzia e "manipola" oggetti di tipo model e view per mettere assieme tutto il pattern

come dicono gli stessi Dei di Zend:




le frecce tratteggiate indicano presumibilmente la chiamata di metodi sugli oggetti e il loro ritorno, come normalmente si effettua

c'è anche l'uso dell'observer come piu o meno dici te:

http://ootips.org/mvc-pattern.html

citato anche dagli stessi zendiani, solo che, come ti è stato detto prima, in un ambiente stateless è una scelta inutile. E cmq li si parla di observer tra view e model, in maniera da modificare il comportamento della view a seconda dello stato del model, non certo tra model e controller.

come dicono bene quelli di zend:



L'interazione tra model e controller è da evitare per il semplice fatto che così facendo leghi il controller col model in maniera molto forte, e probabilmente anche inutile, perchè basterebbe che il model torni un risultato di un'operazione invece di invocare eventi così, a buffo. Questo ti permette poi di poter utilizzare i model in maniera trasparente da qualsiasi altro oggetto, senza bisogno che tale oggetto si registri nel model o implementi un'interfaccia specifica. E soprattutto ti permette di giocare con i model senza legarti a nessuno in particolare.

Se tu vuoi fare un oggetto che NON SIA un controller ma che cmq lavori con dei model, ad esempio per incapsulare una logica di business molto complicata ma usata in molti punti del programma, che fai? devi fare un controller che non sia un controller o cose simili? implementare interfacce inutili? estendere (dio ce ne scampi) altre classi?

cioè lo puoi anche fare, per carità ognuno è genio e inventa i modi che gli tornano piu comodi, solo che quello non è mvc, non è codice disaccoppiato, controller e model fanno piu di quello che devono fare, in particolare il model, e il model è sostanzialmente inutilizzabile da oggetti che non implementano determinate interfacce, quando lo scopo del model è essere usato in maniera trasparente e senza fronzoli.

Ok tutto giusto, magnifico ma non mi spieghi perchè c'è una freccetta tratteggiata che va dal model fino al controller nello schema di Zend.

Mi vorrai mica dire che hanno inserito un fronzolo?

Io la mia piccola soluzione per rispondere a chi ha fatto una domanda l'ho data. E' nel terzo post. Non è certo una soluzione da produzione ma è qui. La vostra dov'è? La critica l'accetto se porta soluzioni. Qual'è la vostra soluzione?

Postate del codice... ci arricchiremo tutti!

[Santino83_02]

Originariamente inviato da Grino
Ok tutto giusto, magnifico ma non mi spieghi perchè c'è una freccetta tratteggiata che va dal model fino al controller nello schema di Zend.

Mi vorrai mica dire che hanno inserito un fronzolo?

Io la mia piccola soluzione per rispondere a chi ha fatto una domanda l'ho data. E' nel terzo post. Non è certo una soluzione da produzione ma è qui. La vostra dov'è? La critica l'accetto se porta soluzioni. Qual'è la vostra soluzione?

Postate del codice... ci arricchiremo tutti!

come ho detto, la riga tratteggiata indica l'interazione tra due elementi, nel caso specifico ritengo chiamate a metodi e loro ritorni, ma non è spiegato. E seppur fosse l'observer, ovvero far scaturire eventi che poi altri usano per modificare il proprio stato, ripeto l'idea che in app stateless come generalmente è una webapp, è una cosa inutile e irrealizzabile, e nello specifico veniva considerato come (ottimo) metodo per dire alla view che si doveva aggiornare.


Vuoi un esempio? ma come, mi citi la bibbia delle bibbie con Zend, e poi chiedi a me un esempio?

http://www.framework.zend.com/manual...ate-model.html

solo in questa pagina c'è l'esempio di un model e di un controller e non mi pare che ci siano eventi che si scatenano

notare che l'oro incapsulano l'entity del database nel model, con solo getter e setter praticamente. Poi usano quelli che chiamano Mapper (che mi ricorda tanto il caro vecchio pattern DAO) per operazioni del tipo "save","find","findAll", o se preferisci, "salva","trova","trovatutti", e il controller non fa altro che dire:

caro guestbookMapper, mi ridai tutti i messaggi lasciati dall'utente? grazie, ora che li ho tutti li do alla mia view così li renderizza come meglio crede...e lì che la view può essere una pagina html, una pagina xml, una json, etc etc etc senza che il controller sappia nulla, senza che il model sappia nulla, senza che il controller debba sapere come comportarsi col model, senza che il model sia costretto ad invocare eventi per altri oggetti etc etc...

il model è una merdina che conosce solo di se stesso
il mapper è una merdina che sa solo compiere operazioni CRUD sul suo model di riferimento
il controller è un ebete alfabetizzato che compie meccanicamente le operazioni che rappresenta
la view è un semplice "render"

direi lineare. e semplice. questo vuol dire che se cambia il model internamente al controller non gliene frega nulla, basta che il contratto non cambi. questo vuol dire che al model non interessa chi lo sta usando, lui fa il suo lavoro e basta. questo vuol dire prendere un model da un progetto e buttarlo in un altro progetto senza star troppo a guardare chi e come lo usa, senza modificare classi esistenti per accettare contratti diversi. Questo è, in definitiva, lo standard attuale che si applica nella stragrande maggioranza dei casi e che prende spunto da principi di programmazione ben precisi il cui rispetto rigoroso giova, anzi è indispensabile, alla riusabilità e manutenzione del codice proposto.

soluzioni fighissime possono naufragare miseramente quando si deve mantenerle e modificarle o aggiornarle.

questo non vuol dire che tu abbia scritto una schifezza, intendiamoci. E' che a vedere un manuale di oop, a vedere che sai in una web app, a vedere che "dici" di usare un determinato pattern, a vedere il risultato finale, secondo me stai sbagliando concettualmente determinate scelte, complicandoti la vita e ingarbugliando il codice. Detto questo, tu sei liberissimo di fare come ti pare per carità. Solo che se mi dici "mvc", l'mvc è una cosa ben precisa, strausato/abusato, quello che dici te, no.

Tanto poi per tornare a teorizzare, in applicazioni dove il programma non "muore" dopo la prima richiesta, ma vive per tutto il tempo di utilizzo (leggasi programmi desktop o simili), pattern come l'mvc non vengono adottati (o meglio, io non ho mai visto un mvc in un programma desktop), o meglio ancora, sono sviluppati differentemente (vedi gli handler di eventi di un file cs in .net che rispondono molte delle volte a interazioni dell'utente col programma).


edit: poi vabbeh, ormai penso che si stia andando in OT o cmq in una discussione che non arricchisce il 3D

[k.b]

Originariamente inviato da Grino
Ok tutto giusto, magnifico ma non mi spieghi perchè c'è una freccetta tratteggiata che va dal model fino al controller nello schema di Zend.

Relazione indiretta tramite observer. C'e' scritto. Di sicuro non chiama direttamente il controller, altrimenti avrebbe una linea continua

Originariamente inviato da Grino
Io la mia piccola soluzione per rispondere a chi ha fatto una domanda l'ho data. E' nel terzo post. Non è certo una soluzione da produzione ma è qui. La vostra dov'è? La critica l'accetto se porta soluzioni. Qual'è la vostra soluzione?

Giusto. Per rispondere alla domanda originale: il punto non e' separare codice PHP dal codice HTML, il punto e' separare la logica del programma dalla visualizzazione dell'output in modo che si possa modificare una cosa senza toccare l'altra.

Ci sono molti modi per farlo: il piu' semplice e' scrivere (anche in un unico file) prima tutto il codice che compie le elaborazioni e prepara le variabili coi risultati, e in coda il markup in cui e' presente codice PHP limitatamente all'echo delle variabili ed a strutture di controllo (e qualche saltuaria funzione sempre legata alla visualizzazione). Il passo successivo e' separare fisicamente i file e includere il file di visualizzazione in quello che elabora i dati. Poi si puo' passare ad organizzare il lavoro in classi (la OOP non e' assolutamente necessaria per la separazione dei compiti, e' una scelta) o direttamente considerare la possibilita' di utilizzare un framework, dipende anche dalla dimensione e dalla complessita' del progetto.

Comunque il punto fondamentale e' passare da questo approccio:

<?php
echo "<h3 class=\"evidenza\">Elenco dei nomi</h3>";
$result = // qualche query;
echo "<table>";
while ( $line = mysql_fetch_array($result) ) {
    echo "<tr class=\"riga\"><td class=\"cella_nome\">".$line['nome']."</td></tr>";
}
echo "</table>";
echo "<hr>";
echo "<a href=\"altra_pagina.php\" class=\"elenco\">Clicca qui</a>";
?>

a questo:

<?php
$result = // qualche query
$data = array();
while ( $line = mysql_fetch_array($result) ) {
    $data[] = $line['nome'];
}
?>

.........

<h3 class="evidenza">Elenco dei nomi</h3>
<table>
    <?php foreach ( $data as $nome ): ?>
    <tr class="riga">
        <td class="cella_nome"><?php echo $nome; ?></td>
    </tr>
    <?php endforeach; ?>
</table>
<hr>
[url="altra_pagina.php"]Clicca qui[/url]

tutto il resto puo' venire con calma, ma finche' non ci si abitua a preparare i dati prima e mostrarli poi il codice sara' sempre un casino illeggibile e un inferno da mantenere.

[michelepi]

Ok iniziate a parlare come un povero come me

Quindi nel caso di scrivere seguendo OOP, nella classe non metto nessun output html ma solo codice php che restituisce array e poi nella pagina da visualizzare con foreach prendo il dato e lo stampo?


Io sto facendo l'errore allora di stampare anche codice html nelle classi.


merci beaucoup