Skip to topic | Skip to bottom
Home
TechWeb07
TechWeb07.WorkingGroupACDFr1.149 - 29 May 2007 - 15:08 - LuigiEnricoTomasellitopic end

Start of topic | Skip to actions
-- LuigiEnricoTomaselli - 17 Apr 2007
  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE =

Working Group AC-DF

Membri

IMPORTANTE: PROBLEMA WSDL


Se qualcuno di voi sta facendo delle prove su Golem e non riesce a capire perche' ottiene quest'errore :
Message = SoapFault? exception: [Client] DTD are not supported by SOAP
Ecco svelato il mistero: il modulo SOAP di PHP permette il caching dei file WSDL. In altre parole se state lavorando su un file WSDL con degli errori e avete gia eseguito almeno una volta una chiamata al vostro webservice, il modulo PHP fa il caching del file WSDL utilizzato (la durata standard del tempo in cui viene memorizzato e' di un giorno!). Quindi se ottenete un errore inaspettato che potrebbe derivare dal file WSDL probabilmente e' per questo motivo.
Soluzione (nell'attesa di scoprire qualcosa di piu) : il sistema di cache SOAP su Golem si basa sul nome del file quindi ad ogni modifica del file WSDL cambiategli il nome (e di conseguenza modificare tutti i punti in cui richiamate quel path).

Soluzione problema wsdl

Il messaggio di errore DTD are not supported indica che Soap si trova a dover gestire dei dati che non sono in formato xml _tipicamente un errore (anche di battitura) del webservice che vi risponde.

Aiuta utilizzare le funzioni (Dopo aver creato il SoapClient? con il trace a true)

  • SoapClient?->__getLastRequest()
  • SoapClient?->__getLastResponse()
  • SoapClient?->__getLastRequestHeaders()
  • SoapClient?->__getLastResponseHeaders()
Per scoprire cosa non ha effettivamente funzionato.

Passiamo a livello del caching.

Come mi ha detto Enrico, il caching dei wsdl da parte del SOAP e una direttiva del file php.ini

per risolvere il problema e' possibile usare la direttiva ini_set('soap.wsdl_cache_enabled','0'); per costringere php a non fare il caching del file. ATTENZIONE ini_set cambia la direttiva solamente per lo script corrente (ed ovviamente quelli che include) fino alla fine dell'esecuzione dello script.

per GWAIN, GiacomoMagisano?


ALERT! Grammatiche schema DF ALERT!

Ho creato una pagina contenente informazioni sulle nostre grammatiche; troverete tutte i link della grammatiche attuali (linkate comunque anche nel protocollo) ed eventuali bugfix ed esempi.

Quindi, date il vostro contributo qui! UPDATED ;-)

NOTA BENE: vista l'attuale fase di testing e debugging delle grammatiche tutte le modifiche/aggiornamenti a queste, che saranno fatti prima del rilascio del prossimo protocollo, si potranno trovare esclusivamente nella pagina sopra indicata.

Proposte per l'attributo tipo di contenuto [was contenutoStatico]

E' stato oggi deciso (lunedi 21/05/2007) di dare una settimana di tempo a tutti per proporre estensioni del set di valori ammessi dall'attributo tipo di contenutoStatico.

E' possibile qui proporre nuovi valori secondo voi utili seguendo le seguenti regole:

  1. La proposta deve prevedere la specifica del nuovo valore, il suo significato semantico ed una descrizione della sua utilita'.
  2. Ogni gruppo puo' avanzare piu' proposte diverse, puo' votare piu' proposte diverse ma una singola proposta la puo' votare una volta sola e vota in quanto gruppo e non in quanto singolo studente.
  3. Ci sara' tempo fino alle 24 di lunedi 28 per avanzare proposte in tabella e per iniziare a esprimere le proprie preferenze riguardo alle altre proposte. Scaduti i termini, martedi 29 ci sara' la votazione ufficiale e definitiva in merito.
NOTA BENE: questa tabella sara' modificabile fino alle 24 di lunedi 28 maggio. Scaduti tali termini non verranno considerate ulteriori proposte e martedi 29 si votera' ufficialmente durante la riunione.

<CLOSED>
Proposta numero Gruppo Valore Significato Semantico E' utile perchè Voti
1 LCDP generico Indica di trattare il contenutoStatico come non avente significato semantico (e' il caso di fallback in sostanza) Per poter gestire casi in cui non e' specificabile un significato semantico preciso CaLindro, AAAiuto <B3L/>
2 LCDP intestazione Indica l'intestazione della pagina Per poter indicare l'header/intestazione della pagina CaLindro <B3L/> AAAiuto GWAIN
3 LCDP aiuto Indica un aiuto per l'utente Per poter distinguere chiaramente un messaggio di help per l'utente CaLindro AAAiuto <B3L/> GWAIN
4 LCDP suggerimento Indica un suggerimento per l'utente A differenza di aiuto un suggerimento non prevede una situazione di "problema" ma un semplice suggerimento per l'utente (su cosa fare, come farlo) CaLindro AAAiuto <B3L/> GWAIN
5 LCDP crediti Indica i crediti della pagina Perche' tanto era gia' previsto wink CaLindro <B3L/> GWAIN
6 CaLindro sessione Raggruppa informazioni riguardanti la sessione dell'utente,ad esempio il numero di schede dati visitate, quelle che ha deciso di salvare ecc. Perche' dal momento che dobbiamo gestire una sorta di carrello mi sembra logico poter dare un riassuntino sempre visualizzato di quello che l'utente ha fatto GWAIN
7 CaLindro navigazione Rappresenta una serie di link (o di informazioni generali) che indicano il percorso fatto dall'utente dalla home page fino alla sezione in cui si trova (se qualcuno vuole cambiargli nome per me fa lo stesso) Per questioni di accessibilita' e perche' secondo me un portale complesso non puo' farne a meno AAAiuto (GWAIN 1/2)
8 GWAIN sinossi Compendio (Riassunto) della pagina Tutti i dati che l'application logic ricava dalle pagine ma che non sono direttamente associate ad una scheda ... GWAIN
9 GWAIN meteo Rappresenta le previsioni metereologiche per un dato punto d'interesse Se qualcuno dovesse chiedere i dati meteo di una localita' .... smile GWAIN
10 GWAIN Live Informazioni (diverse da link contestuali di tipo altri link) che sono associate ad una scheda E' piu' generico di meteo ed un po' meno generico di "generico". Potrebbe essere visto come una mutazione di menu' contestuale/statico rappresentabile in maniera meno "standard" v. nota qui sotto.  
11 GWAIN Tagcloud Una tagcloud è un sistema di visualizzare una prospettiva di un sistema dal punto di vista dei dati presenti al suo interno Con il Tagcloud un utente riesce a stabilire quanto è specializzato un data source a colpo d'occhio  
12 CaLindro news Indica modfiche, update, o novita' sul portale Si differenzia da suggerimento perche' non suggerisce nulla, semplicemente notifica delle novita'  
</CLOSED>

Note: Non sappiamo dove aggiungere commenti alle varie proposte senza stravolgere la tabella e quindi li aggiungiamo qui' sotto:

  • suggerimento: Dovrebbe avere un attributo che indichi a cosa si associa un suggerimento, se abbiamo capito bene il suo significato
  • live: dovrebbe avere un attributo che rappresenta l'URI da cui sono stati prelevati i dati
  • tagcloud: Non sappiamo se riusciremo ad utilizzare il tagcloud, ci piacerebbe veramente farlo, però.

Mi Manda il Chair!

Nasce questa nuova rubrica per dare spazio a chi, fulminato sulla via di damasco, pensa di essere in possesso di verita' assolute da declamare a noi tutti :-)

Pensi di possedere la verita' assoulta?, sei in possesso di informazioni segrete?, hai qualcosa di interessante da dire?.....Mi Manda il Chair! e' il posto giusto per te!.

Apre ed inaugura questa rubrica il nostro beniamino RobertoMaggi? del gruppo CaLindro

Le seguenti affermazioni sono di responsabilita' del rispettivo autore, il chair non ne e' responsabile e comunque non rappresentano decisioni del WG et similia.

Intervento numero Gruppo Tematica Commenti
1 CaLindro WORK FLOW GENERALE DELL'ARCHITETTURA
(potrebbe chiarire i dubbi grossi di tutti)
Ultimo Aggiornamento r1.32 - 19 May 2007 - 00:28 - LuigiEnricoTomaselli

Riunioni

UPDATED ALERT! Prossima riunione ALERT! UPDATED

Non vi saranno piu' riunioni in quanto oggi (29/05/2007) e' stato chiuso il lavoro sul protocollo. Aspettiamo conferma da Vitali per la fiera del 5 giugno. Entro domani mattina verra' pubblicata la versione finale e definitivamente congelata del protocollo (la DFV7). Rispetto alla 6 vi saranno delle modifiche soprattutto agli schema della grammatica.

<CLOSED> Inserite nella tabella seguente proposte di discussione per la prossima riunione:

Proposta numero Gruppo Proposta Commenti
1 GWAIN Modifica delle schede funzionali Ultimo Aggiornamento r1.7 - 30 Apr 2007 - 01:43 - GiacomoMagisano
2 GWAIN Schema per menu contestuali Ultimo Aggiornamento r1.3 - 09 May 2007 - 19:33 - GiacomoMagisano
3 CaLindro Schema per menu statici
UPDATED
Ultimo Aggiornamento r1.6 - 28 May 2007 - 20:08 - MaurizioCasimirri
4 CaLindro Schema per contenuto statico Ultimo Aggiornamento r1.5 - 16 May 2007 - 23:42 - RobertoMaggi
5 CaLindro MODIFICATO: Introduzione dell'elemento <contenitore>
UPDATED
Ultimo Aggiornamento r1.11 - 20 May 2007 - 22:49 - GiacomoMagisano
6 CaLindro Revisione grammatiche Ultimo Aggiornamento r1.12 - 19 May 2007 - 23:24 - RobertoMaggi
7 <B3L/> Modifica grammatica del form Ultimo Aggiornamento r1.24 - 22 May 2007 - 20:12 - LuigiEnricoTomaselli
8 CaLindro Schema Form con elementi semantici Ultimo Aggiornamento r1.6 - 20 May 2007 - 19:52 - RobertoMaggi
9 CaLindro Disambiguare l'elemento testo delle form Ultimo Aggiornamento r1.6 - 20 May 2007 - 22:05 - RobertoMaggi
</CLOSED>

Verbale riunione del 29/05/2007

Finalmente oggi e' stata l'ultima riunione del working group wink . Non saranno piu' tenute ulteriori riunioni in quanto oggi si e' chiuso anche l'ultimo punto rimasto in sospeso.

Brevemente ecco i punti oggi discussi:

  1. Riguardo alle proposte per l'attributo tipo di contenuto (inserite nella tabella in cima a questa pagina) e' stato deciso, visto l'esiguo numero di tali proposte, di farle passare tutte. Di conseguenza tale attributo potra' avere uno tra i 12 valori possibili tra quelli presenti in tabella, vi ricordo che tale attributo e' required, quindi se non sapete che valore mettere inserite generico.
  2. Sono state spiegate le decisioni prese in accordo con il DS per il problema "guida completa". In sostanza d'ora in avanti quando vorrete ottenere la formattazione di una guida completa (contenente tutti le informazioni al suo interno, senza riferimenti) dovrete invocare l'apposito metodo sul DS, che vi restituira' la versione completa di una data guida. Tale documento restituito dal ds sara' poi passato in input al DF (nella formatta_documento) in modo da ottenere la visualizzazione della guida nella sua interezza. Tale problema era evidente in un formatter PDF (che non poteva lavorare su guide contenenti riferimenti, ecc..) ma era anche presente in un formatter XHTML (laddove si voglia rendere possibile una anteprima della guida) o in generale laddove si voglia ottenere una visualizzazione completa della guida. Ulteriori informazioni sulle nuove versioni dei protocolli.

Questi credo siano stati i punti affrontati, spero di non dimenticarmi nulla. Per quanto riguarda la fiera vi ricordo che e' prevista per il 5 giugno, ma il prof. Vitali deve ancora darci conferma a riguardo, stay tuned!!

Entro domani mattina pubblico l'ultima versione del protocollo, non vi saranno ulteriori modifiche tuttavia vi consiglio di tenere sempre d'occhio la pagina delle grammatiche per eventuali bug trovati e segnalati (che non saranno comunque corretti, ci appoggiamo al vostro buon senso ed alla vostra attenzione).

Infine, essendo questo l'ultimo verbale della mia stressante e gioisa carriera da chair, vi auguro un buon lavoro.

Verbale riunione del 21/05/2007

Quella di oggi e' stata l'ultima grossa riunione del progetto. Si e' discusso a 360 gradi di tutte le discussioni aperte negli ultimi giorni, cercando una mediazione per ottenere delle soluzioni plausibili.

Riassumo di seguito in ordine sparso quelle che sono state le discussioni affrontate con relative soluzioni:

  • Attualmente la grammaticha degli errori ritornati da un DF prevede una descrizione testuale arricchibile con del markup del testo (strong ecc..); e' stato deciso di rimuovere tale markup e di rendere la descrizione come testo semplice (non avente markup).
  • Attualmente un menuContestuale puo' essere associato ad una scheda, ad un elenco o ai loro sotto elementi mediante l'associazione tra: attributo codice di menuContestuale ed attributo altreInfo assegnabile ad un qualunque elemento di scheda, elenco o loro sotto elementi. Secliendo un codice univoco ed assegnandolo come valore di questi due attributi posso specificare questa associazione. E' stato proposto di affiancare a tale tecnica anche quella dell'xpath. In sostanza sara' possibile specificare nel menuContestuale a quale scheda/elenco/sotto-elementi si faccia riferimento in due modi:
    1. Mediante l'attuale sistema di attributi codice-<altreInfo
    2. Mediante una espressione xpath specificabile in un nuovo attributo di menuContestuale. Tale espressione xpath permette di selezionare in modo piu' flessibile e complesso quelli (e non piu' quello) che sono gli elementi associati a tale menuContestuale. Sara' possibile quindi specificare anche un insieme di nodi ai quali il menuContestuale e' associato.
    Le due opizioni sono esclusive: o si usa la prima o la seconda, caso per caso; tuttavia l'utilizzo di una delle due possibilita' sara' obbligatorio.
  • La famosa discussione sulla necessita' di aggiungere un elemento "contenitore" (per poter raggruppare elementi diversi) si e' chiusa definitivamente. L'unica modifica prevista sara' il cambio di nome da contenutoStatico a contenuto. In sostanza abbiamo convenuto di lasciare l'attuale struttura cosi come e', a parte questo cambio di nome puramente cosmetico ma che non modifica la grammatica o l'utilizzo dell'elemento contenutoStatico (ne introduce nuovi elementi di raggruppamento et similia).
  • Altra famosissima discussione, collegata alla precedente, era legata alla distinguibilita' semantica degli elementi funzionali di una pagina (menu, contenuti, schede ecc..). Era sorta (tanto tempo fa) la necessita' di estendere i valori dell'attributo tipo di contenutoStatico; tale estensione si rendeva necessaria per una corretta identificazione da parte del DF del significato semantico di determinate sezioni della pagina, in modo da fornire una formattazione piu' specifica. Siamo convenuti alla fine su quanto segue:
    1. I valori dell'attributo tipo dell'elemento contenutoStatico saranno estesi mediante proposta piu' votazione. La loro estensione non sara' illimitata ma avra' una scadenza entro la quale avanzare proposte di estensione. Una volta terminati i tempi per le proposte queste saranno votate ufficialmente in riunione onde decidere quali estensioni accettare e quali scartare.
    2. Di tutte le estesioni accettate (votate a maggioranza) circa 4 saranno considerate obbligatorie (ovvero rappresenteranno un insieme obbligatorio di valori da dover riconoscere e supportare nel DF); tutte le altre estensioni saranno opzionali e facoltative (ovvero potranno essere supportate oppure no) ma sara' vietato aggiungerne delle nuove.
    3. Potete usare la seguente tabella del wiki per proporre le vostre estensioni ad i valori dell'attributo tipo. La proposta deve specificare il valore, il significato semantico ed una descrizione specifica del perche' usarlo e perche' puo' essere utile.
    4. Ogni gruppo puo' avanzare piu' proposte diverse, puo' votare piu' proposte diverse ma una singola proposta la puo' votare una volta sola e vota in quanto gruppo e non in quanto singolo studente.
    5. Ci sara' tempo fino alle 24 di lunedi 28 per avanzare proposte in tabella e per iniziare a esprimere le proprie preferenze riguardo alle altre proposte. Scaduti i termini, martedi 29 ci sara' la votazione ufficiale e definitiva in merito.

  • Le grammatiche schema e relativi esempi xml presenti nel protocollo sono vecchi e non aggiornati. Inseriro' la nuova versione del protocollo il prima possibile, appena terminata la scrittura delle grammatiche ed apportate le dovute modifiche.
  • E' stata decisa la rimozione dell'elemento button. Tale elemento non era ancora presente nel protocollo ufficiale ma era in via di inserimento. Siccome l'utilizzo dell'elemento button (cosi come previsto dalla nostra grammatica ufficiosa) non avrebbe avuto senso se non in presenza di javascript, siccome durante la creazione delle schede funzionali (e quindi di tale elemento) non potremmo essere sicuri del corretto funzionamento di javascript lato client, per tanti altri buoni motivi e' stato deciso di rimuovere tale elemento.
  • E' stata decisa l'aggiunta di un nuovo elemento dal nome azione. Tale elemento avra' un content-model molto simile a quello di un link. Il suo scopo sara' quello di distinguere un link di navigazione da un link utile ad eseguire una azione. E' una necessita' nata a livello di DF, in modo tale che il DF stesso possa distinguere le due situazioni e attuare delle formattazioni piu' specifiche. Questo elemento sara' disponibile sia in contenutoStatico che all'interno di una form.
  • E' stato notato come l'elemento testo all'interno di una form sia piuttosto ambiguo (riguardo al suo utilizzo). A tal proposito e' prevista una sua disambiguazione nel nuovo protocollo, stay tuned.
  • In seguito alla segnalazione sui problemi dell'attributo for di una label (utile a specificare a quale elemento di input fosse associata tale label) e' stato deciso di eliminare l'elemento label e di trasformarlo in un attributo associato ad un qualunque elemento di input o textarea. Tale attributo label sara' una semplice stringa ed avra' comunque il significato di label (etichetta).

Come vedete sono stati chiariti un nutrito insieme di punti; tutte le decisioni prese oggi saranno riflesse in forma di modifiche/aggiunte nel nuovo protocollo che spero di pubblicare il prima possibile. L'attuale protocollo e' abbastanza vecchio (alla luce del fervore propositivo degli ultimi giorni smile ) quindi non vi ci basate troppo pesantemente. Appena pronte le grammatiche pubblichero' la nuova versione che sara' quella definitiva e congelata. Restera' aperta solo la questione "valori dell'attributo tipo" che verra' congelata entro lunedi 28 (come specificato).

Buon lavoro

Luigi

Verbale riunione del 17/05/2007

Contrariamente a quanto sperassi e pensassi oggi non si e' riusciti a chiudere/congelare il protocollo. Causa di cio' e' stata una proposta/problematica sorta ed avanzata riguardo la gestione delle schede funzionali. Qui di seguito cerchero' di riassumervi i punti salienti della riunione per quanto possibile, partendo dal piu' importante.

  • E' stato fatto notare dai rappresentanti del gruppo CaLindro e GWAIN come l'attuale protocollo preveda un meccanismo troppo povero per la gestione delle schede funzionali. In particolare il problema si pone riguardo alla gestione dell'elemento contenutoStatico in relazione al suo attributo tipo . Tale attributo serve a specificare un particolare significato "semantico" di cio' che e' racchiuso in un determinato contenutoStatico.

    Attualmente i valori previsti sono intestazione e crediti e specificano che tale contenutoStatico rappresenti ad esempio l'intestazione della pagina o i relativi crediti.

    L'utilita' di questo attributo risiede nella possibilita' per il DF di comportarsi adeguatamente nella formattazione di un certo contenutoStatico, avendo cioe' una conoscenza maggiore sul significato "semantico" di quel particolare elemento/contenitore.

    La necessita' primaria sarebbe quindi quella di definire un insieme di valori piu' ampio per poter riconoscere ed identificare ulteriori casi utili; ad esempio l'aggiunta del valore aiuto utile ad identificare un contenutoStatico riservato all'help della pagina.

    Una necessita' meno banale sarebbe quella di aggiungere/avere un elemento "contenitore" che permetta di raggruppare in modo logico/semantico determinati elementi che, per qualche motivo, hanno bisogno di essere visivamente raggruppati.

    L'idea sarebbe quella di definire un elemento dal nome gruppo (o qualcosa di simile) che permetta di raggruppare un insieme di elementi eterogenei; tale elemento deve poter contenere qualunque altro elemento della grammatica (schede funzionali, schede del DS ecc..). Tale elemento gruppo avrebbe inoltre un attributo tipo con lo stesso ruolo del medesimo attributo presente in contenutoStatico; l'aggiunta sarebbe quella di lasciare liberi i vari gruppi/DF di specificare un insieme di valori aggiuntivi gestiti e personalizzati dal proprio DF. L'elenco di valori aggiuntivi definiti da ogni DF dovrebbe, per buon senso, confluire in una tabella sul wiki dove specificare il valore gestito ed il suo significato. Il buon senso di ognuno di noi starebbe nel verificare la presenza di un valore di interesse in questa tabella onde evitare di gestire la stessa cosa ma ognuno con nomi diversi.

    Ogni DF dovrebbe nel suo catalogo specificare l'insieme di valori gestiti per l'attributo tipo dell'elemento gruppo.

    E' evidente che la modifica piu' banale sarebbe estendere ufficialmente l'insieme dei valori specificabili nell'attributo tipo di contenutoStatico. La seconda modifica e' invece piu' complessa e, viste alcune sovrapposizioni che si verificano tra il nuovo elemento gruppo e l'attuale contenutoStatico, richiederebbe una attenta valutazione e progettazione della modifica da fare.

    E' altresi' evidente la limitazione dell'attuale protocollo (o meglio dell'attuale progetto), limitazione dovuta al quanto mai fastidioso requisito di interoperabilita' richiesto. L'idea sarebbe quella di limare un po' queste limitazioni, capendo per bene fin dove e' ragionevole spingerci onde evitare di tirarci la zappa sui piedi.

    Oggi, dopo averne a lungo discusso, si e' stabilito che:

    1. Entro sabato mattina devono pervenire sul wiki (usate pure la tabella "proposte") tutte le proposte di modifica su questo argomento; le proposte devono essere corredate di grammatica schema piu' descrizione dettagliata delle modifiche da fare. Se non avete proposte ma anzi siete contrari a tale modifica fatevi comunque sentire sul wiki!!
    2. Lunedi mattina decideremo durante la riunione quale soluzione adottare.
    3. Lunedi alle 12 il protocollo sara' necessariamente congelato

    Mi rendo conto che, per chi non era presenta alla riunione odierna, quanto scritto fin qui non permette di farsi un'idea completa; spero almeno che sia corretta e che rispecchi le proposte avanzate dai gruppi GWAIN e CaLindro .

  • E' stato deciso che l'elemento button verra' inserito sia in contenutoStatico che nella form. Tale elemento non avra' pero' il content-model previsto in xhtml, ma soltanto gli attributi.
  • IMPORTANTE: In merito alla problematica sull'invio dei pdf ed i relativi problemi di codifica con SOAP accennati nel precedente verbale e' stato deciso che:
    1. sia l'AC che il DF DEVONO codificare le stringhe (mioDocumento nel caso AC->DF oppure la stringa di output nel caso DF->AC) ,inviate tramite soap, con le funzioni rawurlencode (php) o encodeURIComponent (javascript) .
    2. la codifica deve essere fatta SEMPRE ed in ogni caso, cosi anche la decodifica
    3. la codifica deve essere fatta su ogni parametro di input o output il cui tipo e' stringa
  • Contrariamente a quanto gia' deciso e' stato segnalata la necessita' di riaggiungerei parametri idSkin ed idLayout nel metodo formattaFrammento. Questa necessita' si presenta quando formatto un frammento e devo sapere in quale dei miei layout supportati tale frammento sara' poi inserito. Questi parametri nel caso della formattaFrammento serviranno come reminder al DF per formattare adeguatamente. Probabilmente verra' riaggiunto solo il parametro idLayout visto che tanto la skin non puo' essere rispecificata ma si usa quella specificata durante la formattazione del documento di cui fa parte il frammento.
  • Relativamente alla problematica posta nel precedente verbale a riguardo del parametro urlAC e' stato deciso che tale parametro sara' una stringa contenente un semplice albero xml. In tale albero si inseriranno tutte le informazioni su ajax: la funzione di inizializzazione e l'elenco degli script da includere (da includere nell'esatto ordine in cui si presentano nell'albero, da sopra verso sotto).

