Skip to topic | Skip to bottom
Home

TechWeb12
TechWeb12.FAQ1112r1.24 - 24 Jan 2012 - 05:55 - MarcoChiappettatopic end

Start of topic | Skip to actions
DISCLAIMER: La seguente raccolta di domande frequenti (Frequently Asked Questions) potrebbe contenere errori (sia sintattici che logici che tecnici). Il lettore e' pregato di segnalarlo ad uno o piu' membri del WorkingGroup che provvedera' alla correzione.

IN EVIDENZA: Come risolvere l'errore "Origin ... is not allowed by Access-Control-Allow-Origin" nelle richieste Ajax

Ci sono due modi (almeno i due che ho trovato io). Uno è corretto, l'altro è "sporco" e "insicuro" ma funziona comunque. Il primo è di usare JSON-P al posto di Ajax (se anche voi state facendo questa faccia -> O_o sappiate che non siete i soli) e non se ne parla neanche. Il secondo è di integrare, nei propri descrittori, in OGNI risposta HTTP inviata, una cosa del genere (esempio in PHP):

header('Access-Control-Allow-Origin: *');

In questo modo si consentono richieste asincrone (come Ajax, appunto) da domini esterni. RICORDA: gli header funzionano "a cascata" (purché non si sovrascrivino esplicitamente), quindi si possono effettuare più chiamate sequenziali della funzione header(..) senza incorrere in alcun problema!

In cosa consiste il progetto Meta Market?

Il progetto Meta Market consiste nell'elaborazione di un sistema informativo che aggreghi informazioni di vario genere circa attivita' commerciali (locazioni, orari ecc.) e svolga funzioni di filtraggio, comparazione, rielaborazione, descrizione e visualizzazione di queste ultime sottoforma di diversi "layout" (mappa con marker, tabella, timeline ecc.) chiamati "narratori". Il lavoro di elaborazione e' distribuito su 3 elementi fondamentali: aggregatori, descrittori e, appunto, narratori.

Integrazione:

Risposta "as is" del Prof. Vitali alla domanda "I progetti dei vari gruppi devono essere fatti per mostrare, se richiesto dall'utente, TUTTI i dati di TUTTI gli aggregatori (separati per categoria o simili) oppure soltanto un sottoinsieme di questi? (p.e. Solo farmacie e supermercati)":

"Il narratore non deve soltanto visualizzare i dati (né tutti i dati né parte dei dati). Se così fosse si chiamerebbe visualizzatore, e se li dovesse visualizzare di tutti i dati si chiamerebbe visualizzatore generico o visualizzatore totale. Il narratore deve fornire una visione completa ed interessante (cioé: deve narrare) una serie di dati necessari per fornire un servizio utile. Quali dati? Quelli necessari per fornire un servizio. Quale servizio? Un servizio utile.

Il vostro obbligo è usare il protocollo per accedere ai dati e elaborarli, confrontarli, trasformarli, crearne di nuovi. La differenziazione tra progetto e progetto, quello che creerà progetti belli o progetti brutti, progetti interessanti o progetti appena accettabili, sarà data dalla vostra capacità di immaginare un servizio utile che usi in maniera interessante i dati che vi ho dato e ogni altro dato che vorrete creare o che troverete già creato dagli altri gruppi o in rete."

In cosa NON consiste il progetto Meta Market?

Il progetto Meta Market non consiste nello sviluppare un'applicazione che si limiti a seguire le specifiche del protocollo! L'applicazione sviluppata deve rivelarsi una narrazione interessante e utile. Un progetto che si limiti ad essere compatibile con il protocollo non e' un buon progetto. Un progetto che si limiti a visualizzare i dati "grezzi" non è un buon progetto.

Cosa sono gli aggregatori?

Gli aggregatori sono semplici moduli software (server-side) che sono in grado SOLO di filtrare dati pre-esistenti. Ogni aggregatore non legge che il proprio formato e la relazione tra aggregatori e insiemi di dati e' di uno a uno (es. ci sara' un aggregatore per le farmacie, descritte in un file XML, che lavora SOLO su XML, un aggregatore per i supermarket, descritti in un file JSON, che lavora SOLO su JSON ecc.). Un aggregatore ha dei requisiti fondamentali: deve poter filtrare seguendo l'interpretazione dei parametri nell'URL di richiesta descritte nelle specifiche del protocollo, deve poter restituire SOLO un sottoinsieme (non necessariamente proprio) dei dati raccolti nel file letto e deve poter rispondere a richieste provenienti da QUALSIASI descrittore.

