Newsgroup: it.comp.www.php
Titolo: La Buona programmazione

ciao a tutti,	
 
	secondo voi è cosi brutto integrare parti di php nel codice html? Io ho 
iniziato da poco a programmare e mi ritrovo con parti di codice php 
all'interno dell'html!
Mi hanno consigliato ke è bene separare le due cose! Io però ho visto in 
giro software in php che nn facevano quessta distinzione! ed erano 
software di alto livello
Cosa ne pensate?

 ha scritto nel messaggio 
news:430eb...@newsgate.x-privat.org...

Mi sono chiesto la stessa cosa.
Il mio prof ritiene che il codice html vada "sparato" a video tramite 
funzioni PHP,
ma c'e' anche chi ritiene che il mio prof. sia un cretino.
Per ora io sto seguendo questo approccio, anche se credo sia più facile 
(soprattutto veloce) mischiare html con php.
Di contro si potrebbe dire che in questo modo si stia mescolando troppo la 
logica dei dati con la loro presentazione, e non sia buona progettazione.(?)
Attendiamo notizie da qualcuno di più esperto :)
Buon proseguimento a tutti,
Simone 

 logica dei dati con la loro presentazione, e non sia buona progettazione.(?)
Teoricamente, la cosa migliore e` fare dei template in HTML e prenderli
da PHP e riempirli, per poi spararli al browser.
In questo modo hai la separazione totale (tranne qualche meta-tag creato
apposta) tra php e html.
Per certe cose pero` e` sovradimensionato (siti di 2-3 pagine, per
esempio), e in alcuni casi poco flessibile, a meno di non complicare i
template o di suddividerli in sotto-template (pensa a un sito che deve
visualizzare un box solo se ci sono dati relativi, per esempio).
Certo che mischiare php e html porta velocemente a spaghetti code
difficili da debuggare e da mantenere, quindi appena la tua pagina
supera le 100 righe inizia a pensare alla separazione.
Bye.



Che se non separi il tutto finisci per andarci scemo dopo un mese di  
programmazione sul medesimo progetto (o prendendo in mano roba fatta da  
altri che non segue questo metodo).
Sull'alto livello di software che non usa questo approccio, permettimi di  
dubitare.
Tac
-- 
La netiquette prevede sign di al massimo quattro righe.
Purtroppo la mia sign in quattro righe non ci stà.

 Cosa ne pensate?
separa, separa....
a meno che non sia il sitino della mia nonna di 10 pagine... ma allora non 
basta html?
ciao
massimiliano 

10anniavanti wrote:

    IMHO
Mischiare HTML e PHP può essere più semplice all'inizio, ma poi porta via un
sacco di tempo e rende il codice molto rigido.
Separando l'interfaccia dalla logica attraverso i template, si possono
ottenere fin da subito e molto più facilmente i seguenti vantaggi:
- multilingua
- multistile
- manutenzione dell'interfaccia da parte dei non programmatori (grafici e
designer)
- riciclo del codice
- montaggio dell'output per componenti
- output differenziato riusando lo stesso codice
- nuove possibilità per la gestione dei contenuti
- facilità nell'applicazione di filtri durante l'output
- minore rischio di errori e debugging facilitato
- ...
Credo che le prime tre bastino ed avanzino, soprattutto pensando che la
manutenzione diventa sensibilmente più facile ed efficace.
    IMHO
Prova a dare un'occhiata a Smarty 
http://smarty.php.net
Nella libreria PEAR trovi anche altri template engine.
Byez!
By Design


Vero però questo finchè non diventerà un qualcosa di nativo del php, renderà 
tutto più complesso, intendo dire senza l'uso di estensioni di terze parti 
etc; ovvero un qualcosa che rientra nella logica di programmazione del php 
stesso.
Cooper.
-- 
BlueWare WebStudio
 [web:] 
http://www.blueware.it
 [msn:] 
coo...@blueware.it
 [icq:] 146781935 

 all'interno dell'html!
Fondamentalmente dipende dal progetto, anche se sarebbe buona norma 
separare sempre modello e vista per garantire maggiore scalabilità 
all'applicazione.
Diciamo che a lungo andare diventa una specie di forma mentis, per cui 
ti viene spontaneo vedere visualizzazione e dati separatamente.
-- 
Ciao,
	Fabrizio
===  
http://www.negusweb.it
  ===

mi ricorda quando ho letto lo ZopeBook sul motivo perche' esistono le
zpt e gli oggetti dtml. In zope e' obbligatorio tenere separato gli
script dai documenti web. Non so se ci siano altri linguaggi con questo
approccio.

Giovanni Dall'Olio ha scritto:

Beh, l'argomento è senza dubbio interessante.
Come affrontate questo discorso della separazione da modello e 
visualizzazione?


 Cooper.
Non ne comprendo il motivo, che differenza c'é tra un'estensione scritta in
C ed una in PHP?
Se tu stesso implementassi il templating direttamente nel tuo codice questo
non sarebbe un'estensione, quindi che differenza c'é?
Il templating ti permette di ottenere numerosi vantaggi e rispetta la logica
del pattern MVC.
PHP è un linguaggio, non un tool, con un linguaggio puoi virtualmente fare
ciò che vuoi. Anzi, è perfino possibile creare template in PHP: sono gli
stessi file di codice che crei e li unisci con l'include.
Considera che Smarty è supportato dal PHP Group.
http://www.php.net/sites.php
Byez!
By Design


Mi scuso per essermi espresso male, me ne rendo conto :( quello che 
intendevo nella sostanza è una separazione nativa del codice PHP puro dal 
codice HTML.
Attualmente infatti si usano delle estensioni (vedi smarty etc) a cui si 
richiamano librerie e via dicendo; se questo avvenisse in maniera nativa 
ovvero in modo del tutto trasparente per il programmatore sarebbe più 
semplice.
Il programmatore sa che deve curare due file:  X.PHP e X.TPL (un esempio) su 
X.TPL ci mette il codice HTML e xu X.PHP quello php. la comunicazione fra 
X.PHP e X.TPL avviene direttamente senza coinvolgere il programmatore.
Ne segue che se su X.TPL hai qualcosa del tipo:
X.TPL:
<html> <head> <title> %TITLE </title> </head> </html>
avremmo:
X.PHP
Template.Load ("X.TPL")
  Template.Variable.TITLE = "quello che vuoi te";    // Inizializzazione 
variabile %TITLE
Template.Run ();
Ho fatto un esempio di massima veloce veloce (anche errato) per rendere 
l'idea di quello che intendo in poche parole, senza che il programmatore 
insomma si debba preoccupare di dover gestire un software di terze parti 
sviluppato anche in php che svolga il compito.
Un motore diciamo cosi, già integrato in php e semplificato affinchè con il 
minor numero di operazioni (righe di codice) si possa ottenere l'effetto 
desiderato.
Non so se mi sono spiegato, ma sicuramente in questo modo l'approccio nel 
separare il codice puro dal layout sarebbe di gran lunga più semplice, 
veloce e meno problematico.


 l'effetto desiderato.
Ok, credo di avere capito che t'interessa la divisione tra logica e
presentazione ma senza usare una estensione.
Se ho capito correttamente puoi provare ad utilizzare PHP stesso come
template engine.
Ecco un esempio convertendo il tuo proposto precedentemente:
== X.inc ==
<html> <head> <title> <? echo $title; ?> </title> </head> </html>
== X.php ==
$title = 'quello che vuoi te';
include 'X.inc';
Ho cambiato il nome del file in uno che potrebbe essere processato dal
server come PHP. ;)
Questo potrebbe essere adatto ai tuoi requisiti?
La separazione tra interfaccia e logica è sufficientemente netta (basta
rispettarla) e non vengono usate estensioni; il motore è PHP stesso.
Ecco una valida spiegazione per cui questa soluzione spesso non è utilizzata
(presa da 
http://smarty.php.net/whyuse.php
):
 Why use templates at all? What is so tough about writing <? echo $title; ?>
 instead of {$title}?
 Making things easier to read wasn't a design goal, but more of a side
 effect. Using templates has huge benefits, many of which have been
 explained above. Since we are in a template environment anyways, {$title}
 is less extraneous than <?php echo $title; ?>, especially when you start
 looking at it in long pages of content, so it was pretty evident that a
 simpler syntax helps to make templates easier to read and maintain. 
Spero di esserti stato di aiuto, byez!
By Design


Non proprio,  nell'esempio fatto il file *.inc contiene ancora una volta 
codice php. Il fine invece è separare completamente il codice php dal resto.


 semplice.
Sarebbe piu' semplice, ma anche molto piu` limitato.
Pensa per esempio a una pagina con i risultati di una query di DB.
Le righe della tabella possono variare da 0 a infinito.
Fai infiniti template?
O metti che un div con bordo, titolo e data fissi, deve venire
visualizzato solo se ci sono informazioni al suo interno e deve sparire
se non ce ne sono.
Per queste (e altre cose) esistono motori di template come smarty, che,
oltre alla semplice sostituzione di variabili, implementano anche una
specie di metacodice interno.
Se dovessi fare questo dall'interno del motore PHP, avresti che:
- il codice sorgente di PHP si complica. Piu` righe di codice = piu`
possibilita` di errore.
- Devi implementare un altro parser per i template, oltre che per il
codice normale.
- Ti serve comunque una libreria esterna, che sara` .so o .dll invece
di .php
- Per piccole correzioni a questa libreria devi aspettare una nuova
release di PHP
- Devi definire (e quindi irrigidire) fin da subito la struttura che
dovra` avere il codice che la utilizza (le API) e non potrai cambiarlo
praticamente piu` per mantenere la compatibilita` col passato (con
Smarty ti basta installare una vecchia versione di smarty assieme alle
tue pagine per fare l'override di quello che c'e` a livello di sistema)
L'unico vantaggio e` la velocita` di esecuzione, che comunque sistemi di
template come smarty risolvono abbastanza bene, facendo anche caching
dei risultati e altre cose.
Bye.