Come vedete ci sta ancora un po' di carne al fuoco, ma comunque vada lunedi 21 si chiude baracca e burattini cosi iniziamo ad implementare seriamente. Per domani inseriro' una nuova versione del protocollo con le nuove modifiche, in attesa di quella finale di lunedi.

Pace.

Verbale riunione del 14/05/2007

Nella odierna riunione si sono prese le ultime decisioni sulle schede funzionali (in particolare quella dell'editor) e si e' fatto il punto della situazione in vista del congelamento del protocollo.

In breve le ultime decisioni prese sono le seguenti:

  • E' stato deciso di aggiungere un valore all'attributo tipo dell'elemento query . Questo nuovo valore sara' inserisciCommento e servira' per specificare il caso particolare di una query utile ad aggiungere un commento ad una scheda; in questo modo il DF potra' comportarsi in modo opportuno.
  • E' stato deciso di aggiungere l'elemento button sia a contenutoStatico che all'elemento form . Tale elemento sara' l'equivalente XHTML e permettera' di creare schede funzionali piu' flessibili; saranno ovviamente rimossi tutti gli attributi prettamente presentazionali.
  • Riguardo al problema di come gestire gli attributi presentazionali (strong, em ecc..) presenti nel testo delle schede (guide/itinerari/pdi) nello specifico caso di visualizzazione in un editor e' stato deciso che ognuno trovera' un suo metodo per gestire questa possibilita'. In sostanza ognuno scegliera' il metodo piu' opportuno per permettere all'utente di aggiungere queste caratteristiche al testo in base a quanto gia' permesso dal DS.

Queste invece sono delle considerazioni che ho maturato personalmente dopo la riunione e che saranno inserite come modifiche nel nuovo protocollo:

  • Sono riuscito a risolvere il problema dell'invio di un pdf sotto forma di stringa tramite il metodo del wsdl gia' previsto. Purtroppo data la presenza di caratteri molto particolari nel pdf binario sono stato costretto ad usare la rawurlencode per codificare la stringa risultante dal pdf. In sostanza prima di spedire il risultato bisogna codificarlo in modo che SOAP non si incazzi di brutto; lato client bisognera' decodificarlo con la rispettiva rawurldecode per poter ottenere il pdf originario. Lato client/javascript si deve usare la funzione decodeURIComponent per decodificare correttamente il messagio. Sara' obbligatorio fare la codifica del messagio di ritorno sempre e comunque anche nel caso di xhtml normale in modo da non dover gestire casi particolari. Purtroppo a quanto ho capito anche SOAP (come tutti gli altri protocolli del resto) soffre di problemi sulle stringhe contenenti caratteri speciali (come il caso particolare del pdf), quindi mi sembra non ci siano alternative. Se ne trovate molto meglio, altrimenti si fara' cosi. Ho implementato un client ed un webservice che dimostrano la spedizione del pdf via webservice, ho usato un altro wsdl solo per non toccare i vecchi esempi, la definizione di questo e' pero' identica a quelli vecchi.

    • Il client-php e' qui .
    • Il webservice e' qui.
    • Il wsdl e' qui
    • L'archivio dell'esempio e' qui

  • Sono stato informato di un casino presentatosi l'anno scorso su ajax. La decisione di passare una sola URL di javascript (ad esempio quella dell'AC javascript) al DF e' sbagliata. Il problema e' che, cosi facendo, sarebbe l'AC javascript a dover includere dentro di se tutte le ulteriori librerie javascript che gli servono, cosa che a quanto mi hanno detto e' un casino da evitare volentieri. L'inclusione di script javascript e' una rogna, ad esempio bisogna fare attenzione estrema all'ordine con il quale si includono le librerie ecc.. Per tagliare la testa al toro al posto dell'attuale parametro urlAc che e' una URI mettero' un parametro stringa elencoJS. In questo parametro sara' passato un banale albero XML contenente tanti elementi quanti sono gli script da dover includere; questi saranno inclusi nell'esatto ordine in cui sono inseriti nell'albero xml. L'alternativa sarebbe usare un complex type nel WSDL al posto della stringa in modo da definire una struttura apposita per fare questo, oppure usare una array di stringhe. Per esperienza conosco vari casini che si presentano nell'usare complex type nel WSDL, gli eviterei volentieri.
  • L'attuale WSDL non e' valido, ovvero funziona e va bene....ma non rispetta in pieno le definizioni del W3C (qualcuno ha detto soapAction ?? big grin ). Provvedero' a renderlo corretto, se trovate altri errori fatemi sapere.
  • Contrariamente a quanto vi dicevo l'ultima volta nel caso di AC javascript si formatta praticamente sempe e solo di frammenti; ovvero si chiama sempre e solo il metodo formattaFrammento . In sostanza la formattaDocumento la invochera' al massimo l'AC php la prima volta, appena entra in giocio l'AC javascript si andra' avanti di frammenti (si, anche per quei frammenti che non ci sono ancora nella pagina, o meglio che non sono ancora visibili! wink ). Nel caso speciale in cui bisogni cambiare layout verra' richiamato in vita l'AC php ed il giro della giostra ripartira' dall'inizio. Sono stato illuminato in tal senso, quindi giovedi illuminero' anche voi smile