NOTA: Un aggregatore non puo' restituire, ad esempio, l'indirizzo di una location ma deve restituire L'INTERA location. Il lavoro e' sulle location, non sulle parti di queste. Un aggregatore che restituisce, ad esempio, la lista dei nomi delle location a cui è legato NON è un aggregatore (fermo restando che una feature tale può essere inclusa come "valore aggiunto" OLTRE a quelle descritte nel protocollo).

Cosa sono i descrittori?

I descrittori sono moduli software (server-side) che si occupano di 3 cose: trasformazione di una richiesta complessa (es. "quali luoghi sono aperti il Martedi dalle 16.00 alle 18.00") in una o piu' richieste/funzioni semplici (es. "chiedo all'aggregatore di darmi tutti i luoghi aperti di Martedi"-->"di tali luoghi prendo SOLO quelli che hanno intervalli di apertura che comprendono tutto o parte dell'orario richiesto"); conversione da qualsiasi formato ricevuto da eventuali aggregatori, definito nel protocollo, a qualsiasi formato richiesto dal narratore, definito nel protocollo (se il descrittore restituisce un valore semplice e' sufficiente restituire un text/plain con il risultato: stringa, numero, booleano ecc.) e, infine, la possibilita' di essere contattati (di ricevere richieste) dai narratori del gruppo che ne ha acquistata una copia durante la Fiera. I descrittori NON sono restrittivi come gli aggregatori. La qualità e l'interoperabilità sono due fattori che aiutano a venderne/utilizzarne più copie ma il comportamento dei singoli descrittori NON è coperto dal protocollo.

Cosa sono i narratori?

I narratori sono moduli software (client-side) che si occupano di visualizzare l'informazione, gia' elaborata dal descrittore, in layout che rendano la lettura delle informazioni utile, piacevole e costruttiva. Essi, per ogni richiesta a descrittori, devono precisare il formato dei dati che vogliono ricevere (ad esempio se il mio narratore si rivolge ad un descrittore semplice si preparera' a ricevere text/plain, se invece si rivolge ad un descrittore strutturato si preparera' a ricevere un formato, scelto a priori tra quelli presenti nel protocollo). Un narratore non si limita a visualizzare i dati ricevuti dal descrittore ma si occupa di strutturarli in maniera tale che la user-experience sia sufficientemente buona. In alcuni casi la strutturazione dei dati, in un formato piu' descrittivo (es. HTML), puo' spettare al descrittore (dipende dal tipo di descrittore che si va ad implementare, vedi pagina "Descrittori approvati").

In che maniera comunicano i vari componenti del progetto?

Qui entra in gioco il protocollo. La comunicazione tra i vari componenti avviene tramite richieste e risposte HTTP. Le richieste sono effettuate tramite metodo GET (opzionalmente e' possibile richiedere solo l'header lanciando una richiesta con metodo HEAD) e DEVONO essere costruite secondo le specifiche. Di seguito e' descritto cio' che viene chiamato un esempio di "processo Meta Market", ovvero un esempio di comunicazione completa tra i vari componenti:

  1. L'utente, tramite una certa interazione con l'interfaccia grafica, desidera sapere quali farmacie sono vicine alla sua posizione in quel momento.
  2. Il narratore genera una richiesta al descrittore "tipologia" chiedendogli di restituire tutte le location che hanno tra le categorie "farmacia" in un determinato mime-type.
  3. Il descrittore "tipologia" si occupa quindi di richiedere a uno o più aggregatori (dipende da com'è strutturata la narrazione) tutte le location le cui categorie contengono "farmacia" (tripla: category_CONTAINS_farmacia).
  4. Ogni aggregatore che riceve la richiesta di cui sopra si occupa di filtrare le location e restituire il sottoinsieme richiesto.
  5. Al descrittore arriveranno tanti dati in formati differenti. Suo compito è di convertirli nel formato richiesto dal narratore e restituirli.
  6. Il narratore visualizzerà sulla tabella i dati arrivati. Ma l'utente è anche interessato a sapere quali di queste location sono aperte. Dunque il narratore ha due scelte: chiamare un secondo descrittore da 6/9 crediti che restituisca solo le location aperte (e fare un'intersezione dei dati) oppure chiamarne uno da 3 PER OGNI LOCATION. In quest'ultimo caso il narratore si limiterà a interrogare il descrittore (ad es.) "è aperto" indicandogli, di volta in volta, gli opening delle location che ha precedentemente ottenuto.

