Newsgroup: it.comp.www.php
Titolo: Il contenuto è lo stesso, la grafica cambia...

Nel mio filone ispirato di oggi, ecco un altro quesito "hot". :-)
Volendo realizzare per un'"applicazione web" (genericamente qui intesa 
come "tutto" ^_^) la possibilità di modificare l'"interfaccia grafica" 
(diciamo in generale la visualizzazione degli elementi, dalla A alla Z, 
includendo tutto [quindi non solo ciò che potrei fare comodamente con 
un css, ma proprio tutto, ad esempio, che so, con un'interfaccia metto 
del contenuto in un div in alto a destra, e con un'altra interfaccia 
metto quello stesso contenuto in una cella di una tabella posizionata 
in basso al centro]) come ci si dovrebbe muovere?
Per fare un esempio banale, in tutti i cms comuni c'è la possibilità di 
cambiare i "temi": il contenuto resta lo stesso, ma la disposizione 
cambia completamente.
Come si lavora per giungere a tale obiettivo?
rob4you

 
Template engine ?
	Francesco

 Come si lavora per giungere a tale obiettivo?
Si lavora stando in ginocchio sui ceci! :)
Come dice Francesco, ti fai (o usi) un template engine.
Io ho trovato molto interessante quello di Drupal (PHPTemplate), che
suddivide i template in base agli elementi della pagina. Li` ci sono solo
nodi e blocchi, ma puoi estendere il concetto a piacere.
Puoi farti un template per la news, uno per il feed rss, uno per la scheda
prodotto, ecc. ecc. Idealmente, ragionando a oggetti, crei per ogni classe
dell'oggetto una classe gemella per l'interfaccia.
Alla fine ti fai un template "pagina" che include i vari pezzi nell'ordine
che preferisci. Ti basta cambiare questo template per spostare i pezzi.
Io consiglio di "abusare" del semantic web, in modo da avere meno rogne in
seguito. Per esempio, per le news avrai un template simile a:
<div class="news">
  <span class="title"><?php print $news->title; ?></span>
  <span class="date"><?php print $news->date; ?></span>
  <div class="content"><?php print $news->body; ?></div>
</div>
che puoi lasciare come file esterno da includere pre-impostando $news,
oppure infilare in una classe/funzione
<?php
function news_box($news) {
  ?>
  ...
  <?php
}
?>
Bye.

 seguito. Per esempio, per le news avrai un template simile a:
a questo punto quale miglior template engine di xml+xslt?
con php generi l'xml dinamicamente, e poi lo associ ad un xslt statico
(o se proprio vuoi fare il fine generi anche quello dinamicamente, da
un pannello di controllo wysisyg ;))
se vuoi vedere un esempio di come si fa e come funziona:
http://www.zend.com/php5/contest/contest.php?id=92&single=1
 (php5
ovviamente :P)



Stabilendo un'interfaccia rigorosa e uno strato applicativo che si occupi  
della trasformazione in markup. Nella maggior parte dei casi non conviene  
granchè.
Il sistema piu' utilizzato (in generale, non solo in php) è xml + xslt, è  
anche quello che ti dà piu' strumenti per il controllare l'integrità dei  
dati.
Altrimenti un template engine può fare al caso tuo (X-Template, Smarty e  
via dicendo).
In ultimo anche un sistema Mvc ( CakePhp e via dicendo ) può dare una mano.
Saluti
Tac
-- 
Using Opera's revolutionary e-mail client: 
http://www.opera.com/mail/

 Nel mio filone ispirato di oggi, ecco un altro quesito "hot". :-)
Guarda, premesso che ho letto tutto il thread e che non ho mai lavorato  
pesantemente sulle lingue.
Farei una tabella con una colonna indice (contenente un ID testuale) e una  
colonna x ogni lingua.
ID 		italiano 		inglese 		tedesco
t_bye		ciao			bye			tchus
Questo ti dà il vantaggio di poter controllare facilmente tramite sql  
quando una lingua non è del tutto aggiornata.
Per i campi aggiornati non mi esprimo.
Prestazioni: leggerei tutta la tabelle per la lingua richiesta a inizio  
pagina ( SELECT ID, italiano from traduzioni ) e metterei tutto in un  
array. Nel caso divenga troppo lento come sistema (ma cambia a seconda del  
tipo di hosting) tenterei di cachare il contenuto della tabella in una  
serie di files php da includere. Ma è un passo che difficilmente si  
renderà necessario.
Ciao


 php da includere. 
A questo punto perché passare per il db e non lavorare direttamente sui 
files?
Pensando ai db, mi è venuto un altro dubbio in mente: con una tabella 
fatta come dici tu, posso gestire soltanto campi testuali, tutti dello 
stesso tipo? Se volessi gestire variabili numeriche intere dovrei 
creare una tabella per i numeri interi, idem per i numeri float, idem 
per le date, giusto?
rob4you

 date, giusto?
Beh, che te ne fai di campi non-stringa quando devi gestire delle  
traduzioni (che sono testuali per definizione) ?
Gestire formati monetari e via dicendo trascende il discorso (cerca con  
google I18N) ed è una questione + complessa.


 piccole applicazioni/frameworks.
Grazie di tutti i consigli. ;-)
rob4you

t_bye		ciao			bye			tchus
Ti conviene farlo con tre colonne soltanto: ID, LANG e CONTENT.
Per verificare i campi dove l'inglese non e' aggiornato puoi fare con
una LEFT JOIN della tabella con se stessa:
SELECT DISTINCT base.ID FROM traduzione AS base, traduzione AS controllo
	ON (base.ID = controllo.ID AND base.LANG != controllo.LANG AND
	controllo.LANG = 'en_US') WHERE controllo.LANG IS NULL;
L'indice per LANG, ID ti consente una ricerca abbastanza veloce. Inoltre
per testi molto lunghi, non ha senso tradurre la pagina frase per frase,
e conviene tenersi una directory di soli contenuti del tipo
	/INTL/en_US/text/about.html
...probabilmente se ci sono testi in grafica (es. loghi) uno avra' anche
una directory
	/INTL/en_US/images/
...a quel punto il blocco /INTL/en_US piu' gli elementi della tabella di
traduzione con LANG='en_US' costituiscono il pacchetto en_US (non serve,
cosi', cambiare il codice o la struttura della tabella per aggiungere la
lingua XYZ).
Volendo esagerare, in PHP si puo' usare preg_replace e callback, in modo
da scrivere roba come <input type="button" value="%%%SAVE%%%" /> e avere
la traduzione automatica di 'SAVE' in "Salva" ecc.
Leonardo e i suoi .02 %%%t_valuta%%%
-- 
Geordie - he's a man, there's little doot about't,
He's done all he can, wha' can do withoot't?
Doon there cam a blade, linkin' like me lordie,
He wad drive a trade, a' the loom of Geordie.

 Leonardo e i suoi .02 %%%t_valuta%%%
:-d ...io direi .02e100 euro! :-)
rob4you

sostituirla al "segnaposto". :-)
Si', ma lo devi fare in un posto solo: mi spiego, in una fase (la piu'
tardiva possibile ;-) ) della generazione dell'HTML, oppure, al limite
anche operando sull'output_buffer, fai un preg_replace_callback che si
va a cercare "%%%([A-Za-z0-9]+)%%%", e lo passa a una funzione come la
seguente:
	function localize($string)
	{
		GLOBAL $LANG, $langCache;
		if (!isset($LANG))	$LANG = 'ENG';
		if (!isset($langCache))	$langCache = array();
		// Attenzione...! se LANG da qualche parte si puo'
		// schiantare client-side, qui c'e' una injection
		// facile facile. Es.: impostare un LANG uguale a
		// "!';SELECT+passw+FROM+users+WHERE+user='admin"
		if (!isset($langCache[$string]))
		{
			$exec = SQLExec("SELECT ... LANG='$LANG'");
				$langCache[$string] = "<span
style=\"langerror\">$string</span>";
			else
			{
				$tuple = SQLFetchTuple($exec);
				$langCache[$string] = $tuple['CONTENT'];
			}
			SQLFree($exec);
		}
		return $langCache[$string];
	}
Leonardo


 		}
Penso comunque di aver capito l'idea....mi piace! ;-)
rob4you

> 			{
Leonardo


>> 			{
Ora tutto è magicamente chiaro! :-) Grazie!!
rob4you

 Ti conviene farlo con tre colonne soltanto: ID, LANG e CONTENT.
Vero, è piu' flessibile e normalizzato. In realtà, volevo proporre una  
soluzione semplice.


soluzione semplice.
Intendiamoci: per una sola lingua - o due - mi sa che e' meglio la tua,
di soluzioni. Senza join, e alla via cosi'.
E' che per esperienza ho visto che un progetto che nasce "piccolo" dopo
un po' subisce il temuto 'creeping featurism', specie se il committente
non aveva le idee chiare in partenza... ed i committenti si dividono in
due categorie: quelli con le idee poco chiare e quelli che volano.
Leonardo pessimista


 due categorie: quelli con le idee poco chiare e quelli che volano.
Mai visto un cliente con le ali. :-)
Hai perfettamente ragione. Un altro aspetto da considerare è che forse  
YAGNI ( 
http://c2.com/xp/YouArentGonnaNeedIt.html
 ).
Con un minimo di esperienza e un occhio all'incapsulamento puoi cambiare i  
meccanismi di fondo in modo relativamente indolore (ovviamente smazzandosi  
l'esportazione nella nuova struttura dati).
Il Test Driven Development aiuta e anche molto, ma non sempre è così  
semplice da implementare.


semplice da implementare.
Nulla e' mai semplice 8-|
Leonardo