Per ora e' tutto, cerco di fare i miracoli e mettere su la nuova versione quanto prima, specie gli schema nuovi. Giovedi parleremo di eventuali ultime proposte/modifiche ad errori/meta prescelta per la vacanza estiva big grin

Ad maiora.

Luigi

Verbale riunione del 09/05/2007

Verbale molto breve quello di oggi. In sostanza abbiamo affrontato e chiuso (almeno per ora) il discorso sulle schede funzionali. Dopo le discussioni di oggi sono state prese queste decisioni:

  1. La grammatica per l'editor sara' unica.
  2. La grammatica prevedera' un elemento unico "editor" avente l'attributo "tipo"; i valori di tale attributo potranno essere "PdI, Itinerario o Guida" per indicare il tipo di editor che l'AC/AL invia al DF da formattare.

  3. L'elemento "editor" conterra' l'elemento "form". L'elemento form conterra' tutti i gli elementi previsti per una form html con alcune modifiche.
  4. Aggiungeremo un elemento alla "form" per permettere il raggruppamento logico/visivo di alcuni campi della form (campi che continueranno comunque a fare parte di "quella form specifica").

Il grosso del discorso e' stato chiuso per ora. siamo in attesa che il DS pubblichi le sue grammatiche e/o comunque una versione aggiornata del protocollo per capire come sono composte le loro schede ed elenchi. Domani mi vedro' con alcuni di voi per scrivere le grammatiche in xml-schema in modo da pubblicare la nuova versione del protocollo. Per oggi e' tutto, pace.

Verbale riunione del 07/05/2007

Nel corso della riunione sono stati affrontati i seguenti argomenti:

  1. Work-flow dell'architettura
  2. Definizione delle schede funzionali

