Domande e risposte tecniche

• Perché è stato scelto HTMLArea come editor HTML di default?
  Quando iniziò lo sviluppo di Wedgefish, nel 2005, non c'erano molti editor HTML di qualità e dal peso ridotto in circolazione.
  HTMLArea è stato quindi personalizzato correggendo numerosi errori per utilizzarlo nella piattaforma, con un notevole impiego di tempo.
  Attualmente, a seguito di svariate ottimizzazioni, le sue dimensioni risultano essere meno della metà di altri editor HTML editors, pur disponendo di tutto il necessario e offrendo un funzionamento affidabile sui browser maggiormente diffusi.
  Potrebbe essere ulteriormente migliorato in futuro, ma questo non rappresenta una priorità al momento.
  Le future versioni della piattaforma consentiranno di configurare ciascun sito web per utilizzare un editor HTML differente, ed altri popolari editor HTML verranno confezionati come moduli di Wedgefish per poter essere utilizzati dall'Editor Universale degli Oggetti.
• Perché non è stato utilizzato Smarty come motore per i templates?
  Smarty non stabilisce una separazione reale tra la programmazione ed il design. Consente infatti di inserire istruzioni condizionali e cicli all'interno del codice HTML, insieme a svariati altri costrutti.
  Nella pratica, ciò equivale a scrivere pagine PHP con una sintassi semplificata. Sebbene sia vero che il codice vero e proprio dell'applicativo venga mantenuto in files separati, il codice che gestisce la presentazione resta tuttavia memorizzato nei files HTML.
  Non bisogna mai dimenticare che vi sono molti grafici (non necessariamente dalle tariffe economiche) che sanno a malapena cos'è HTML, e che dipendono completamente da strumenti visuali per realizzare qualunque tipo di modifica ad una pagina, per quanto piccola.
  Nella pratica, Smarty rimarrebbe qualcosa di probabilmente oscuro ed estraneo a tali grafici, che tenderebbero con molta probabilità a cancellare i suoi tag di presentazione nel tentativo di riformattare la struttura della pagina secondo i loro gusti.
  Il risultato è che, utilizzando Smarty, vi ritrovereste probabilmente a dover correggere ogni template modificato da un grafico, esattamente come sarebbe accaduto utilizzando PHP da solo.
• Perché utilizzare il WODBMS, invece di un normale database MySQL?
  Il WODBMS è un'estensione al concetto di database relazionale con caratteristiche che non è possibile trovare nei sistemi tradizionali, quali campi indicizzati e multilingua, relazioni tra i campi senza necessità di utilizzare query di JOIN, possibilità di relazionare dati tra database virtuali differenti, ACL in lettura e scrittura e un'API semplificata che consente di interrogare qualunque struttura di dati, anche complessa, senza utilizzo di lunghe query SQL.
  La sua implementazione di default è comunque basata su un database MySQL, al quale vengono inviate normali query SQL generate dinamicamente.
  L'utilizzo del WODBMS consente l'utilizzo della cache dell'output con qualunque sito web e qualunque modulo che ne faccia uso, senza che si verifichino problemi di incompatibilità.
• Perché tutte le immagini sono servite dalla piattaforma, anziché da Apache?
  Vi sono vari motivi che hanno originato questa scelta, di seguito elencati:
  1. La stessa installazione della piattaforma può essere utilizzata per più nomi di dominio, da far corrispondere a differenti siti.
     A seconda del dominio selezionato, il sistema provvederà quindi a restituire l'immagine contenuta nella cartella corretta. È quindi necessario che tutti gli URL siano gestiti dalla piattaforma, incluse le immagini, affinché essa possa interpretarli correttamente. È vero che sarebbe possibile creare un virtual host su Apache Web Server per ciascun nuovo sito, ma questo renderebbe impossibile creare nuovi siti senza dover modificare ogni volta la configurazione del server
  2. Molto spesso le immagini che vengono pubblicate in un sito non possono essere restituite al browser come sono, perché essendo state scattate con una fotocamera digitale o un telefono cellulare sono di risoluzione e dimensioni eccessive e richiederebbero molto tempo, con qualunque connessione, per essere visualizzate.
     Esse devono quindi essere ridimensionate e convertite ad una qualità adatta per il web prima di essere servite.
     Sarebbe possibile svolgere questo compito una volta per tutte (memorizzando solo la versione scalata sul server) ma in caso si decida poi di cambiare le dimensioni di molte immagini, sarebbe necessario ripetere nuovamente l'upload degli originali (che spesso, nella pratica, non è più possibile recuperare); Wedgefish mantiene invece memorizzate sul server le foto così come sono state scattate, affinché sia possibile in qualunque momento rielaborarle con differenti parametri, ed anche restituire la versione ad alta risoluzione per la stampa, qualora l'utente del sito la richieda.  Le foto vengono quindi elaborate dal modulo imageprocessor e restituite dinamicamente (memorizzando i risultati in varie cache, per ridurre i tempi di risposta alle successive richieste).
     
  3. Gestire gli URL mediante la piattaforma consente di impostare il tempo di caching lato client, cioé per quanto tempo il browser dovrà mantenere nella sua cache una copia della risorsa prima di verificare che ne esista una nuova versione sul server⁽¹⁾: questo è molto utile poiché determinate immagini, quali i "captcha"⁽²⁾ sono sempre dinamiche, cioé devono essere generate ad ogni richiesta, mentre altre immagini vengono modificate raramente e possono quindi essere mantenute nella cache del browser per tempi più lunghi.
  4. Quando eseguita in modalità standalone, la piattaforma deve essere in grado di gestire tutti i tipi di URL ed associarli al sito corretto, senza poter contare sulla gestione dei virtual host del server web Apache

(1) la possibilità di specificare a piacimento il tempo di caching lato client per singolo URL e per estensione deve ancora essere implementata; attualmente il tempo di caching è 0 per tutte le risorse.
(2) il modulo imagecaptcha deve ancora essere implementato