Ho trattato un caso particolare, relativo alla sostituzione di variabili, 
che era quello più semplice, ovviamente non mi limitavo a quel caso 
soltanto.
Hai fatto un riferimento alle query di un db, beh in quel caso avresti un 
sub-template che richiameresti tot volte all'interno di un altro template e 
via dicendo, nulla quindi di complicato.
Il principio che illustravo prima vale anche in questo caso.


 Il principio che illustravo prima vale anche in questo caso.
Hai quotato tutto ma hai letto solo le prime 5 righe...
Una volta che hai un subtemplate come lo specifichi nel template
principale? Ti serve un linguaggio da parsare.
La lista di pregi/difetti che ho postato vale ancora.
Bye.


Non proprio, puoi tranquillamente gestire un unico template oppure puoi 
avere un template diviso in tanti sub-template che verrebbero ricomposti 
(vedi a titolo di esempio phpbb).
Nella ricomposizione, puoi richiamare tot volte un qualsiasi sub-template e 
andargli a sostituire i valori che desideri.
Alla fine otterresti sempre e comunque il template di origine.


 ha scritto il seguente 
messaggio:

-- 
Lisp Users: Due to the holiday, there will be no garbage collection on Monday.
News 2000 [v 2.06] - 
http://www.akapulce.net/socket2000

 Template.Run ();