Nel dettaglio:

  1. Work-flow dell'architettura
  2. Durante la riunione con il prof. Vitali e' emersa una precisazione sul work-flow comunicativo nel progetto. Mi ha spiegato Vitali che e' possibile e previsto che l'application logic possa, una volta ricevuti dei dati da arricchire con ulteriori informazioni, reinterrogare di sua spontanea volonta' il DS; ovviamente passando tramite l'AC. Prima si pensava che i dati arrivati all'AL fossero da arricchire solo mediante l'ontologia e da spedire verso il DF; a quanto pare invece l'AL puo' recuperare ulteriori dati oltre che dall'ontologia anche dal DS.

  3. Definizione delle schede funzionali
  4. E' stato l'argomento che ha portato via quasi tutto il tempo della riunione. Il comptio che dobbiamo risolvere il prima possibile e' definire le grammatiche per le schede funzionali. Fortunatamente potremo riciclare molte grammatiche gia' definite l'anno passato in quanto abbastanza simili ed utili a quelle di quest'anno. Una scheda funzionale che dovremo invece definire da zero sara' l'editor di schede provenienti dal DS, ed e' proprio su questo che abbiamo speso molte delle discussioni.

    In sintesi cio' che e' emerso dalla riunione e' che:

    • Definizione di cosa significa modificare una scheda
    • Si e' chiarito che, essendo le schede provenienti dal DS fondamentalmente di 3 tipi (Guida, Itinerario, PdI?), allora abbiamo 3 livelli di modifica e, conseguentemente, 3 tipologie di editor. In sostanza a seconda della scheda che stiamo modificando si devono applicare ragionamenti differenti. Tenendo a mente la gerachia di inclusione Guida->Itinerario->PdI vediamoli nel dettaglio in stile bottom-up:

      • Modifica di una scheda PdI?
      • Modificare una scheda PdI? significa esclusivamente modificarne il contenuto. In questo caso quindi l'editor deve fornire la possibilita' di modificare il contenuto di ogni elemento della scheda (Descrizione, mappa ecc...) mediante delle form apposite. Nostro compito sara' definire la grammatica che stabilisce gli elementi/widget utilizzabili per la composizione di un editor di PdI? mediante il classico ragionamento "a mattoncini".

      • Modifica di una scheda Itinerario
      • Modificare una scheda Itinerario significa poter:

        1. Modificare il contenuto di "descrizione", "nome" dell'itinerario
        2. Modificare l'ordine dei PdI? (Berlino prima di Parigi ecc...)
        3. Aggiungere uno o piu' PdI?
        4. Rimuovere uno o piu' PdI?
        Per poter fare queste operazioni bisognera' definire un insieme di elementi/widget piu' esteso rispetto a quello per l'editor PdI?. In particolare ci sara' bisogno di un elemento "choice" che permetta di fornire scelte realizzabili mediante "checkbox, radio button, menu a tendina". L'idea e' di rimanere astratti su questo elemento permettendo al DF di scegliere il tipo di interazione piu' adatta se non meglio specificato dall'AC.

      • Modifica di una scheda Guida
      • Modificare una scheda Guida significa poter:

        1. Modificare il contenuto di tutti i meta-dati della guida
        2. Modificare l'ordine degli Itinerari
        3. Aggiungere uno o piu' Itinerari
        4. Rimuovere uno o piu' Itinerari
        Per poter fare queste operazioni bisognera' definire un insieme di elementi/widget simile a quello usato per l'editor di Itinerari. In particolare ci sara' bisogno di un elemento "choice" che permetta di fornire scelte realizzabili mediante "checkbox, radio button, menu a tendina". L'idea e' di rimanere astratti su questo elemento permettendo al DF di scegliere il tipo di interazione piu' adatta se non meglio specificato dall'AC.

    • Altre particolarita' sull'editor
      • La definizione di editor segue fedelmente la struttura gerachica che definisce una Guida come insimeme di Itinerari a loro volta insieme di PdI?. Abbiamo quindi 3 tipologie di editor specifiche per ognuno dei 3 casi. La divisione logica in 3 tipologie di editor si e' resa necessaria per meglio capire come risolvere il non banale problema dell'editing. A livello di grammatica bisogna ancora decidere se ci sara' questa distinzione; questo potrebbe risultare in 3 grammatiche diverse per i 3 editor oppure in una unica grammatica/scheda funzionale avente un attributo "tipo" utile a distinguere tra i 3 casi.
      • L'editor per la creazione di nuove schede "Guida, Itinerario o PdI?" saranno identici a quelli gia' descritti, semplicemente non forniranno contenuto da modificare ma saranno "vuoti".
      • E' stato inoltre chiarito che sara' l'AC/AL, durante la creazione dell'editor da far formattare al DF, ad inserire i contenuti da modificare come valore degli elementi dell'editor. Al DF in questo caso quindi non arrivera' l'albero xml della scheda, arrivera' invece la definizione dell'editor contenente al suo interno tutti i contenuti della scheda da modificare.

CONCLUSIONI VERBALE

Il grosso argomento da chiudere il prima possibile resta quello delle schede funzionali. Vi ricordo che per il 15/17 maggio e' previsto il congelamento del protocollo, quindi dobbiamo aver chiuso e risolto i vari problemi entro quella data (una settimana o poco piu' da ora!). Grazie all'aiuto di alcuni di voi (Giacomo Magisano, ThinleyKoblensky?) stiamo facendo le prime grammatiche in schema. Perche' schema e non relax-ng?, perche' ieri al DS hanno deciso all'unanimita' (corrotta ed ipocrita big grin ) di usare schema; di conseguenza onde evitare di prendere due strade diverse (con tutti i problemi di doppio lavoro per chi andra' ad implementare e lavorare sul progetto) ho scelto di uniformarci al DS (li mortacci loro!! big grin ). Comunque dopo la riunione di domani prevedo di tirare fuori la nuova versione del protocollo che, come di consuetudine, sara' direttamente la versione 0.9.5 big grin . Per domani quindi il piano d'attacco sara':

  1. Definizione della scheda funzionale editor (in tutte le sue salse)
  2. Definizione e discussione (per la serie vi vanno bene si o no) sulle altre schede funzioali
Spero di essermi ricordato tutto, in caso contrario segnalatemelo! wink

NOTA BENE: vista l'imminente scadenza che ci aspetta questa settimana sara' di fuoco, preparatevi a morire e tenetevi liberi da impegni. smile Rock 'n roool!.

Firmato: Luigi, un char in evidente stato confusionale.

Verbale riunione del 03/05/2007

Nel corso della riunione sono stati affrontati i seguenti argomenti:

  1. Codifica caratteri in UTF-8
  2. Decisione su XML-SCHEMA o RELAXNG
  3. Problema scheda funzionale per l'editor delle guide
  4. Riassunto e spiegazione su come funzionera' l'architettura AJAX

