Directory di siti, quale tecnologia per mostrare i dati relativi ai siti?

[tdef]

Salve a tutti, la metto qui perché non saprei esattamente dove altro mettere questa discussione, se fuori tema pregherei i mod di spostarla nel luogo più opportuno.
Come ho accennato nel titolo, devo creare un sito che di fatto è una directory con i link a siti, una roba abbastanza comune no?
Dunque il problema è questo ed più un problema procedurale che meramente tecnico, quello semmai seguirà nei forum specifici.
Il problema che mi si è posto è il seguente: dato che tutto il materiale si trova confinato in database e dato che questo materiale contiene sia l'immagine del sito in questione (banner o altro), link, descrizione, autore, eccetera... e dato che queste informazioni saranno riassunte nella pagina in forma tabellare, mi preme trovare il modo migliore per estrarre in sequenza dal database le informazioni per creare la tabella.

1. Ho provato a creare il classico file che estrae l'immagine dal database e la mostra ma andrebbe richiamato più volte, una per ogni link, eppoi comunque dovrei fare un'altra query per estrarre i dati che mancano (link, descrizione, eccetera) quindi è da scartare.
2. Potrei anche fare una query in ingresso nella pagina che estragga tutte queste informazioni e poi la elaboro per creare la tabella (al momento la tecnologia più probabile);
3. Ultima ipotesi analizzata è quella di una chiamata ajax ed una risposta json che contenga tutti i dati da intabellare, un po' come funzionano i motori di ricerca per capirci; la cosa mi intriga ma come faccio a rendere le immagini per intenderci da json/javascript ?

Voi come vi comportereste?

Aggiungo che ho studiato la questione json e ovviamente ci sono sul web pareri discordanti.
json non è fatto per i dati binari ma vi si possono inserire e poi estrapolare se codificati in 64bit e poi decodificati.
bson permette tutto questo senza precodifica (la b sta per binary) ma va implementata a parte e non è affatto semplice, ovviamente ci sono librerie in PHP e inoltre è pienamente supportata se fosse disponibile MongoDB ma non è il caso di Altervista.

[dreadnaut]

Per prima cosa, eviterei di passare immagini con metodi non standard, perché finisci per pagare di più in termini di a) prestazioni b) codice da scrivere c) imprecazioni perché non funziona ovunque. Preparati lato server un metodo semplice per estrarre l'immagine x dal database, che restituisca l'immagine direttamente, con gli header per il corretto content-type ed il caching lato browser (max-age, etag).

Per estrarre i dati e mostrarli, parti prima con una versione html, che andrà ovunque. Una volta che quella è funzionante, poi se vuoi aggiungi un livello javascript sopra, che la renderà 2.0 e sbrilluccicosa. JS-only è spesso una pessima idea.

Come lavorare lato php? Boh, non credo ci siano metodi contorti: prima ->fetchAll() e poi inserisci i dati nel template di una pagina html (sito senza js), e in seguito anche in uno spezzone di html o in json (versione avanzata).

Poi è un periodo che sto facendo troppi front controller e REST, quindi magari mi dimentico altri metodi

[tdef]

Allora: per venire incontro alle tue obiezioni a) prestazioni? json è sicuramente più performante di altri metodi simili, è puro testo, in pratica l'unico dato ammesso dal protocollo http, il problema semmai viene dopo; b) no il codice è sicuramente il problema minore, tirare fuori i dati dal database comunque lo si deve fare, aggiungere una o due istruzioni per json è davvero ben poca cosa; c) su questo dato oramai giochiamo alla pari, javascript è supportato mi pare anche da Opera mini, il browser dei vecchi telefoni mi pare di averlo sul vecchio Nokia C3, poi basta mettere un <noscript> di avviso, insomma non posso gestire l'intero mondo degli schermi se no divento pazzo, quindi sarà sì responsive ma per gli utilizzatori classici quindi javascript sì senza grossi patemi d'animo.
Per dire di restituire l'immagine, ma è qui il problema, non è che mi manca la parte software, l'ho già creata ma ha i suoi limiti nel senso che non posso certo chiedere l'immagine che so attraverso <img src="getimage.php?id=1" ... /> tanto per dire, per ogni immagin presente nel database e per due motivi:

1. dovrei fare tante query quante sono le immagini e non mi pare il caso
2. e quante sono le immagini? Per saperlo dovrei fare un'ulteriore query preventiva, costruire la parte html come dici tu e poi in ognuna mettere la richiesta per l'immagine, e poi? Poi mancherebbero gli altri dati presenti nel DB, no così non va!