L'intero processo si basa su tecnologie AJAX. Cio' significa che: 1) l'URL nella barra degli indirizzi NON CAMBIA MAI e 2) La pagina non verra' MAI aggiornata. Bisogna stare attenti alla possibilita' che l'utente, molto ingenuamente, possa cliccare su "Indietro", comportamento non coerente (se non con vari artifici) con un'applicazione AJAX.

A cosa serve il metacatalogo? E i cataloghi?

Il metacatalogo riunisce tutti gli URL dei cataloghi dei vari gruppi. E' un file che, superata una certa data, viene congelato e rimane immutato per tutta la durata del progetto. I cataloghi, al contrario, sono risorse "locali" al server di ogni gruppo che possono essere aggiornate dinamicamente (aggiunta/rimozione di componenti). Essi si occupano di riunire TUTTI i componenti sviluppati dal gruppo proprietario del catalogo (eccetto i narratori).

In cosa consiste l'acquisto di un descrittore? Posso utilizzare tutti i descrittori che voglio?

La risposta alla seconda domanda e', brutalmente, si. C'e' un ma! Il protocollo uniforma la comunicazione tra i vari componenti, vero, ma non puo' occuparsi di stabilire cosa e come devono essere i risultati restituiti dai vari descrittori. Quello e' compito di chi sviluppa ogni descrittore. Un esempio: se dal mio narratore invio una richiesta al descrittore "Aprira'" DEVO sapere a priori che tipo di risultato mi verra' restituito. Non e' plausibile che ogni narratore riesca a comunicare con tutti i descrittori e conosca, a priori, cosa gli verra' restituito. L'unica maniera e' stabilire un contatto diretto con quel descrittore. Per questo motivo esiste la Fiera. Quando si acquista un descrittore di un altro gruppo, e' NECESSARIO rendere compatibili (interoperabili) al 100% il proprio narratore con quel descrittore (e quindi conoscere in anticipo se restituira' dati strutturati o semplici, se strutturati in che maniera? ecc.). Una specificazione del genere non è da includere nel protocollo.

I miei descrittori possono o devono comunicare con tutti gli aggregatori? E il mio narratore?

I descrittori non sono costretti a comunicare con TUTTI gli aggregatori ma solo con quelli a cui si è interessati. È però anche vero che TUTTI gli aggregatori DEVONO POTER essere interrogati da TUTTI i descrittori. I narratori DEVONO poter comunicare ALMENO con i descrittori acquistati e, ovviamente, con quelli sviluppati dal gruppo proprietario dei narratori. La comunicazione con altri descrittori e' un "di piu'". Rendere compatibile un narratore con un descrittore significa includere, nel narratore, la possibilita' di richiedere il servizio al descrittore.

Tutti i descrittori devono comunicare con degli aggregatori?

Assolutamente no. Dipende dal tipo di descrittore. Ci sono descrittori che ricevono in input (come text/plain) una stringa di orari opening/closing e restituiscono valori come true/false, interi ecc. (sempre sottoforma di risposta HTTP text/plain). In questo caso sara' il narratore ad occuparsi di prelevare il campo interessato, location per location, e inviarne il valore al descrittore per utilizzarlo. Altri descrittori (strutturati), invece, devono per forza rivolgersi a uno o più (se sono parametrici) aggregatori. I primi sono, solitamente, descrittori da 3 crediti, i secondi da 6 o da 9.

Se genero nuovi dati devo rispettare qualche convenzione?

E' OVVIO che tutti i nuovi dati generati dai vari gruppi debbano seguire le specifiche del protocollo (adattate per ogni formato). Ovvero: avere OBBLIGATORIAMENTE le 5 chiavi (in XML come elementi/attributi, in JSON come sotto-oggetti ecc.) ed essere validi secondo i vari documenti di sintassi/semantica (DTD, ontologie ecc.). E' dunque automatico che un documento che rispetti il modello descritto nel protocollo sia ritenuto "valido" per l'utilizzo nel progetto Meta Market. Fare attenzione soprattutto al formato delle date!

Il protocollo è stato aggiornato e ora devo modificare tutto! Che faccio?

La risposta sembrerebbe brutale e scontata (e per certi versi lo è) ma non è detto. Se ciò che hai scritto è qualcosa che è stato "rimosso" dal protocollo, puoi continuare a mantenerlo funzionante. Il protocollo stabilisce cosa DEVE e PUÒ essere fatto e non (salvo casi particolari) cosa NON DEVE essere fatto. Se invece il cambiamento prevede la forzata modifica di uno o più "moduli" (aggregatore, descrittore e narratore) un motivo c'è e, se vuoi che il tuo progetto funzioni, DEVI attuare le modifiche. Se ritieni che le modifiche effettuate al protocollo siano inutili puoi comunque segnalarlo.