Nel dettaglio:

  1. Codifica caratteri in UTF-8
  2. Si e' discusso sulla problematica della codifica dei caratteri. E' necessario che ogni gruppo utilizzi la codifica UTF-8 (anziche' ad esempio iso-latin-1) nei seguenti punti fondamentali:

    • Documenti XML generati (in particolar modo quando salvate tali file sul filesystem o dal vostro editor di testo)
    • Form di input testo (bisogna che ogni form di input testo codifichi il suo testo in UTF-8, l'utente non si accorge di nulla ma a noi evita molti problemi)

    Bisogna seguire questa convenzione per evitare che, nello scambio di dati tra DF e DS di altri gruppi, ci siano problemi di codifica dei caratteri. Ad esempio: La scheda PdI? di Parigi del tuo DS contiene dei caratteri che il mio DF non riesce a leggere correttamente. Per l'appunto questo esempio non dovra' verificarsi (pena punizione corporale smile )

  3. Decisione su XML-SCHEMA o RELAXNG
  4. Dopo la discussione su pro e contro di entrambe le scelte e' stato deciso quasi all'unanimita' di usare relaxng per la definizione delle nostre grammatiche. Resta chiaro che questa scelta dipende fortemente dalla scelta adottata dal DS (il quale attualmente propende parzialmente per schema). In sostanza aspettiamo conferma da parte loro (il prima possibile) e in base alla loro scelta cerchiamo di adeguarci (non avrebbe senso prendere due strade diverse, i vantaggi derivanti dall'adozione di relaxng sarebbero vanificati dal dover gestire due definizioni di grammatiche diverse). NOTA BENE: a seguito della mia richiesta lunedi 07/05/2007 il prof. Vitali affrontera' a lezione l'argomento RELAXNG e SCHEMATRON. Vi consiglio di venire per chiarirvi (si spera smile ) le idee su questi argomenti.

  5. Problema scheda funzionale per l'editor delle guide
  6. Inizialmente si pensava che fosse possibile demandare totalmente al DF la decisione sul "come" visualizzare l'editor per le guide (ovvero l'editor che permette di modificare/aggiungere la scheda di un PdI?/Itinerario/Guida). Questa idea risulta purtroppo sbagliata e non adatta. In sostanza anche per l'editor sara' necessario specificare delle schede funzionali (cosi come gia' avviene per i menu, le form di query ecc..) che tutti dovremo usare per la creazione del nostro editor. Questa decisione e' legata a delle problematiche che altrimenti si presenterebbero; esaminiamo i due casi di interesse:

    In PHP: in php esiste un grosso limite. Tale limite prevede che per realizzare l'editor delle guide dovremo usare tutti quanti delle input form. Questo e' attualmente l'unico modo per gestire la modifica di una scheda (tanti campi di testo per la modifica del contenuto di una scheda ed un bel pulsantone SUBMIT per confermare la modifica della scheda; potenzialmente anche altri widgets per altre cose che decideremo). Questo limite non e' deciso da me ma e' un chiaro limite di php+xhtml, semplicemente non c'e' altro modo per ricevere input da parte dell'utente (a parte eventuali modi palesemente porchettari et similia).

    In AJAX: in ajax si presenta un grosso problema. Se demandassimo tutto il lavoro al DF questo potrebbe partire per la tangente e, anzi che usare un approccio ad "input form", utilizzare altri approcci javascript piu' o meno complessi e fighi. In particolare potrebbe prevedere una gestione dell'input da parte dell'utente totalmente diversa da quella che si aspetta l'AC. Ricordiamoci che l'input dell'utente (ovvero le sue modifiche/aggiunte) dovra' passare per l'AC al momento della richiesta di salvataggio delle modifiche. Diventa evidente quindi che AC e DF devono collaborare e decidere di comune accordo un modo per gestire l'interazione dell'utente con l'editor e per gestire l'invio delle sue modifiche all'AC a seguito della SUBMIT (se io AC devo interpretare e prelevare il contenuto modificato dall'utente allora devo sapere dove andarlo a cercare e come!). Resta possibile associare layout e skin particolari all'editor di guide ma sara' obbligatorio definire una scheda funzionale apposita; tale scheda funzionale definira' tanti "mattoncini" utili all'AC per creare il suo editor particolare. In sintesi, se avete capito il problema delle schede funzionali (perche' esistono, a cosa servono) allora avete gia' capito anche questo problema e la sua soluzione smile (se leggendo "schede funzionali" siete stati vittime di attacchi di panico allora e' meglio che vi studiate il protocollo e i vari verbali precedenti wink ).

  7. Riassunto e spiegazione su come funzionera' l'architettura AJAX
  8. Giusto per comodita' e sicurezza oggi e' stato riaffrontato il capitolone "AJAX". In particolare abbiamo ridiscusso alcuni punti fondamentali che permetteranno l'implementazione dell'architettura AJAX e la sua interoperabilita'.

    Questi sono i punti (ed i vostri comandamenti! wink ) :

    1. L'architettura AJAX vive sulle spalle di quella PHP.
    2. La prima formattazione della prima pagina del portale (tipicamente la home) verra' generata dal DF il quale inserira' in tutti gli attributi "href" di ogni link ed in tutti i campi "action" di ogni form una URL (specificata dall'AC) che punta all'architettura php. (eg:

       <a href="/ac.php5?pagina=pippo">link a pagina pippo </a>
      
      ) Il DF inserira' inoltre nel campo "onload" del tag "body" il nome di una funzione javascript che serve ad inizializzare l'architettura AJAX. Inserira' inoltre nell'head del documento xhtml un riferimento allo script javascript che implementa l'AC-ajax. L'url relativa all'AC-ajax e il nome della funzione che inizializza il tutto saranno passati come parametri (facoltativi) ad ogni invocazione di formattaDocumento fatta sul DF.

    3. L'architettura AJAX si attiva quando lo dice il browser, non quando lo dico io
    4. L'unico modo sicuro ed affidabile per sapere quando attivare l'architettura AJAX e' quello di lasciare la decisione al browser. In particolare il browser quando avra' finito di caricare la pagina analizzera' (questo e' garantito che lo faccia gia' di suo) il contenuto dell'attributo "onload" del tag "body". Si presentano due casi:

      1. Il browser supporta ed ha abilitato javascript
      2. In questo caso il browser invochera' l'esecuzione della funzione specificata nell'attributo "onload". Il compito principale di questa funzione sara' quello di modificare ogni attributo "href" di ogni link ed ogni attributo "action" di ogni form in modo da togliere l'url che punta allo script php ed inserire una chiamata ad una funzione javascript opportuna. Ad esempio:

        PRIMA

        <a href="/ac.php5?pagina=pippo">link a pagina pippo </a>
        

        DOPO

        <a href="javascript:miaFunzioneRichiestaPagina(pippo)">link a pagina pippo </a>
        

        In sostanza questa funzione ha il compito di inizializzare l'architettura AJAX in tutti i suoi aspetti. Quelli appena visti sono i principali.

      3. Il browser non supporta oppure non ha abilitato javascript
      4. In questo caso sempicemente ignorera' (in quanto non capace di eseguirla) la funzione specificata nell'attributo "onolad". Tutto continua a funzionare correttamente (ovvero l'architettura php) perche' i link puntano, di default, all'AC-php.

    Compiti per la prossima riunione:

    • Avanzare proposte sulle schede funzionali che dovremo definire. Prendere spunto e studiarsi le schede funzionali definite nel progetto dell'anno scorso qui
    • Avanzare proposte sui "mattoncini" necessari nella definizione della scheda funzionale per l'editor di guide
    • Studiarsi l'accoppiata relaxng+schematron
    • Trovare delle librerie fatte come si deve per accedere ai webservice da javascript (requisito: devono funzionare con il webservice di esempio che ho fornito sulla mia home page)
    • Iniziare pesantemente a fare test e prove implementative per php e javascript in generale. In particolare in accoppiata con i webservice. Lavorate, lavorate, LAVORATE smile

Verbale riunione del 30/04/2007

Nel corso della riunione sono stati affrontati i seguenti argomenti:

  1. Proposta sulla modificabilita' delle schede funzionali
  2. Inserimento di nuove schede dati nel DS e modifica di quelle esistenti

Vista la corposita' del punto numero 2 non e' stato possibile affrontare altri argomenti tra quelli proposti o rimasti aperti.

Nel dettaglio:

  1. Proposta sulla modificabilita' delle schede funzionali
  2. E' stata ridiscussa la proposta di rendere modificabili le schede funzionali. Per chi non sapesse di cosa tratta la proposta puo' consultare questo link Modifica delle schede funzionali dove trovera' la proposta con commenti aggiunti. In seguito alla discussione odierna sono rimaste fisse le due "posizioni" che si erano gia' delineate. L'autore della proposta GiacomoMagisano e' (ovviamente smile ) a favore della modificabilita' delle schede funzionali. Il sottoscritto (chair smile ) e' invece contrario. Le motivazioni di entrambi le trovate espresse nel link prima segnalato. Si e' deciso in generale di rimandare la decisione su questa proposta al momento in cui ci occuperemo di creare la grammatica delle schede funzionali, nel frattempo vi chiedo cortesemente di documentarvi a riguardo e di formulare una vostra opinione chiara in modo da capire meglio anche quanti sono pro o contro tale proposta.

  3. Inserimento di nuove schede dati nel DS e modifica di quelle esistenti
  4. L'intervento odierno del chair-DS AlessandroCaponi ha aperto il dibattito su tale argomento. Il problema fondamentale riguarda il come gestire:

    • Inserimento/creazione di una nuova scheda (Guida, Itinerario, Punto di interesse)
    • Modifica di una scheda esistente
    • Permessi annessi e connessi

    Innanzitutto e' stato corretto un punto fondamentale in riferimento alla sezione "4.3.1" del protocollo totale. Facendo riferimento alla sezione "4.3" il protocollo attuale prevede che esistano 4 tipi di schede all'interno del protocollo. In particolare l'elemento "Scheda" ha come content-model il seguente: (info,pagina | PdI? | itinerario | guida).

    Tralasciando l'elemento "info" quello che tale CM definisce e' che una "Scheda" possa essere:

    • Scheda funzionale (elemento "pagina")
    • Scheda punto di interesse (elemento "PdI"
    • Scheda di Itinerario (elemento "itinerario")
    • Scheda di una guida (elemento "guida"

    Quello che e' stato appurato oggi e' che una scheda NON debba/possa essere una scheda funzionale . In sostanza il succo e': le schede funzionali sono affari del DF e vengono definite dal nostro working-group. La loro grammatica non ha nulla a che vedere con quella relativa alle schede proprie del DS. (NOTA BENE 1: vi ricordo che non e' necessario ne previsto che una scheda funzionale risieda nel DS. Le schede funzionali sono vostre e private, quindi vanno memorizzate a parte dove piu' vi fa comodo o addirittura si possono generare al volo nel codice ma NON possono essere accedute da parte di altri AC all'infuori del vostro. NOTA BENE 2: vi ricordo inolte che una scheda funzionale sara' "costruita" a partire da mattoncini che definiremo insieme nel working group. Menu, form , widget vari ed eventuali avranno una grammatica specifica che definiremo noi; a partire da questi "mattoncini" potrete creare le vostre schede funzionali. )

    In definitiva la modifica futura sara' rimuovere ogni concetto di "scheda funzionale" dalle sezioni del protocollo di competenza del DS (Da 4.3 in poi soprattutto).

    In base a questa futura modifica si e' pensato a come risolvere un altro problema: come fa' un utente ad inserire paragrafi aggiuntivi nella sua guida?

    In sostanza una guida sara' una collezione di itinerari e, a loro volta, di punti di interesse. E' gia' prevista la possibilita' di aggiungere descrizioni/commenti/informazioni strettamente collegate ad un Itinerario o un PdI?. Non e' ancora prevista in modo chiaro la possibilita' di aggiungere pagine libere (tipicamente paragrafi personali) alla guida stessa. Spero sia evidente l'importanza e l'utilita' della cosa; i tag "descrizione" associati ad un itinerario o un PdI? sono sicuramente ottimi per gestire commenti/informazioni/descrizioni ma non sono abbastanza flessibili per diventare pagine libere di una guida. Con libere intendo potenzialmente scollegate da un preciso PdI? o itinerario.

    Ad esempio vorrei poter scrivere un paragrafo di introduzione, o in generale paragrafi scritti da me e non necessariamente/strettamente associati ad un itinerario o un PdI?.

    Il come risolvere questo problema non e' banale e non e' competenza esclusiva del DS; le loro scelte si rifletteranno pesantemente sul come noi DF permettiamo all'utente di inserire nuovi paragrafi. Per questo motivo mi sto organizzando con l'altro chair (Alessandro) per affrontare la questione con una task-force congiunta smile , stay tuned.

    AGGIUNTA/MODIFICA DI UNA SCHEDA (Guida, Itinerario, PdI?) E PROBLEMI DI PERMESSI

    Una lunga discussione e' stata fatta su come gestire i vari permessi di modifica di una scheda. In particolare si e' discusso sulla semantica dell'operazione "modifico la scheda del punto di interesse Parigi".

    In breve quello che si e' deciso per ora e' quanto segue:

    • Se io modifico la scheda PdI? di Parigi la mia modifica comportera' la creazione di una copia della scheda contenente le modifiche fatte (In puro stile Wiki). Questa semantica e' associata alla modifica di qualunque tipo di scheda (Guida, Itinerario, PdI?).
    • Se io creo la mia guida su Parigi e decido di sfruttare le informazioni presenti nella scheda PdI? di Parigi allora viene effettuata una copia della scheda PdI? che viene inserita nella propria guida. Da questo momento in poi la scheda PdI? originaria avra' vita propria e scollegata dalla scheda PdI? che io ho incluso nella mia guida (o nel mio itinerario). In sostanza: modifiche alla risorsa originaria non si ripercuotono (ammesso che sia possibile) sulla copia della risorsa inclusa nella propria guida (o nel proprio itinerario).

    Come evidente l'approccio usato per ora e' molto semplice e basilare. Ha come difetti la duplicazione di dati potenzialmente uguali al 99%, tuttavia e' molto piu' sicuro (dal punto di vista delle modifiche) e molto piu' semplice da realizzare.

CONCLUSIONI DEL VERBALE

Restano validi per la prossima riunione le proposte inserite nella tabella. La proposta sulla modificabilita' delle schede funzionali viene rinviata a data da destinarsi. Aggiungete a tale tabella altre proposte di discussione su argomenti specifici.

Verbale riunione del 26/04/2007

Nella riunione odierna sono stati affrontati i seguenti argomenti:

  1. Ridefinizione delle specifiche del protocollo per includere l'utilizzo dei webservices. In particolare sono stati ridefiniti i paragrafi 5.2, 5.3, 5.4 riguardanti le richieste supportate dal DF.
  2. Discussione sulle possibili soluzioni al problema "Inserimento o modifica di schede contenute nel DS".
  3. Discussione sulla possibile estensione della opzione di modifica anche alle schede funzionali (home page, menu, form)

Di seguito riporto le discussioni/decisioni/proposte avanzate sui 3 punti elencati.

  1. Ridefinizione delle specifiche del protocollo per includere l'utilizzo dei webservices
  2. In vista dell'adozione della "alternativa figa" riguardo all'utilizzo dei webservices (trovate l'intera discussione sull'argomento nel verbale del 24/04/2007 qui[inserire link al verbale]) si e' discusso su come modificare le specifiche per adottare tale alternativa. L'utilizzo dei webservices comportera' la modifica totale del macro paragrafo 5 ("Richieste al data formatter") e di tutti i suoi sotto punti. Questi seguenti sono dei riassunti riguardo alle principali differenze tra il vecchio protocollo e la nuova versione. La nuova versione del protocollo verra' stilata e resa pubblica entro domani ed includera' tutte le modifiche maturate fino ad oggi. Purtroppo vista l'entita' e la particolarita' delle modifiche non e' stato possibile (aveva poco senso) fornire delle micro versioni del protocollo fino ad oggi; di conseguenza la prima versione che sara' pubblicata differira' abbastanza da quella iniziale ma includera' gia' al suo interno una importante e grossa modifica (i webservices in questione).

    • Paragrafo "5.1 , Il catalogo" DIFFERENZE
    • Innanzitutto e' stato chiarito come la richiesta del catalogo non debba essere tecnicamente gestita direttamente dal DF.

      OGGI

      Attualmente tale richiesta e' una semplice GET HTTP indirizzata alla URL di riferimento del catalogo. Sostanzialmente io AC richiedo la risorsa http://tw.web.cs.unibo.it/catalogo.xml , dove "catalogo.xml" e' un documento xml che rispetta la grammatica descritta al punto "6.1" delle specifiche. Il documento che ottengo contiene tutte le meta informazioni del DF.

      DOMANI

      Fattibilita' tecnica permettendo chiedere il catalogo equivarra' a chiedere il file WSDL che mi descrive il mio webservice DF. Un file WSDL e' sempre e comunque un documento XML che contiene tutte le informazioni associate al servizio. Al momento non sono ancora sicuro che all'intero di un file WSDL sia possibile inserire TUTTE le informazioni attualmente presenti nel catalogo. Se questo non fosse possibile allora la situazione sara' questa (male che vada):

      1. Un file "catalogo.xml" accessibile come attualmente gia' avviene, tale file pero' conterra' solo informazioni sul servizio come: descrizione, tipo di output ecc. In particolare al posto degli attuali elementi "url-elenco", "url-formattazione", "variabile-dati-formattazione" ci sara' un solo elemento che sara' "url-wsdl".
      2. Nell'elemento "url-wsdl" vi sara' ovviamente la URL che punta al mio file WSDL. All'interno di questo file saranno presenti tutte le specifiche riguardanti l'interazione con il webservice-DF ovvero: definizione di tutti i metodi esposti dal webservice, url relativa allo script che fornisce il servizio (il mio vero e proprio DF).
      3. Io AC leggo il file "catalogo.xml", estraggo l'url del WSDL e genero il mio "proxy" per il webservice-DF basandomi sul WSDL puntato da quella url (in php: $mioProxy = new SoapClient?(URL-WSDL))
      4. Da questo momento io AC eseguo ogni richiesta al DF semplicemente usando il mio proxy in questo modo (per php): $mioProxy->richiestaElenco() oppure $mioProxy->formattaDocumento(idLayut, idSkin, documentoDaFormattare) o in generale $mioProxy->MetodoDefinitoNelWsdl() a patto che tale metodo sia effettivamente definito nel WSDL (e la definizione di questi e' compito del working group)

      Ribadisco (se mai ce ne fosse bisogno) che comunque richiedere il "catalogo" e/o il WSDL non e' una funzione che deve gestire direttamente il DF, si tratta semplicemente di GET HTTP a documenti XML resi pubblici e leggibili ad una determinata URL in fase di registrazione del proprio DF.

    • Paragrafo "5.2 , L'elenco" DIFFERENZE
    • Innanzitutto e' stato chiarito che l'elenco ritornatomi dal DF e' una serie di associazioni LAYOUT->SKIN dove la relazione tra i due elementi e' di 1->n (un layout puo' prevedere piu' skin diverse da potergli associare). Questo significa che NON e' l'AC a specificare l'url della skin da usare, l'AC puo' solo indicare tra le scelte fornite dal DF quale usare (voglio il layout 2 con la skin 12, sempre ammesso che questa associazione rispetti quelle fornite dal DF).

      OGGI

      Attualmente la richiesta dell'elenco prevede da parte dell'AC di effettuare una semplice GET HTTP all'url specificata nel catalogo nell'elemento "url-elenco". Tale richiesta http viene gestita altrettanto semplicemente dal DF, il quale risponde con un documento xml contenente l'elenco di layout e skin disponibili.

      DOMANI

      A seguito dell'utilizzo del webservice la richiesta dell'elenco layout+skin si risolvera' in una semplice invocazione (da parte dell'AC) di un metodo cosi definito nel documento WSDL:

      String richiediElenco()

      Questo metodo non ha bisogno di parametri in input. L'output del metodo e' una stringa contenente l'albero xml (ben formato) cosi come descritto (attualmente) nel punto "6.2" delle specifiche del protocollo.

    • Paragrafo "5.3 , Formattazione di dati XML per un intero documento" DIFFERENZE
    • OGGI

      Attualmente e' prevista l'invio della richiesta al DF mediante l'url specificata nel catalogo. Tale richiesta deve contenere al suo interno sia i parametri della formattazione (voglio il layout 12 con la skin 14) sia i dati che effettivamente vanno formattati dal DF.

      DOMANI

      Sparira' definitivamente la grammatica descritta dal DTD presentato al punto "5.3" dalle specifiche attuali. In particolare richiedere la formattazione di un documento si risolvera' in una invocazione (da parte dell'AC) di un metodo cosi definito nel documento WSDL:

      String formattaDocumento(int layout, int skin, String mioDocumento)

      Come vedete le informazioni su layout e skin che prima bisognava specificare insieme ai dati da formattare (ovvero nello stesso albero xml totale) ora invece diventano parametri del metodo e quindi correttamente separati dai dati veri e propri da formattare. Il DF nell'implementazione di tale metodo potra' quindi salvarsi separatamente i parametri "funzionali" (voglio questo layout, voglio questa skin) dal documento xml contenente effettivamente i dati da formattare. Soprattutto non dovra' piu' validare tutto l'albero xml rappresentante la mia richiesta (e contenente anche i dati, da validare ulteriormente) ma si preoccupera' di validare solo i dati xml che sono da formattare (il contenuto del parametro "mioDocumento"). In particolare, ad esempio, posto che l'AC abbia specificato un layout o una skin non corretta, il DF potra' per prima cosa valutare la correttezza di questi due parametri, evitando quindi di dover validare il documento xml nel caso i parametri siano sbagliati (ovvero ho richiesto un layout non presente, oppure una skin non associabile al layout scelto ecc...). Errori riguardanti il tipo dei parametri passati al metodo (ovvero passo tre stringhe anzi che due interi ed una stringa, ecc...) saranno restituiti e correttamente identificati direttamente dal webservice stesso, ovvero dalle librerie che consentono la comunicazione tra AC e DF; non sara' quindi compito del DF capire se anzi che un intero l'AC mi ha passato una stringa. L'output restituito dal metodo e' una stringa contenente l'albero xml del documento formattato (nel caso di un DF xhtml conterra' direttamente l'xhtml formattato che io AC devo spedire NON MODIFICATO direttamente al mio user-agent (il browser ad esempio)).

      NOTA BENE 1: l'AC non ha alcun diritto e ne potere di modificare l'output restituitogli dal DF cosi come specificato al punto "6.3" delle specifiche. L'AC deve esclusivamente redirigere l'output del DF verso lo user-agent, senza apportare modifiche sostanziali all'output stesso ad eccezzione esclusiva del "content/type".

      NOTA BENE 2: vi chiedo cortesemente di effettuare delle prove implementative per verificare che, ad esempio nel caso di un DF pdf, non ci siano problemi nel restituire un contenuto binario (il pdf stesso) all'intero della stringa di output. Mi e' venuto in mente solo ora, spero che funzioni comunque smile

    • Paragrafo "5.4 , Formattazione di dati XML per un frammento di documento" DIFFERENZE
    • Una cosa e' stata chiarita in particolare: non ha senso formattare frammenti per un DF di tipo pdf.

      Segnalo inoltre un dubbio che e' sorto oggi durante la riunione: e' logico/corretto passare informazioni su layout e skin anche quando devo formattare un frammento e non l'intero documento?

      Attualmente il protocollo prevede che in entrambi casi di formattazione l'AC debba specificare il layout e la skin da usare per la formattazione. Abbiamo rimandato la discussione e la decisione definitiva per la prossima riunione, tuttavia vi fornisco gia' da ora le mie considerazioni riformulate a freddo post-riunione sull'argomento.

      MIE OPINIONI

      In sostanza secondo me non ha senso ed e' un errore consentire la specifica di un layout e di una skin per la formattazione di un frammento. Queste sono le motivazioni per quanto dico:

      • Coerenza 1: mi sembra chiaro che permettere cio' permetterebe casi in cui per l'intero documento(pagina xhtml) uso un layout+skin mentre per quella singola porzione uso una skin totalmente diversa, generando quasi sicuramente incoerenza grafica
      • Coerenza 2: dato che alla fonte chi decide il layout+skin e' l'utente navigatore del mio portale (mediante apposito menu a tendina) allora bisognerebbe, per ogni singola porzione del documento, fornire un menu a tendina per permetterne una visualizzazione diversa. Mi sembra una complicazione assurda. Sia chiaro che NON e' l'AC a decidere quale layout o skin usare, l'AC si limita a comunicare tali preferenze (espresse dall'utente) al DF, punto.
      • Esperienza passata: l'anno scorso anno avuto l'identico problema e l'hanno risolto impedendo una ulteriore scelta nel caso dei frammenti. Semplicemente il frammento formattato si "beccava" la formattazione gia' decisa per l'intero documento.
      • Motivazioni tecniche: dato che il layout e la skin si decidono al momento della formattazione dell'intero documento mediante inserimento di link al css scelto e mediante opportuna disposizione degli elementi nella pagina (entrambe le cose fatte ovviamente ed esclusivamente dal DF) consentire una ulteriore scelta di layout+skin richiederebbe l'utilizzo del tag "style" di xhtml ad esempio per poter specificare una skin diversa per quel frammento. Ricordatevi infatti che nella formattazione di un frammento non vengono generati anche l'head o il body del documento xhtml ma soltanto il div attinente al mio frammento. Ricordatevi inoltre che non e' ammessa la modifica a posteriori dei link css da parte dell'AC.
      In sostanza secondo me non ha senso gestire tale cosa; semplicemente il frammento restituitomi dal DF si buschera' il layout e la skin gia' scelte per il documento di cui fa parte. Se vi state ponendo la seguente domanda: se io non posso specificare layout e/o skin allora che cavolo fa il DF nel caso di un frammento? a che mi serve? La risposta a tale domanda e': il DF comunque mi serve perche' mi genera l'xhtml finale che l'AC inserira' al posto del frammento iniziale.

      NOTA BENE: la formattazione di un frammento ha evidentemente e palesemente senso nel caso di architettura ajax. Nel caso di architettura php semplice puo' avere comunque senso nel caso di politiche di caching da parte dell'AC, tuttavia la possibilita' di caching da parte dell'AC va seriamente ed attentamente valutata, poiche' potrebbe introdurre problemi vari. Pensiamoci :-)

      FINE MIE OPINIONI

      A parte le problematiche di cui sopra questo che segue e' il raffronto tra la situazione pre e post webservices.

      OGGI

      Attualmente e' prevista l'invio della richiesta al DF mediante l'url specificata nel catalogo. Tale richiesta deve contenere al suo interno sia i parametri della formattazione (voglio il layout 12 con la skin 14) sia i dati che effettivamente vanno formattati dal DF.

      DOMANI

      Sparira' definitivamente la grammatica descritta dal DTD presentato al punto "5.4" dalle specifiche attuali. Dipendentemente dalla discussione della prossima riunione spariranno potenzialmente anche la specifica di layout e skin. In particolare richiedere la formattazione di un documento si risolvera' in una invocazione (da parte dell'AC) di un metodo cosi definito nel documento WSDL:

      Nel caso si decida di specificare comunque layout+skin String formattaFrammento(int layout, int skin, String mioFrammento)

      Nel caso si decida di non rendere specificabili layout+skin String formattaFrammento(String mioFrammento)

      L'output del metodo sara' una stringa contenente il mio documento formattato. Nel caso di un DF xhtml conterra' il codice xhtml, nel caso di un DF pdf dovrebbe contenere il pdf generato (che e' un binario) quindi come ho gia' chiesto facciamo delle prove implementative per vedere se ha senso e si puo' fare il discorso di restituire dati binari in un output di tipo stringa.

    • CONCLUSIONI
    • Le modifiche precedentemente descritte genereranno la nuova versione del protocollo per il DF che spero di pubblicare entro domani. Per motivi tecnici e di orgoglio la numerazione del nuovo protocollo potrebbe partire direttamente da 0.9.5 smile .

  3. Discussione sulle possibili soluzioni al problema "Inserimento o modifica di schede contenute nel DS".
  4. Si e' discusso in generale su possibili soluzioni da adottare per l'inserimento o la modifica di schede nel DS. La decisione piu' o meno unanime prevede che:

    MODIFICA DI UNA SCHEDA

    1. L'utente vuole modificare una scheda
    2. L'AC richiede la scheda al DS
    3. Il DS restituisce la scheda richiesta dove ogni elemento di una scheda ha un attributo associato di tipo "edit=si/no"
    4. L'AC incapsula la scheda ottenuta dal DS all'interno di un tag "edit""/edit" per avvisare il DF di permettere la modifica della scheda
    5. Il DF in base al tag radice "edit" capisce che la scheda va resa in modalita' editaggio ed in base al valore dei vari attributi "edit=si/no" permettera' la modifica dei vari campi della scheda. Come il DF fara' questo a livello visivo e' decisione esclusiva di chi implementa il DF, non ci sono vincoli se non quello di permettere effettivamente la modifica di cio' che e' modificabile e viceversa.

    AGGIUNTA DI UNA NUOVA SCHEDA

    1. L'utente vuole creare una nuova scheda
    2. L'AC richiede al DF di creare la visualizzazione per la creazione di una nuova scheda
    3. il DF restituisce l'output utile per inserire i nuovi contenuti

    Questo secondo caso non e' stato affrontato ancora in modo esplicito. In particolare sara' necessario specificare come, i dati aggiunti dall'utente mediante il "submit" finale", debbano essere indirizzati all'AC stesso, il quale a sua volta li passera' al DS.

  5. Discussione sulla possibile estensione della opzione di modifica anche alle schede funzionali (home page, menu, form)
  6. E' stato proposto da Giacomo Magisano (spero di non sbagliarmi smile ) durante la riunione di poter estendere il concetto di editaggio anche alle schede funzionali. La sua idea prevede la possibilita' da parte dell'utente di poter specificare e modificare il contenuto di homepage, menu ecc.. Un esempio in tal senso prevede questo:

    • L'utente naviga sulla home page del portale e, tra i menu visualizzati, decide che le 30 voci del menu a sinistra non gli interessano. In particolare gli interessano solo 5 di quelle.
    • L'utente puo' specificare di far sparire quelle voci a lui non utili mediante un meccanismo opportuno fornitogli
    Un esempio reale in tal senso potrebbe essere quello che google attualmente fa nella pagina principale di ricerca; ovvero fornisce la possibilita' di creare menu personalizzati o comunque di variare il contenuto dei menu. E' stato deciso di rinviare la decisione su questo argomento alla prossima riunione. Di seguito vi riporto le mie considerazioni meglio formulate a freddo post-riunione sull'argomento.

    MIE OPINIONI

    Secondo me non ha senso fornire questa possibilita' per pochi, semplici e lampanti motivi (uno dei quali mi e' venuto in mente solo dopo la riunione).

    • Motivazioni temporali: come detto anche in riunione siamo tutti consci che tale opportunita' nessuno avra' il tempo di sfruttarla nei suoi DF.
    • Motivazioni tecniche 1: credo che la complessita' aggiuntiva di fornire questa possibilita' si rifletta pesantemente anche su chi questa possibilita' non vuole gestirla. Inoltre si riflette sia a livello di AC sia a livello di DF. In sostanza non credo sia una opzione che chi vuole gestirla fatti suoi e chi no poco male.
    • Motivazioni tecniche 2 (FONDAMENTALE): gestire questa opzione richiede coerentemente di gestire anche un meccanismo di gestione della sessione utente. In particolare sarebbe necessario o gestire il login dell'utente (cosa che abbiamo gia' deciso di non fare) oppure bisognerebbe gestire correttamente i cookies per salvarsi queste preferenze.

    Facendo riferimento all'ultimo punto descritto mi sembra chiaro che i cookies sono purtroppo poco utili allo scopo. Se li cancello oppure mi collego da un altro pc/browser tutte le mie preferenze spariscono. Per dare un senso a questa opzione bisognerebbe gestire il login dell'utente, in modo da fornire un modo stabile di salvare le proprie preferenze; questo pero' abbiamo gia' chiarito che non lo faremo vista la complessita' del tutto.

    FINE MIE OPINIONI

CONCLUSIONI DEL VERBALE

Vista la decisione fondamentale presa sui webservices pubblichero' il prima possibile la nuova versione del protocollo, contenente tutte le modifiche descritte in questo verbale. Si rimandano alla prossima riunione le decisioni sulle discussioni rimaste aperte. Per avanzare proposte di discussione per la prossima riunione ho inserito in testa pagina una tabella da compilare.

Verbale riunione del 24/04/2007

Nella riunione odierna sono stati affrontati e sviscerati i seguenti argomenti:

WEBSERVICES

Assumendo che ormai sappiate rispondere alla domanda "cosa sia un webservices" (altrimenti partite da qui: http://en.wikipedia.org/wiki/Web_service, e qui: http://vitali.web.cs.unibo.it/TechWeb07/IntroSOAP), oggi si e' appunto discusso su come sia possibile sfruttare tale architettura cosi come richiesto dalle specifiche. In particolare io (chair smile ) ho proposto una modalita' di utilizzo dei webservices che richiederebbe una modifica sostanziale delle specifiche e del protocollo. NOTA: Quanto diro' adesso e' di interesse generale per i due working group e per tutti coloro che devono fare il progetto entro giugno.

  1. Introduzione
  2. Nella definizione e specifica del protocollo di comunicazione (tra AC<->DF e AC<->DS) e' compito nostro decidere come la trasmissione dei dati deve avvenire. Questo richiede e presuppone due decisioni importanti:

    • Decidere quali tipi di richieste vengono gestite da DF e DS, in termini di grammatiche specificanti il formato della richiesta (e della risposta)
    • Decidere su quale protocollo di comunicazione appoggiarsi per inviare richieste e ricevere risposte.

  3. Ciao amico webservice (post-introduzione)
  4. Sostanzialmente esistono due possibilita'/alternative/modalita' di utilizzo dei webservices all'interno del nostro progetto/protocollo: una baldracca ed una figa (o meglio una semplicistica e terra terra ed una invece che piu' rispetta il concetto stesso di webservices). Spieghero' nei seguenti punti le differenze tra queste due possibilita', le cose in comume, ed i motivi per i quali sarebbe corretto (molto democraticamente smile ) scegliere la seconda.

  5. Aspetti in comune per entrambe le alternative
  6. A prescindere da quale approccio sceglieremo sicuramente vi saranno delle cose che bisognera' specificare e fornire in entrambi i casi; queste saranno:

    • Un file di descrizione (WSDL) del webservice DF
    • Un file di descrizione (WSDL) del webservice DS

    All'interno di tali file bisognera' fornire la descrizione (l'interfaccia) dei due servizi, specificando i metodi forniti dai servizi stessi.

  7. Modalita' baldracca (anche detta "modalita' del postino")
  8. Questa scelta prevede di sfruttare il protocollo webservice come una semplice (e stupida) "capsula" all'interno della quale inserire le nostre richieste per DF e DS. In particolare nei due WSDL si specifichera' UN SOLO metodo per servizio che non faccia altro che prendere un parametro stringa in input e restituire un output di tipo stringa.

    Supponendo di essere nei panni del DF questo significa che:

    • il DF espone un solo metodo pubblico che si chiama "richiesta"
    • tale metodo e' cosi definito: "String richiesta(String query)
    Supponendo ora di essere un AC questa sarebbe la sequenza tipica di utilizzo del webservice:
    1. Compongo il mio albero xml contenente:
      • i parametri di interesse per il DF
      • tutto l'albero xml del documento da formattare
    2. Trasformo questo documento xml in una stringa
    3. Invoco il metodo "richiesta" passandogli in input tale stringa
    4. Aspetto la risposta del webservice (ovvero del DF)
    Il succo di questo approccio e' che il webservice lo usiamo esattamente come l'anno scorso usavano CURL, ovvero per spedire e ricevere dei dati dove i dati stessi contengono sia la richiesta che i dati sulla quale eseguirla.

    Mi spiego meglio....

    Attualmente abbiamo come compito quello di stabilire delle grammatiche xml in base alle quali comporre richieste valide (ed ottenere risposte valide).

    In particolare se io AC volessi chiedere una formattazione al DF dovrei creare un unico albero (documento) xml che mi rappresenti la richiesta vera e propria e che contenga quindi:

    • i parametri della richiesta (eg: voglio questo layout con questa skin)
    • i dati da formattare (e che sono a loro volta un albero xml)
    Il compito del DF e' quello di:
    1. validare la richiesta che riceve (basandosi su schema + schematron o su relaxng + schematron)
    2. estrarre dall'albero xml i parametri della richiesta
    3. estrarre il documento da formattare
    4. validare il documento da formattare
    5. eseguire la richiesta
    6. inviarmi la risposta
    In base a quanto detto e' evidente che NON e' l'invocazione di un metodo del webserice DF che mi caratterizza la richiesta ma invece e' la stringa passata in input (ovvero il documento xml) che mi rappresenta sia il tipo di richiesta sia i parametri, che i dati sui quali eseguirla; ovvero ho un metodo unico generico il cui unico ruolo e' quello del postino, non fa altro che consegnare un messaggio, il messaggio stesso mi rappresenta sia la richiesta che i dati su cui eseguirla.

    Vi faccio un esempio:

    Sono al ristorante e voglio ordinare una cotoletta alla bolognese.

    Il cuoco rappresenta per me il servizio vero e proprio (il DF per intenderci, colui che realizzera' la mia richiesta) mentre il cameriere e' un mezzo comunicativo (il webservice di per se, colui che mi permette di inviare al cuoco una richiesta, il suo "rappresentante").

    Seguendo l'approccio "baldracco" descritto sopra, per ordinare una cotoletta alla bolognese farei cosi:

    1. scriverei su un bigletto il cibo che desidero, specificando anche il tipo di cottura ed altri "parametri" (ovvero mie preferenze) utili al cuoco per fornirmi un "output" di mio gradimento
    2. Chiederei al cameriere di consegnare questo biglietto direttamente al cuoco
    3. se tutto va bene il cuoco eseguirebbe la mia richiesta e, una volta pronto, chiederebbe al cameriere di portarmi la cotoletta

    Come potete notare in questa sequenza il ruolo del cameriere e' quello di "semplice postino"; il suo unico compito e' quello di portare il biglietto al cuoco e di portare il piatto pronto al cliente. In nessun modo il cameriere facilita la comunicazione tra me ed il cuoco (ad esempio dicendomi direttamente cosa posso ordinare [a prescindere dal menu, spesso i piatti del menu in tal giorno non sono disponibili], cosa oggi non e' disponibile ecc...)

    Per capire meglio il perche' questo approccio non sia vantaggioso immaginatevi una sequenza del genere:

    1. scrivo sul biglietto che voglio una cotoletta alla bolognese, la voglio con carne di cavallo e con il salame al posto del prosciutto e possibilmente senza sugo di contorno.
    2. il cameriere consegna il biglietto al cuoco
    3. il cuoco si incazza ( :-)) perche' la richiesta non e' corretta (non te la faccio la cotoletta alla bolognese con carne di cavallo, e non ci metto il salame al posto del prosciutto ecc...)
    4. il cameriere mi comunica il fallimento della richiesta
    5. analizzo gli errori nella mia richiesta e la riformulo
    6. riparto dal punto "a" corregendo gli errori commessi

    A parte notare come il cuoco sia molto permaloso smile quello che si evidenzia e':

    • il cameriere e' inutile, perche' pagarlo? :-)
    • prima di accorgermi di uno sbaglio devo arrivare al punto "e" e, nel caso, ripartire dall'inizio
    • il cuoco non ha potenzialmente tempo di assicurarsi che la richiesta sia corretta (potrebbe farlo il cameriere!)

    Riassumendo questo possibile approccio e' sostanzialmente banale, non sfrutta in alcun modo la "potenza" dei webservices, non se ne avvantaggia assolutamente, usiamo un cannone per uccidere una mosca. Vediamo ora il secondo approccio...

  9. Modalita' figa (anche detta "il webservice e' il mio pastore")
  10. Questa seconda possibilita' prevede di avvantaggiarsi dell'utilizzo di un webservice con lo scopo primario di separare e di tenere distinti:

    • il tipo di richiesta che voglio fare
    • i parametri di questa richiesta
    • i dati su cui eseguire la richiesta
    In questo caso dovremo sempre e comunque descrivere e fornire due interfaccie WSDL per DF e DS ma con una grossa differenza: i due webservice non forniranno piu' un solo metodo generico "richiesta" che prende in input una stringa (il mio complesso documento xml) e da in output una stringa. Il webservice (tramite il WSDL) fornira' invece:
    • un metodo specifico per ogni richiesta supportata (nel caso del DF 3 metodi, uno per l'elenco e gli altri due per la formattazione di documenti o frammenti)
    • ogni metodo prendera' in input non piu' un solo parametro ma tanti parametri divisi in queste due categorie: Funzionali: "n" parametri utili a fornire informazioni al DF (eg: voglio questa skin, questo layout ecc...) Dati: UN SOLO PARAMETRO di tipo stringa che mi identifica UNICAMENTE il documento xml da formattare

    Supponendo di essere nei panni del DF questo significa che il DF espone TRE metodi pubblici cosi definiti (ad esempio):

    • String richiesta_elenco()
    • String formatta_documento(int layout, int skin, String documento)
    • String formatta_frammento(in layout, int skin, String frammento)

    Supponendo ora di essere un AC questa sarebbe la sequenza tipica di utilizzo del webservice:

    1. Trasformo in stringa il mio documento xml da formattare (ad esempio la scheda di Parigi)
    2. invoco l'opportuna funzione formatta_documento(1, 3, mio_documento) dove specifico che voglio il layout di id=1 con la skin di id=3 e che "mio_documento" sono i dati da formattare
    3. aspetto il risultato del metodo, ovvero la stringa del documento formattato

    Come spero sia lampante in questo caso abbiamo separato NETTAMENTE la logica "funzionale" del DF (e dei suoi metodi) dai dati sui quali il metodo dovra' lavorare. In particolare:

    • per formulare una richiesta basta invocare il metodo opportuno
    • i parametri "funzionali" (id del layout, della skin..) sono separati dai dati da formattare
    • il webservice impone e garantisce subito una corretta formulazione della richiesta, ovvero:
    • il DF NON si deve preoccupare di validare la richiesta (da un punto di vista grammaticale, con schema+schematron ad esempio) ma si deve preoccupare solo di validare i dati sui quali andra' a lavorare
    • il DF, grazie al webservice, lo utilizzo come se fosse una classe, un oggetto, direttamente presente nella mia applicazione; invocando metodi su di esso come sono abituato a fare con le classi, SENZA preoccuparmi se il DF si trova in Iran anzi che su brangania in lab ercolani.

    Riesumando l'esempio del ristorante per ordinare una cotoletta alla bolognese adesso farei cosi:

    1. chiamo il cameriere chiedendogli quali sono i piatti del giorno
    2. chiedo una cotoletta alla bolognese, specificando tutte le mie preferenze (ben cotta, poco sugo ecc..)
    3. il cameriere accetta la mia richiesta (e' valida) e avverte il cuoco di cucinare la cotoletta
    4. quando il cuoco avra' finito il cameriere mi portera' il piatto pronto

    Risulta ora evidente l'importanza del ruolo del cameriere; agevola la comunicazione, blocca subito eventuali formulazioni palesemente sbagliate della mia richiesta. In particolare sara' direttamente il cameriere a dirmi che la cotoletta alla bolognese con carne di cavallo, il salame al posto del prosciutto e poco sugo, non e' una richiesta valida, ovvero soddisfabile. In tutto questo il cuoco non e' necessario interpellarlo, il cameriere e' un suo rappresentante (una interfaccia verso il cuoco) utile e funzionale.

  11. PRO E CONTRO DELLE DUE SCELTE
  12. -- Modalita' baldracca

    PRO:

    • il (falso smile ) senzo di sicurezza derivato dal seguire una specifica del protocollo identica a quella dell'anno scorso (unica differenza: usiamo webservice anzi che curl come postino)
    CONTRO:
    • bisogna definire tutte le grammatiche per le richieste/risposte valide
    • ogni DF o DS deve validare sia la richiesta che i dati ricevuti
    • eventuali modifiche, anche minime, ad una di queste grammatiche comporta modifiche estese potenzialmente su tutto il codice di DF o DS

    -- Modalita' figa

    PRO
    • Separa nettamente il tipo di richiesta dai suoi parametri funzionali e dai dati effettivi
    • il DF o DS non deve validare e processare la richiesta ed i dati associati, basta che implementi una funzione per ogni metodo fornito. Molti controlli di correttezza vengono fatti implicitamente dal webservice (aggratis!)
    • Modificare la definizione di una richiesta (ad esempio il formatta_documento) per includere o rimuovere informazioni richiede la banale modifica della definizione del metodo (aggiungo un parametro, tolgo un parametro ecc..) e l'altrettanto banale e immediata modifica dell'implementazione di SOLO quel metodo.
    • scriviamo DUE soli file WSDL una volta per tutte e NON svariate grammatiche diverse per ogni richiesta possibile e supportata

    CONTRO
    NON PERVENUTI smile

  13. Conclusioni
  14. Il succo di tutto questo discorso e' che possiamo fare una scelta veramente utile e vantaggiosa che inoltre non richiede competenze o lavoro aggiunto ma anzi semplifica e diminuisce il lavoro da fare (non 10/20...n grammatiche per ogni richiesta/risposta valida, DUE soli file WSDL, restano ovviamente da fare le grammatiche per i dati). Nonostante tutto l'impegno che ho messo per rendere chiare le differenze tra le due scelte mi rendo conto che alcuni punti saranno sicuramente oscuri o non menzionati, a tal proposito conto di fare una spiegazione orale domani per il working group DS dato che il mio working group si e' gia' sorbito (felicemente smile ) tutta la spiegazione live.

ALTRE INFORMAZIONI SULL'ARGOMENTO WEBSERICES

A prescindere dalla decisione che prenderemo resta tuttavia necessario studiarsi il comportamento e le modalita' di utilizzo ed implementazione dei webservices su PHP e JavaScript?.

Come spiegato durante la riunione ho implementato un semplice webservices PHP (un HelloWord?) al quale vi si interfacciano due client: uno php ed uno javascript.

Gli esempi sono disponibili a questi URL:

Questi sono invece link ad informazioni utili sull'utilizzo dei webservices da php
to top


You are here: TechWeb07 > WorkingGroupACDF

to top

Copyright? © Fabio Vitali + TechWeb students 2006