Allora ho pensato a due soluzioni, la prima semplice, non ci sono altri file che rimandano dati, tutto avviene nella stessa pagina, la query e la costruzione della tabella con i dati nelle sue celle, immagini comprese.
Due, fare come fanno da anni i motori di ricerca, cioè un file in remoto che fa la query ed emette un file (json) che viene letto in locale mostrando il risultato.
Se fossero solo scritte benissimo, ma ci sono le immagini da mostrare e qui viene il bello o il brutto perché attualmente non ho trovato una libreria in grado di gestire tali dati in javascript quindi dovrei farla io... no penso mi rifarò al metodo uno.

edit:

Trovato! Anche se non so se lo farò, pur essendo un esercizio di stile ma è interessante per chiunque passi di qui credo, l'elemento img supporta i dati binari, l'ho scoperto leggendo il codice di Google.

<img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/ la taglio qui .... />

in pratica devo fare due prove per vedere se basta passare la stringa codificata in base64 e poi se la legge da solo e se deve essere anche decodificata (da stringa a binario) comunque è ciò che mi serviva.
Ma ho visto che Google usa questo metodo quasi con tutte le immagini presenti nella pagina, in pratica con tutte quelle passate per la query di ricerca, quello che ancora non ho scoperto è la tecnologia che usa (json, bson, yaml)?

[dreadnaut]

Forzare js vuol dire mandare a quel paese l'accessibilità e la navigazione. Se per te non è un problema, fai pure. pushState ti sarà essenziale.

Encoding di un'immagine in testo/json vuol dire base64, cioè un incremento del 33% dei dati inviati. Speriamo che gzip ti aiuti a questo punto. Come alternativa, ti butto li quella di costruire un'immagine unica via gd, e poi tagliarla lato client, a mo' di sprites.

Per il resto, purtroppo manca del contesto, ed alcuni termini sono ambigui. E.g., intendi query http o query sql?

edit:

Ma ho visto che Google usa questo metodo quasi con tutte le immagini presenti nella pagina, in pratica con tutte quelle passate per la query di ricerca, quello che ancora non ho scoperto è la tecnologia che usa (json, bson, yaml)?

Il log delle operazioni di rete di Firefox è ottime per queste cose. Cercando "alberi" su google images, e scrollando in fondo alla pagina, cosa viene richiesto?

Un bloccone di codice html recuperato via xmlhttprequest con i nuovi risultati da mostrare:
http://www.google.co.uk/search?q=alb...tart=100&csl=1

pieno di tag img che puntano a singole immagini:
http://t3.gstatic.com/images?q=tbn:A...rW1q6aYSvllslB

come da me suggerito sopra

[tdef]

Ma scusa perché javascript dovrebbe limitare l'accessibilità, oramai anche i lettori di schermo interpretano js?

PS l'ho visto con il profiler di Chrome, Firebug non ce l'aveva fatta

[dreadnaut]

(consiglio Ctrl-shift-k in Firefox —Firebug serve sempre di meno)

Ci sono solo un paio di screen reader che supportano javascript, ma il problema è più generale. Siccome non sai mai cosa l'utente potrebbe utilizzare, l'unico metodo sicuro è fornire html pulito, e poi aggiungere javascript sopra, per chi può.

Oppure puoi decidere di limitare l'insieme dei tuoi visitatori a priori e sviluppare come preferisci. Non è un problema, basta sapere che è una scelta con delle conseguenze.

[tdef]

Sei un po' troppo categorico tra gli screen reader che citi tu c'è sicuramente jaws che legge javascript e che è sicuramente il più usato, anche perché lo passa la "mutua" per capirci, almeno in parte.
Poi non so cos'è oggi che non legge javascript, ajax è supportato da IE5.5 xmlhttprequest è una raccomandazione W3C, i browser principali lo leggono perfettamente, anche sui telefoni, francamente non capisco tu di cosa ti preoccupi, se fosse tutto questo problema dubito che FB avrebbe avuto l'ascesa che ha avuto o Flickr o la stessa Google o Yahoo! che per prima ha usato json e quindi javascript, tanto per citare solo i più noti.
Non penso di limitarmi nella mia scelta, ho chiesto già ad amici ipovedenti e non vedenti e mi hanno chiaramente detto che il problema è abbastanza superato nell'ordine del 99% semmai gli ipovedenti mi hanno pregato di evitare di mettere tasti per il ridimensionamento dei caratteri che a quello ci pensano loro.

[dreadnaut]

non capisco tu di cosa ti preoccupi, se fosse tutto questo problema dubito che FB avrebbe avuto l'ascesa che ha avuto o Flickr o la stessa Google o Yahoo! che per prima ha usato json e quindi javascript, tanto per citare solo i più noti.

Mi preoccupo che le cose funzionino, perché se non funzionano non porto a casa la pagnotta —o la porto a casa con molta più fatica. Guardati in giro e noterai che fra graceful degradation e progressive enhancement, la pratica è quella.

Comunque, mi stai citando tutta una serie di siti che funzionano anche con javascript spento, esattamente come ti stavo dicendo, quindi me ne sto