E' la stessa cosa che fai con una libreria per i templates.


 resto. Cooper.
  IMHO
Humm..non sò come aiutarti, il templating prevede il parsing, che sia PHP a
farlo, una estensione in C o in PHP: sempre parsing è. Se vuoi separare
l'uno dall'altro devi per forza usare o implementare un parser, non vedo
altra soluzione.
Se invece vuoi usare il PHP per unire template già fatti, allora non ottieni
comunque una distinzione tra logica e presentazione: infatti stà nella
presentazione la composizione dell'output, la logica serve solo a lavorare
sui dati e ad eseguire comandi.
Accertati di non voler risolvere un problema che non esiste. (prendilo come
una battuta ed un consiglio pratico)
  IMHO
Byez!
By Design

Uhm, forse non conosci Zope, ma fa esattamente questo (con codice in
Python)
http://www.zope.it/Doc/Libri/ZopeBook/attuale/index_html/BasicObject.stx
''' C'è un problema rilevante con molti dei linguaggi progettati per
la creazione di contenuto HTML dinamico: non permettono di raggiungere
la "separazione della presentazione dalla logica" in un modo
sufficientemente semplice. Ad esempio, i linguaggi di scripting
"tag-based" ( che utilizzano marcatori ) come DTML, SSI, PHP e JSP,
incoraggiano i programmatori a includere istruzioni nel codice HTML che
risultano nella migliore delle ipotesi misteriosi agli occhi dei
grafici, il cui scopo esclusivo è quello di creare pagine web di
"aspetto gradevole ed intrigante" senza sapere ( o senza voler sapere!
) ciò che sta dietro alla generazione dinamica. In una situazione più
sfortunata, questi marcatori possono rendere l'HTML non valido,
corrotto e inutilizzabile da qualsiasi tool di web authoring.
Tipicamente un disegnatore di pagine HTML si avvale di strumenti come
Macromedia Dreamweaver o Adobe GoLive per creare un modello. In seguito
il programmatore inserisce nelle pagine speciali marcatori per
conferirne il funzionamento dinamico. Tuttavia l'approccio offerto da
linguaggi tag-based rappresenta un percorso ad un'unica direzione. Se
la presentazione dovesse subire variazioni nel tempo, il programmatore
non potrebbe semplicemente ridare al grafico la pagina a cui sono stati
aggiunti i marcatori per il comportamento dinamico, poichè questi
ultimi, non riconosciuti come validi, verrebbero eliminati dai
programmi di editing dei designer. Quindi, per attuare le modifiche
bisogna che: 1) il disegnatore crea un nuovo modello grafico e e il
programmatore inserisce nuovamente i tag; oppure 2) il disegnatore
effettua le modifiche prestando attenzione a non alterare i tag che non
siano prettamente atti alla presentazione, oppure 3) il programmatore
si assume il compito di creare anche la presentazione. Chiaramente
nessuna di queste scelte ricade in una situazione desiderabile, poiché
né il programmatore né il grafico stanno svolgendo i compiti per i
quali sono preparati. '''

 mi ricorda quando ho letto lo ZopeBook sul motivo perche' esistono le

