5. Uso di web services in Drupal
Il presente capitolo si pone come obiettivo di presentare un modulo esterno chiamato RemoteCCK per il content management Drupal che implementa le funzionalità descritte nel capitolo precedente.
5.1 Stato dell'arte dell'uso di Web Services su di Drupal
Occorre avere ben chiaro quali sono le possibilità di Drupal di gestione di servizi esterni in modo da poter scegliere se appoggiarsi nello sviluppo ad altri moduli o meno.
Tra i moduli esterni si ricorda il modulo “Services” (32) che si pone come obiettivo l’introduzione di API per la comunicazioni di dati.
Infatti questo modulo, che sarà integrato in Drupal 7, permette di utilizzare protocolli come XML-RPC, JSON, JSON-RPC, REST, SOAP, AMF, etc.
Tra le caratteristi si ricordano:
API per la creazioni di server basati si REST e SOAP
API per la creazione di servizi
integrazione con funzionalità come file, nodes, taxonomy, users
Anche se queste funzionalità potrebbero risultare appetibili, l’assenza del supporto al linguaggio WSDL non lo rendono compatibile per l’applicativo che si vuole sviluppare.
Il modulo SOAP Server (33) permette sia di trasmettere dati tramite protocollo SOAP che l’utilizzo del linguaggio WSDL.
Il modulo, si appoggia alla libreria NuSOAP (30), ed offre soltanto un interfaccia per effettuare veri chiamate SOAP.
Purtroppo il presente modulo risulta non risulta attualmente sviluppato dalla data 27 ottobre 2008, questo assieme alla carenza delle funzionalità offerte non lo rendono una buona scelta tra i moduli da usare.
Da queste considerazione si evince che utilizzare moduli esterni per la comunicazione non è da considerarsi una scelta utile per lo sviluppo dell’applicativo.
5.2 Generalità sull'implementazione
Dalle considerazioni del paragrafo precedente, per le realizzazione dell’applicativo, oltre ad essere usato il content management Drupal, è stato usata presa in considerazione la libreria per il supporto di web service chiamata NuSOAP.
Essendo l’interfaccia utente di fondamentale importanza per il successo dell’applicativo, è stato scelto di utilizzare la famiglia di tecnologie AJAX per poter effettuare richieste asincrone verso Drupal.
Al fine di avere un adeguato supporto di AJAX è stata usata la libreria esterna JQuery che si interfaccia a Drupal tramite il modulo jQuery UI (33). Questa libreria oltre ad essere molto completa lascia allo sviluppatore piena libertà ed è quindi indicata per lo sviluppo di interfacce web dinamiche.
5.2.1 Menu
Concettualmente è possibile distinguere RemoteCCK in due aree funzionali diverse, quella di utilizzo e quella di amministrazione.
Della prima area fanno parte tutte quelle funzioni che permettono l’esecuzione di richiesta di operazioni da sistemi remoti, oltre che tutte le operazioni di aggregazione (vedi paragrafo specifica requisiti utente per l’utente semplice).
Della area amministrazione fanno parte tutte le funzioni dell’utente amministratore come specificato nel paragrafo specifica requisiti utente. Al fine di rendere l’applicativo maggiormente integrato all’interno di Drupal è stato scelto di inserire l’area di utilizzo all’interno del menu “Create content”, mentre il menu amministrazione come sottomenu dell’area di amministrazione di “admin/settings/remotecck”.Di seguito viene mostrata come viene visualizzato il menu di amministrazione di RemoteCCK:
Figura 16: Menu di RemoteCCK
5.2.2 Generalità sul Database
RemoteCCK utilizza il database di Drupal per il salvataggio di tutte le informazioni riguardanti:
credenziali di accesso al web service
l’analisi del web service
il mappaggio tra content type e operazione del web service
il mappaggio del template di aggregatori
le informazioni riguardante la connessione tra content type e template di aggregatore
La rappresentazione del database è il seguente:
Figura 17: Diagramma del database di RemoteCCK
Queste tabelle vengono inoltre usate per effettuare la ricerca delle operazioni per i template di aggregatore.
Più nel dettaglio le tabelle hanno le seguenti funzioni:
1. remotecck_wsdl_info contente le informazioni e le credenziali del web service 2. remotecck_operation contente le operazioni dei web service
4. remotecck_parameter contente i parametri base che formano i vari messaggi 5. remotecck_cck_created per la gestione della connessione tra operazioni del web
service e content type
6. remotecck_mapping per la gestione del campo di un content type e parametro di un’operazione
7. remotecck_aggregator_name contente le informazioni sul template di aggregatore 8. recotecck_aggregator_mapping contente il mappaggio del template
dell’aggregatore
9. remotecck_aggregator_mapping_content_type contente la connessione tra content type ed aggregatore
5.2.3 Entity Relationship Model
Il modello Entità Relazione dell’applicazione è la seguente:
5.2.4 Logica di funzionamento del modulo RemoteCCK
Il modulo RemoteCCK basa il suo funzionamento sulla programmazione ad eventi propria di Drupal.
Infatti Drupal mette a disposizione particolari funzioni chiamati hook che permettono ad un generico modulo di agganciarsi durante la visualizzazione delle generiche pagine del CMS.
Questo permette ad un generico modulo di modificare, anche radicalmente, il comportamento di Drupal senza doverne toccare il sorgente.
RemoteCCK quindi si mette in mezzo tra il core di Drupal e l’interfaccia utente comunicando con questi due strati in maniera bidirezionale.
La rappresentazione grafica di questa metodologia è la seguente:
5.3 Inserimento ed analisi di un web service
Per l’inserimento di un nuovo web service all’interno di RemoteCCK è necessario conoscere l’URL del WSDL associato al servizio.
Inoltre, nel caso sia necessario, è prevista la possibilità di inserire le credenziali del web service, tra queste si ricordano soap version, login, password, proxy host, proxy port, proxy login, proxy password, local certificate, compression, encoding.
Le informazioni vengono salvate nelle tabelle remotecck_wsdl_info, remotecck_operation, remotecck_message e remotecck_parameter.
L’operazione di inserimento produce come risultato, due tabelle, una di input ed una di output, contenenti:
1. il nome dell’operazione
2. il messaggio di input o di output associato 3. il nome dei parametri associati ai messaggi 4. il tipo dei parametri associati ai messaggi
Lo storyboard associato a questa funzione è il seguente:
L’interfaccia grafica dove inserire l’URL del web la seguente:
Figura 21: Form d'immissione d'URL del Web Service
Nel caso si debbano inserire parametri di accesso al web server occorre inserirle nel menu a tendina “Advance Information” come mostrato nella seguente immagine:
Figura 22: Credenziali Web Service
Successivamente alla pressione del bottone “Analyze” si ottiene la schermata contenente le tabelle di analisi del WSDL oltre il messaggio di avvenuto inserimento nel database dell’analisi.
La schermata in seguito all’analisi è la seguente:
Figura 23: Risultato dell'analisi di un Web Service
Da notare che, in accordo con le specifiche di Drupal, viene restituito pure il messaggio “Insert WDSL Done” per indicare l’avvenuto inserimento.
Nel caso si tenti di reinserire un web service già presente, RemoteCCK restituirà, oltre l’analisi, un messaggio “WSDL URL PRESENT ON DATABASE” indicante che il WSDL è già presente.
L’operazioni di analisi di un WSDL è computazionalmente complessa, infatti occorre effettuare l’analisi del XML-Schema associato ai tipi.
La specifica del XML-Schema (22) permette di usare come tipo di un campo, un tipo complesso formato da altri campi e quindi la funzione di analisi permette di analizzare ricorsivamente un campo complesso fin quando non si arriva al tipo semplice (vedi Appendice A).
5.4 Modalità di aggiunta di un'operazione ad un Content Type
RemoteCCK dispone di due modalità d’aggiunta di un operazione di un web service ad un content type.
La prima è la creazione di un content type realizzato ad hoc per invocare l’operazione del web service associato, mentre la seconda è l’aggiunta di una serie di campi ad un content type già creato.
Entrambe le operazioni vengono fatte utilizzando le API del modulo CCK di Drupal.
Infatti dal punto di vista strettamente implementativo, il modulo CCK vede un content type come una tabella sul database di Drupal.
Il modulo CCK dispone dell’API “content_copy_import_form_submit”, che permette di creare e di aggiornare un content type tramite un array, opportunamente creato, contenente la nuova struttura.
L’operazione di creazione dell’array content la struttura del content type da creare od aggiornare viene effettuata dalla classe realizzata di nome “Create_content_type”.
Questa classe partendo dalla descrizione di un operazione di un web service crea il content type associato.
Considerando che i tipi base del modulo CCK sono i seguenti:
Decimal
Integer
Text
La classe si occupa di realizzare il mapping tra i tipi dei campi dell’operazione ed i tipi dei campi del content type.
Una precisazione molto importante è che esistono diverse estensioni del modulo CCK per permette di aggiungere ulteriori tipi rispetto a quelli base, che però non sono stati presi in considerazione al fine di non avere ulteriori dipendenze.
Per completezza viene riportata il codice della funzione che si occupa sia della creazione che dell’aggiornamento di un content type (vedi file utilityWSDL.php) :
function remotecck_insert_content_type($operation_name_cck, $operation, $fields, $label, $is_new_content_type) {
// Create or update a content type
$content_obj = new Create_content_type($operation_name_cck, $operation, $fields, $label); $content = $content_obj->getContent();
$form_state = array();
$form = content_copy_import_form($form_state); // or like that
include_once('./'. drupal_get_path('module', 'content') .'/includes/content.admin.inc'); include_once('./'. drupal_get_path('module', 'node') .'/content_types.inc');
// Insert the Values
$form_state['values']['type_name'] = ($is_new_content_type) ? '<create>' :$operation_name_cck; $form_state['values']['macro'] = '$content = '. var_export($content, 1) .';';
$form_state['rebuild'] = TRUE;
content_copy_import_form_submit($form, &$form_state); }
I parametri delle funzione hanno il seguente significato:
$operation_name_cck: stringa indicante il nome del content type da creare/aggiornare
$operation: stringa indicante il nome dell’operazione (usato per creare descrizione del content type)
$fields: array contente I nome ed I tipi del campi
$label: array di stringhe contente la descrizione del singolo campo che apparirà nella visualizzazione del content type
$is_new_content_type: Boolean che discrimina se si vuole creare (true) od aggiornare (false) un content type
Un ulteriore approfondimento il campo $fields, in quanto occorre specificare che nel modulo CCK un campo avrà un nome che rappresenta l’identificativo univoco del campo all’interno del sistema e questo nome dovrà iniziare con “field_” (limitazione riscontrata fino alla versione 6.14 di Drupal).
In prima analisi il nome del campo del content type sarà pari al nome del parametro dell’operazione con all’inizio la string “field_”, quindi se il parametro si chiama “pippo”, il nome del campo sarà “field_pippo”.
Ovviamente occorre gestire l’univocità del nome del campo all’interno del sistema, questa operazione viene realizzata dalla funzione (anch’esse contenuta nel file utilityWSDL.php) chiamata:
remotecck_validate_field_name($field_name)
che partendo dal nome che si vuole dare al campo, restituisce lo stesso nome modificato (tramite l’aggiunta di un opportuno codice numerico incrementale).
Quindi se il campo “field_pippo” è già stato utilizzato, la funzione restituirà il nome “field_pippo1”, nel caso anche quest’ultimo sia già assegnato, la funzione restituirà “field_pippo2”.
Ovviamente la funzione fa gli opportuni controlli sulla lunghezza della stringa (che attualmente ha dimensione massima pari a 32 caratteri) e nel caso che non possa essere effettuato l’aggiunta del codice numerico, elimina un numero adeguato di caratteri.
Oltre alla creazione del content type occorre stabilire la connessione tra l’operazione del web service ed il content type. Questa connessione viene fatta tramite due passi.
Il primo corrisponde all’inserimento all’interno della tabella “remotecck_cck_created” delle informazioni riguardante il nome del content type, l’identificativo dell’operazione e la modalità di utilizzo.
Il secondo viene fatto tramite l’inserimento del mappaggio tra il nome del campo del content type e l’identificativo del parametro dell’operazione del web service all’interno della tabella “remotecck_mapping”.
5.4.1 Creazione di un Content Type
In questo paragrafo verrà spiegata l’interfaccia grafica che permette la creazione di un nuovo content type con associato una operazione, lo storyboad è il seguente:
La schermata iniziale è la seguente:
Figura 26: Form di creazione di un content type con un'operazione
Da questa occorre inserire il nome del content type da creare e successivamente selezionare il web service dal select box chiamata “Web Services List”.
Questa lista è quella dei web service precedentemente inseriti dal menu “Insert Web Service”.
La selezione di un web service ha come effetto la creazione della select box “Operation of Web Service” contenenti tutte le operazioni ad esso associate.
Questa operazione viene effettuata tramite una richiesta asincrona al database che già contiene queste informazioni.
La seconda schermata è la seguente:
Infine con la pressione del bottone “Create new Content Type” avviene la creazione del content type oltre alla scrittura di tutte le informazioni di mapping descritte nel paragrafo precedente.
In caso che il nome del content type sia già usato, il modulo suggerisce un nome non ancora utilizzato, che può essere cambiato in caso non sia ritenuto sufficientemente esaustivo.
Questa operazione, che è del tutto simile a quella precedentemente descritta per la validazione dei nome dei campi, viene effettuata aggiungendo l’identificavo dell’operazione all’interno del database al nome del content type.
Ovviamente anche in questo caso viene preso in considerazione che il nome sia già stato utilizzato, ed in questo caso viene inserito l’identificativo del content type alla fine un numero sufficiente di volte in modo da ottenere un nuovo nome.
La schermata è la seguente:
Figura 28: Stato d'errore di duplicazione nome di content type
Se il nome risulta essere adeguato si ha una schermata di riepilogo che riassume le operazione appena effettuate:
5.4.2 Update di un Content Type
Questa seconda modalità di inserimento di un operazione all’interno di un content type risulta essere sia concettualmente che graficamente molto simile a quella precedente, lo storyboad è il seguente:
In questo caso non si deve definire il nome del content type, ma semplicemente scegliere tra quelli già presenti nel sistema:
Figura 31: Selezione del content type
Come nella modalità precedente occorre scegliere il web service e l’operazione:
Figura 32: Selezione dell'operazione
Ed infine cliccare sul bottone “Update Content Type” che produce la seguente schermata:
5.4.3 Mappaggio manuale tra un Content Type ed un operazione
Le due modalità di inserimento di operazione descritte precedentemente automatizzano il mappaggio tra campi di content type e parametri di un web service.
Ovviamente possono sussiste casi in cui questa automazione non basta, come per esempio in caso che un dato campo di un content type debba essere associato a più parametri di operazioni.
Il mappaggio manuale è pensato a sopperire a questa mancanza per introdurre una modalità di tuning, lo storyboad è il seguente:
Per effettuare ciò occorre selezione il content type in modo da far apparire la tabella “Content Type Fields” contente tutti i suoi campi:
Successivamente con una modalità analoga a quella vista precedentemente occorre selezionare web service e operazione tra quelle proposte (che sono quelle effettivamente connesse al content type):
Figura 36: Form di mappaggio tra content type ed operazione
In seguito a questa seconda scelta, appare la tabella “Operation Parameter” che descrivere i vari parametri associati alle operazioni indicando il nome, il tipo e se il parametro è di ingresso o di uscita.
Nell’immagine sovrastante è possibile vedere delle linee in verde che indicano le connessioni attualmente esistenti tra campi del content type e parametri dell’operazione.
E’ possibile agire sulle check box di destra per cancellare una connessione e definirne un'altra.
Da notare che questo tipo di mappaggio manuale è totalmente libero e quindi l’utente deve avere una totale conoscenza dell’operazione che intende mappare, pena il non funzionamento della richiesta.
Di seguito viene riportato un tipo di mappaggio totalmente errato e che quindi causerebbe il non funzionamento dell’invocazione del web service:
Figura 37: Esempio di mapping erroneo
La motivazione dell’errore è presto detto, il campo comune nascita è connesso sia tre parametri:
nome
comune nascita
sesso
Per la semantica dell’operazione del web service, un nome del comune non potrà essere accettato come descrizione del sesso dell’individuo.
Il salvataggio del nuovo mappaggio manuale avviene cliccando sul bottone “Save Mapping” che produce la seguente schermata:
5.5 Gestione dell'operazioni di un content type
Come dalle specifiche descritto nel capitolo precedente, esistono quattro tipi di utilizzo delle operazioni:
Before Submit
After Submit
During Compile
Do Nothing
L’amministrazione di queste modalità avviene tramite il menu contestuale “RemoteCCK” presente nell’edit del content type:
Queste quattro modalità definiscono il comportamento durante la richieste delle informazioni, in particolare la modalità “Before Submit” effettua la chiamata dell’operazione all’atto di creazione del documento.
La modalità “After Submit” effettua la chiamata alla pressione del pulsante di submit.
La “During Compile” permette l’invocazione dell’operazione tramite un bottone di “Make Call”, ed infine la “Do Nothing” non effettua nessuna operazione.
Ovviamente è possibile fare la scelta per ogni operazione associata al content type, ma, per evitare la comparsa di troppi pulsanti di “Make Call”, è stata prevista la possibilità di usare un unico pulsante per tutte le invocazioni.
Questa particolare modalità viene attivata se viene selezionata la checkbox “One Request Button for all operation”.
5.6 Aggregazione di più Web Service
Fin ora le funzioni presentate permettono il mappaggio tra parametri di un operazione e campi di un content type.
Concettualmente la funzione risultante è semplicemente la visualizzazione di informazioni in seguito all’invocazione del web service.
Tutto ciò, sebbene sia utile, non è l’unica modalità di utilizzo di un web service all’interno di un content type management.
Infatti, similmente a ciò che è stato fatto da linguaggi come SQL, è pensabile supporre un passo successivo per l’uso di informazioni provenienti di più web services sia quello di aggregare le loro risposte in modo da ottenere un unico valore che rappresenti tutte le informazioni ottenute.
5.6.1 Il concetto di aggregatore
Per aggregatore si indica quindi una funzione che da un insieme di valori, ne restituisca uno che in qualche maniera li vada a rappresentare.
Il concetto di aggregatore, dal punto di vista strettamente concettuale, è paragonabile agli aggregatori utilizzati nelle query SQL.
Quindi, in analogia con il linguaggio SQL, gli aggregatori che sono stati introdotti sono il seguenti:
Agregatore
Funzione svolta
MAX
Restituisce il valore massimo tra i valori considerati
MIN
Restituisce il valore minimo tra i valori considerati
Majority
Restituisce il valore che ha maggiore frequenza tra i valori
considerati
Average
Restituisce la medi aritmetica tra i valori considerati
Count
Conta il numero di risposte ottenute dai web services
Count distinct
Conta il numero di risposte diverse ottenute dai web services
Median
Restituisce il valore mediano tra i valori considerati
Per la creazione di un aggregatore occorre scegliere:
1. Il nome dell’aggregatore 2. la funzione da realizzare
3. le operazioni da utilizzare per aggregare le risposte 4. mappaggio dei parametri in funzione del content type
Ovviamente la scelta delle operazioni su cui effettuare l’aggregazione delle risposte può essere considerata lunga, per questo è tasto introdotto il concetto di template.
Questo template sarà successivamente inserito all’interno di un content type tramite il menu di editing del content type stesso.
Un template è una definizione di come un’aggregazione deve avvenire e si compone di:
1. nome
2. funzione aggregatrice
3. operazioni da usare per l’aggregazione 4. mappaggio dei campi
Un template di aggregazione quindi viene inserito all’interno di un content type (tramite menu di editing dello stesso). In seguito a questa operazione di inserimento verranno creati all’interno del content type i campi opportuni e verranno inseriti i parametri di mappaggio all’interno delle tabelle “remotecck_cck_created” e“remotecck_mapping”.
L’operazione di inserimento di un aggregatore all’interno di un content type viene eseguita cosi come mostrata nell’immagine seguente:
Figura 40: Inserimento di un template di aggregatore all'interno di un content type
Occorre quindi recarsi nel menù di amministrazione del content type interessato, selezionare un template dalla lista e semplicemente salvare tramite il pulsante “Save content type”.
Questa operazione di salvataggio, oltre a apportare tutte le modifiche, crea all’interno del content type tutti i campi necessari per svolgere l’operazione.
5.6.2 La creazione di un template di aggregatore
In questo paragrafo verrà presentato l’interfaccia grafica che permette la creazione di un template di aggregatore.
Lo storyboard associato alla creazione di un template è il seguente:
Recandosi nel menu associato l’interfaccia grafica trovata è la seguente:
Figura 42: Form di template di aggregatore
Inizialmente occorre stabilire il nome del template di aggregatore e la funzione da utilizzare per l’aggregazione.
Per questo è stato implemento due modalità di ricerca:
1. tramite url del web service 2. tramite nome dell’operazione
Usando la prima modalità occorre selezione dal l’url del web service, ed automaticamente compariranno le operazioni ad esso connesse.
Come mostrato in figura sottostante dove il rettangolo rosso indica il web service selezionato, mentre quello verde le operazioni trovate:
Figura 43: Ricerca tramite Web Service
La seconda modalità di ricerca si basa sul trovare le operazioni che hanno un nome che inizia per il nome indicato nella textfield “Operation to Search”, vedi immagine sottostante:
Figura 44: Ricerca tramite nome dell'operazione
In entrambi i casi per inserire realmente le operazioni trovate tra quelle da utilizzare per l’aggregazione, occorre andare a cliccare il checkbox, nella colonna “Add Operation”, associato all’operazione desiderata.
Questo comporta l’inserimento dell’operazione scelta all’interno della tabella sottostante “Operation to insert into Aggregator” e delineato dal rettangolo rosso nell’immagione sotto:
Figura 45: Tabella delle operazioni inserite
In seguito alla pressione del bottone “Continue” si passa nella seconda pagine di impostazione di template di aggregatore, in quanto viene richiesto il mappaggio dell’aggregatore.
Occorre una doverosa precisazione, infatti un template di aggregatore deve avere un nome univoco all’interno del sistema, se ciò non è vero, ossia esiste un altro aggregatore con lo stesso nome, il modulo si occuperà di informare l’utente con un messaggio d’errore e richiedendo il cambiamento del nome, il messaggio è il seguente:
Figura 46: Duplicazione del nome di aggregazione
Inoltre un template di aggregatore ha senso proprio solo nel caso si abbiano almeno 2due operazione associati.
Se questa condizione non viene rispettata, ossia si cerca di aggregare un numero di operazione inferiore a due, il software ritorna il seguente errore:
Figura 47: Errore di minimo inserimento operazioni
Da notare che il mappaggio preso in considerazione ha lo stesso significato del mappaggio manuale nel caso di campi di richiesta, mentre in quelli di risposta permette di definire quali operazioni devono concorrere la il valore aggregato che sarà restituito.
Figura 48: Seconda fase della creazione di template di aggregazione
L’immagine sopra indica che il campo field_spesa avrà come risultato il valore dell’aggregazione dei due parametri di spesa sulla destra. Da notare che, essendo questa solo un template di aggregazione, i nomi dei campi vengono creati a partire dai nome dei parametri delle operazione, ed inoltre non viene fatto alcun controllo di univocità dei nomi
(che verrà fatto all’atto di inserimento di un template di aggregatore all’interno di un content type). Infine, in seguito al salvataggio del nuovo template di aggregatore, il sistema darà il seguente messaggio:
Figura 49: Massaggio di avvenuta creazione
Il salvataggio del nuovo template di aggregatore avviene tramite la scrittura nella tabella “remotecck_aggregator_name” del nome e della funzione di aggregazione scelta.
Il mappaggio viene salvato all’interno della tabella “remotecck_aggregator_mapping” contente l’id del aggregatore, l’id del parametro e quello che è stato chiamato “aggregator_index” (indice di aggregazione).
Ogni “aggregator_index” indica una riga a cui possono essere connessi uno o più parametri rendendo possibile il corretto mappaggio in seguito all’inserimento in un content type.
Infatti l’inserimento di un template all’interno di un aggregatore si compone delle seguenti fasi:
1. creazione dei campi all’interno del content type
2. aggiunta all’interno della tabella remotecck_aggregator_mapping_content_type di una riga contenente l’id dell’aggregatore ed il nome del content type
3. inserimento del mappaggio all’interno delle tabelle remotecck_ccl_created e
remotecck_mapping (cosi come visto nella creazione di un content type).
5.7 Gestione di operazioni ed aggregatori
Fin ora sono stati trattati tutti i menu che permetto l’inserimento di web service, la creazione di mapping tra content type ed operazione e gli aggregatori.
In questo paragrafo verranno introdotte le funzioni di rimozione di un operazione da un content type e la gestione dei template di aggregazione.
Lo storyboard associato alla cancellazione di un’operazione è la seguente:
Figura 50: Gestione operazione
Per eliminare la connessione tra operazione e content type è stato inserito la seguente funzione:
In seguito alla selezione del content type, dovrà essere selezionato l’operazione (riquadro rosso) ed infine cliccare sul puntante “Delete Operation”.
Figura 52: Selezione delle operazioni del content type
Successivamente il modulo notificherà l’avvenuto cancellamento del mappaggio tra content type ed operazione:
Figura 53: Messaggio di avvenuta cancellazione
Un discorso diverso va contemplato per la gestione di template di aggregatori, infatti è stato sviluppato un menu che permette la visualizzazione dinamica, tramite tecnologia AJAX, lo storyboard associato è il seguente:
La schermata realizzata è la seguente:
Figura 55: Gestione dei template degli aggregatori
Inseguito alla scelta di un template di aggregatore dalla lista, verrà visualizzato la tabella corrispondente alla funzione utilizzata (riquadro in verde):
Figura 56: Visualizzazione di un template
Ovviamente in seguito alla pressione del bottone “Delete Aggregatore Template” (riquadro rosso) verrà cancellato il template stesso e verrà visualizzata la seguente schermata:
5.8 Richiesta di informazioni remote
Fin ora è stata descritta tutta la parti di amministrazione del modulo RemoteCCK, un questo paragrafo verrà descritta la parte utente.
Esse viene automaticamente creata andando a modificare il menu di creazione di nuovi contenuti di Drupal.
Questo menu permette la creazione di diversi tipi di contenuti, se ad un tipo “CodiceFiscale” viene connesso ad un operazione, nella pagina di creazione del contenuto verranno introdotte le funzioni richieste per effettuare l’invocazione dell’operazione.
La schermata visualizzata è la seguente:
Figura 58: Richiesta di codice fiscale
I campi che verranno usati per l’invocazione dell’operazione sono quelli del riquadro rosso ed il risultato verrà inserito nei campi contenuti nel riquadro blu.
L’invocazione dell’operazione avviene tramite la pressione del bottone “MAKE CALL” che si occupa:
1. prendere i dati dei campi del riquadro rosso 2. invocare l’operazione
3. inserire i risultati all’interno dei campi ne riquadro blu
Ovviamente è possibile avere più campi di risposta come nella seguente schermata che simula una richiesta di informazioni da un’anagrafica dove dalla matricola vengono recuperate le informazioni dell’individuo:
Medesimo discorso vale per l’utilizzo dei template di aggregatori infatti in questo caso nei campi d’uscita si avrà il risultato dell’operazione di aggregazione.
Di seguito un esempio di aggregatore:
Figura 60: Richiesta di aggregazione dati
La logica di funzionamento è del tutto simile a quella dell’esempio precedente, l’unica differenza è che il bottone che viene aggiunto al content type si chiama “MAKE AGGREGATION”.
Ovviamente le operazioni appena descritte vengono realizzate tramite un opportuna richiesta asincrona javascript che va ad invocare una callback di Drupal che svolge la funzione di invocazione del web service.
Più nello specifico la funzione javascript si occupa di prelevare i dati inseriti nel content type, dell’invocazione del web service e della scrittura delle informazioni ricevute.
In particolare i dati ricevuti saranno inseriti nel caso di richiesta di operazione, mentre saranno usati la realizzazione della funzione della funzione di aggregazione nel caso di presenza di una connessione con un template di aggregatori.
Per quanto riguarda l’inserimento dei pulsanti all’interno del content type, occorre specificare che Drupal possiede particolari funzione (hook) che si agganciano ai vari eventi.
Per effettuare l’inserimento dei pulsanti di aggregazione e di richiesta di informazione viene usata l’hook_form_alter. Questo infatti permette di accedere ad un generica pagina durante la sua visualizzazione e di modificare la pagina inserendo e modificando la visualizzazione della pagina stessa.