NOTA: Chi ha già inserito il sorting negli aggregatori NON È COSTRETTO rimuoverlo! Realisticamente, però, non verrà usato da nessun gruppo poiché assente dalle specifiche del protocollo.

A cosa serve il punto negli orari? E i due punti? Come mai e' presente un tale pattern?

Il punto serve a delimitare intervalli di orari. Significa che le stringhe separate da "." saranno tutte del tipo [PATTERN]:[TIME] (punto escluso, ovviamente). Orari che abbiano un aspetto simile a "[PATTERN]: ." sono da considerarsi orari di chiusura. Perche? Perché non ha senso inserire una data o un giorno di apertura senza il relativo orario! Mentre ha senso (ed è infatti presente in tutti i dati) inserire una data di chiusura (senza orario). I due punti, invece, separano [PATTERN] (intervallo di date o giorni settimanali) da [TIME] (intervallo di orari). Tutti gli orari di tutti i documenti (creati ed esistenti) devono rispettare questa sintassi. Se trovate errori segnalate e/o correggete. Un semplice parsing si basa sul fatto che ciò che è presente FINO ai : è [PATTERN], il resto è [TIME].

Come mai i narratori non hanno un URL individuale?

Crediamo che i narratori siano soltanto "funzioni" all'interno di codice Javascript. Tale struttura non permette di identificare un narratore di un certo tipo (ad es. tabella) tramite un URL specifico. Al contrario esiste un URL che racchiude tutti i narratori (ovvero l'interfaccia web dell'applicazione) e, all'interno del catalogo, sono segnalati solo i TIPI di narratori implementati (tramite l'attributo class). Potremmo, pero', aver fatto un errore di valutazione. A tal scopo vi chiediamo di avvertirci se vi doveste rendere conto che una struttura del genere potrebbe portare a dei problemi seri.

Come funziona il descrittore "È Aperto?"

Esattamente come si può intuire: gli si da un elemento "complesso" ([PATTERN]:[TIME]) e un intervallo semplice del tipo "Mar: 1220-1330" oppure "2011-12-25: 1630-1730". Il descrittore si occupa di vedere se l'intervallo semplice "fa match" con quello complesso. Come? Innanzitutto converte eventuali date in giorni settimanali (mantenendo anche il formato di data!) e verifica due cose "a cascata": se la data è all'interno di un closing la location è chiusa, punto; altrimenti verifica che il giorno ottenuto dalla conversione della data sia presente tra i giorni di apertura settimanale. Se e soltanto se cosi fosse si preoccupa di verificare il matching tra gli intervalli di orari. Eventuali comportamenti aggiuntivi (come l'uso di wildcards per affermare cose come "tutti i Giovedi di Dicembre") aumentano la "qualità" del descrittore.

Ho trasferito gli script sul server di dipartimento ma non funziona più nulla! Cosa devo fare? COSA DEVO FAREEE???

Verifica che:

  1. I permessi degli script siano nella forma 755 o 775 (se si vogliono dare permessi in scrittura anche ai membri del gruppo). L'interprete PHP NON PERMETTE l'esecuzione di script i cui permessi siano 777 (ovvero permessi di scrittura dati a "tutti"). In tal caso restituirà un errore 500 e non un 401/403 (perché i permessi sono troppi e non troppo pochi).
  2. Il file index.html sia presente nella subdir html del tuo spazio web. L'assenza di tale file per più di 2-3 ore comporta la disattivazione dello spazio web! Verifica SEMPRE prima che lo spazio web sia attivo visitando la pagina index.html.
  3. Gli script PHP non comincino con un LineFeed? o un CarriageReturn? (= ritorno a capo). Prima della Processing Instruction (anzi, è sconsigliato da molti).

Alcuni link utili: - I permessi in *nix: http://en.wikipedia.org/wiki/Filesystem_permissions#Traditional_Unix_permissions
- Perché non chiudere i tag php: http://drupal.org/node/263859 (e tanti altri)

-- MarcoChiappetta - 17 Jan 2012


to top

You are here: TechWeb12 > FAQ1112

to top

Copyright © Fabio Vitali 2017 Last update of FAQ1112 on 24 Jan 2012 - 05:55 by MarcoChiappetta