Zope non e` un linguaggio ma un Application Server, con una filosofia
tutta sua.
Niente ti vieta, in Zope, di fare un oggetto script che contiene
print """
<html>
<head>...</head>
<body>.....</body>
</html>
"""
e quindi mischiare codice e html.
DTML, inoltre, e` un linguaggio di templating, praticamente. Come
concetto e` abbastanza simile a quello di Smarty, anche se piu` esteso e
potente (ha un AS intorno, puo` fare piu` cose).
Niente vieta di fare un AS in PHP che faccia cose simili. Per esempio
Drupal si sta muovendo in un senso simile, e tiene abbastanza separati
template, codice e dati.
Bye.

 corrotto e inutilizzabile da qualsiasi tool di web authoring.
Conosco Zope. I marcatori intesi in questo trafiletto sono quelli del PHP,
non quelli dei template engine.
I marcatori che intende sono questi:
  <?php ?>
  <% %>
  ecc..
Zope usa questo tipo di marcatore nei suoi template:
  <!--#var title-->
e lo Smarty (per esempio):
  {$title}
contando che anche Smarty può utilizzare le variabili come:
  <!-- $title -->
Alcuni template engine usano degli attributi XML al posto dei marcatori
(come PEAR::HTML_Template_Xipe se non ricordo male).
- - -
  !!!IMHO
C'é un'altra soluzione che ti permette di utilizzare template senza
marcatori.
Con l'XML crei un file per ogni pagina (perché dev'essere valido per poter
essere letto), assegni l'ID ad ogni elemento che desideri cambiare e usi
uno strumento come SAX per trovare e cambiare gli elementi partendo
dall'ID.
Oppure usi l'XSL.
Ecco i vantaggi:
- usi un'estensione già compresa nel PHP.
- il modello è facilmente replicabile anche su altri linguaggi di
programmazione.
Ecco gli svantaggi:
- oltre alla prima, usi estensioni non comprese nel PHP.
- produzione di più file per lo stesso scopo.
- le librerie attuali sono scarse ed ancora poco raffinate.
- il procedimento è molto più macchinoso.
- l'apprendimento è notevolmente più lungo.
- il tempo di elaborazione è decisamente più lungo.
- l'XSL sarà comunque creato da PHP o completato con dei marcatori.
- la struttura diventa rigida per cui si hanno meno potenzialità.
- si deve fare attenzione affinché CSS e XSL non collidano.
  IMHO!!!
Byez!
By Design