Newsgroup: it.comp.www.php
Titolo: resize immagini automatico

Ciao,
voglio implementare una classe che crei delle thumbnail secondo i 
parametri che desidero. L'applicazione in cui verrà integrata segue il 
paradigma MVC. Ho individuato due approcci:
1) l'attributo src del tag img chiama un controller che esegue il resize 
e si occupa di gestire la cache delle immagini ridimensionate e di 
spedire eventuali header "304 Not Modified" al browser, mandando in 
output direttamente i byte dell'immagine.
es: src="/images/100x100/path-immagine-da-ridimensionare.jpg"
In questo modo ogni immagine corrisponde ad una esecuzione 
dell'applicazione che esegue il routing al controller.
2) Fare tutto il lavoro durante la creazione della pagina html. In questo 
caso la classe dovrebbe fare il resize e gestire la cache, inserendo 
negli attributi src del tag img i link alle immagini ridimensionate 
realmente esistenti sul filesystem.
Quale dei due approcci e migliore, e quali sono sono secondo voi vantaggi 
e svantaggi?
Ciao e grazie,
Leo

 ridimensionate realmente esistenti sul filesystem.
Io ho seguito questo approccio, ma la mia classe non sa niente di HTML.
Semplicemente, nell'html, metto
<img src="<?php echo $baseUrl . $data->thumbURL($nomeimg, $x, $y, 
$parametri); ?>" />
$data e` il mio "oggetto dati" (la news, il prodotto o quello che e`), e 
thumbURL e` un suo metodo che restituisce l'URL dell'immagine. Dentro la 
classe che rappresenta $data ho un array delle immagini associate (che 
posso appoggiare semplicemente al fs facendone uno scan quando serve, o 
al DB con una tabella relazionata). Questo array e` composto da oggetti 
di tipo Base_Image (definita da me, secondo standard di nomenclatura 
Zend) con le funzioni per thumbnailing.
Del caching e dell'indicizzazione delle immagini, oltre che dell'upload e 
dell'eventuale mangling dei nomi per adattarli al FS, si occupa 
direttamente la classe di $data, ma in realta` eredita tutto da 
Base_Db_Table_Row_Extended (sempre definita da me estendendo 
Zend_Db_Table_Row).
E` un po' arzigogolato da spiegare, ma nella realta` e` piu` semplice del 
previsto.
Il baseUrl non lo faccio gestire a loro per non portarlo troppo in giro o 
per non legare troppo strettamente queste classi al Bootstrap (e quindi 
le posso usare anche in progetti non-MVC).
Bye.



Il primo approccio ha il vantaggio di poter assegnare delle url 
arbitrarie ai file. Con il secondo (a cui mi ero orientato per motivi di 
prestazioni) quando faccio un link ad un file presente in cache sono 
costretto a dargli il suo nome reale. Nel mio caso visto che ho una 
classe Cache che crea dei nomi di questo tipo:
PREFIX		CACHE_ID		TIMESTAMP
Medusa__0b64db3e4729ebabe3a50953858134e0__1261570429
pensi che possa essere uno svantaggio in termini di motori di ricerca? è 
meglio estenderla per creare dei nomi "reali"?
Ciao, Leo

 meglio estenderla per creare dei nomi "reali"?
Si`, visto che nessun motore ti indicizzera` degli hash. E comunque 
nessuno li cercherebbe. :)
Se ti interessa aumentare il SEO anche tramite immagini, rivedi 
l'algoritmo di caching.
Bye.



Grazie mille, sei stato molto chiaro.
Ciao, alla prossima
Leo

 /data/nometabella/id/nomeimmagine-100x100-fill
Ciao,
mi viene in mente una domanda.
Che formato usi per la data? se ti serve per invalidare la cache quando 
il file originale viene sovrascritto dovrebbe avere una certa precisione.
Un timestamp? o 2009-01-14 ma poi mancano i secondi.
Il secondo formato mi piace di più ma non è abbastanza preciso...
Ciao, Leo

 mi piace di più ma non è abbastanza preciso...
Uso lo Unix timestamp, con precisione al secondo, tanto alla cache non 
interessa che il formato sia leggibile. :)
In generale uso il timestamp per tutto (anche per le date in DB), e lo 
trasformo in "leggibile" solo al momento della stampa (perche` cosi` 
posso usare sia il banale date("d/m/Y") che il più internazionale strftime
()
Bye.