Utente:Salvatore Ingala/MISIM

Questa pagina provvisoria contiene degli appunti per un progetto futuro per MediaWiki in JavaScript; nome provvisorio: MISIM.

Esso nasce con lo scopo di ripensare l'architettura dell'attuale Monobook Standard, ma tenta nel contempo di allargare gli orizzonti.

Il nome

MISIM Is a Scripting Infrastructure for Mediawiki

Che figata l'acronimo ricorsivo palindromo, eh? :-)

Il concetto

MISIM non è un tool che aggiunge funzionalità a MediaWiki. Come dice il nome, MISIM vuole fornire un infrastruttura standardizzata e dei servizi per chi scrive gli script da un lato, e per chi li utilizza dall'altro. L'obiettivo è fare in modo che i primi possano scrivere codice robusto e pulito concentrandosi sul problema, e i secondi possano installare e personalizzare i propri script in maniera semplice e senza il bisogno di intervenire direttamente sul codice.

Obiettivi

• Modularizzazione. Gli script saranno organizzati in moduli, unità logiche di codice JavaScript, che possono anche avere delle dependencies. I moduli seguono una struttura standard per interfacciarsi a MISIM.
  • Sebbene non sia probabilmente il caso di programmare in OOP (difficilmente servirà l'ereditarietà o altri meccanismi specifici dell'OOP), è certamente il caso di ragionare per oggetti e di seguire convenzioni uniformi in tutti i moduli.
• Configurabilità semplice. L'aggiunta di moduli e la loro configurazione viene gestita dall'infrastruttura. I moduli devono essere organizzati in modo da contenere solo il codice e i dati statici, ma preferibilmente non la configurazione, che converrà gestire in maniera unificata dal core di MISIM (come? si vedrà.)
• Repositories per le risorse a disposizione dei moduli. Un repository è un contenitore di risorse di uno (o più?) tipi, da cui i moduli possono attingere per la configurazione (ad esempio, i link standard per i portlet; i pulsanti per la toolbar; e simili). I repository non vengono inclusi dall'utente nel suo monobook ma vengono letti in automatico da MISIM durante la configurazione, in modo che solo le risorse effettivamente utilizzate vengano caricate dal browser; inoltre ciò consentirà agli utenti di creare risorse non presenti nei repositories. Tutte le risorse (come pure i moduli) sono univocamente identificabili e tengono traccia dell'ultima modifica, in modo da rendere possibile distinguere in automatico la versione.
• Dinamicità: qualora un modulo lo supporti, può essere caricato in qualunque momento (anche dopo il completamento del caricamento della pagina e di eventuali altri moduli) o rimosso prima della chiusura della pagina.
• AJAX. È il futuro, dobbiamo... tenerlo presente.
• Efficienza
• Supporto per applicazioni complesse (rigorosamente caricate a runtime), eventualmente anche con GUI avanzate.

Interfaccia

Il core di MISIM

Il core di MISIM è la parte di codice fondamentale che consente di eseguire tutto il resto. Essa deve rimanere snella, dal momento che non è accessoria. I suoi compiti sono:

• Fornire funzioni di base molto comuni
  • Utilità generale (come la funzione $() come alias di document.getElementById()).
  • Supporto AJAX (ed eventualmente API di MediaWiki).
  • Identificazione Browser (necessario? Se è molto piccolo magari si può mettere, sennò cassare.)
• Gestire il caricamento (nonché l'eventuale eliminazione a runtime) dei moduli, sia statico (e quindi al caricamento della pagina), sia dinamico (in qualunque altro momento).
• Interfaccia con gli accessori di MISIM (come la gestione della configurazione).
• Varie ed eventuali.

Gli accessori

Gli accessori sono moduli di MISIM che non necessitano di essere onnipresenti nella memoria del browser e vengono caricati a runtime tramite AJAX. Tra questi vi sono il gestore della configurazione, l'editor di risorse, etc.

Poiché questi strumenti sono esterni al core di MISIM, non vi sono particolari esigenze sulla loro dimensione, per cui sono possibili anche moduli molto complessi senza che ciò influisca sulle prestazioni generali di MISIM.

I moduli

Un modulo è un oggetto che potrebbe contenere i seguenti membri pubblici:

{
	"name": "toolboxlinks", //nome del modulo
	"guid": = "0123456789ABCDEF0123456789ABCDEF", //firma univoca (GUID)
	"timestamp": "20070817234200", //timestamp nel formato yyyymmddhhmmss
	"dependencies": ["base", "other:20060613234200"], //un array di stringhe del tipo "name" 
	                                                  //[oppure "name:timestamp" (per richiedere una versione minima di un modulo - necessario?)]
	"postponable": true/false, //il modulo può essere caricato in qualunque momento?
	"unloadable": true/false, //il modulo può essere rimosso a run-time annullando tutte le sue modifiche?
	"load": function(){}, //è l'effettivo caricamento del modulo, applicando le modifiche alla pagina;
	                      //per i moduli postponable può essere chiamato in qualunque momento, per le altre
	                      //è chiamato necessariamente al caricamento della pagina (addOnloadHook);
	"unload": function(){} //per le funzioni unloadable, annulla le modifiche alla pagina
}

I repositories (possibile struttura)

Un repository è una collezione (array) di uno o più scaffali (shelves) contenenti risorse (resources) omogenee.

I repository non sono acceduti manualmente dagli utilizzatori (e, a patto di avere strumenti adeguati, neanche dai creatori). La struttura è molto schematica e adatta alla manipolazione informatica; obiettivo fondamentale è che la lettura sia immediata, deve cioè bastare un semplice "eval(<codice del repository>)" per ottenere un oggetto identico al repository rappresentato. Il codice per la scrittura del repository può essere mantenuto esterno al core di MISIM e caricato a runtime, all'occorrenza.

{
	name:"nome deposito",
	guid:"983509285AAFEE...",
	timestamp:"yyyymmddhhmmss" //ultima modifica
	shelves: [
		{
                        name:"nome scaffale",
			description:"Breve descrizione del contenuto dello scaffale",
			manifest:{
				campo1: {
					type:"tipo",
					default:<valore di default>,
					isValid:function(data){...}; //validazione del singolo campo (facoltativo)
				}
				campo2: ...
				...
				isValid:function(res){...}; //validazione dell'intera risorsa (facoltativo)
			}
			resources:[
				{
					guid:"...",
					timestamp:"yyyymmddhhmmss",
					//membri propri della risorsa
				},
				{
					//altra risorsa
				},
				{
					//altra risorsa
				}
			]
		},
		{
			//altro scaffale
		}
	]
}

Una risorsa contiene guid, timestamp e i membri propri della risorsa. Ad esempio un link potrebbe essere così:

{
	guid:"26735F1BA023625653DAC2644C01BFC9",
	timestamp:"20070822011723",
	description:"Bar",
	url:"http://it.wikipedia.org/wiki/Wikipedia:Bar"
}

Il guid serve ad identificare univocamente la risorsa, il timestamp a consentire gli aggiornamenti della risorsa e fare in modo che i client possano capire se è necessario sincronizzare la propria copia della risorsa.

Esempio di repository

Ecco come potrebbe essere un repository:

{
	name:"weblinks",
	guid:"7A16BBCEF511FF90571164AE4EA45E88",
	timestamp:"20070824140600",
	shelves: [
		{
			name:"links",
			description:"Web links",
			manifest:{
				url: {
					type:"url",
					default:null
				},
				title: {
					type:"string",
					default:null
				}
			},
			resources:[
				{
					guid:"6BDAD173EF1C96917D37C81D4F052DD5",
					timestamp:"20070824140600",
					url:"www.google.com",
					title:"Google"
				},
				{
					guid:"330E32A13F1ECF3EA668820F4989D037",
					timestamp:"20070824140600",
					url:"it.wikipedia.org",
					title:"Wikipedia in italiano"
				}
			]
		}
	]
}

Appendice

GUID

Un GUID serve ad identificare in modo unico una risorsa/oggetto. Rispetto ai GUID propriamente detti, qui ci possiamo accontentare di un banale numero a 128 bit (stringa di 32 cifre esadecimali). Come generarlo? La scelta più semplice è generarlo casualmente: la probabilità di collisioni è talmente infima da essere trascurabile (specie considerato che le conseguenze non potrebbero essere gravi). Altrimenti si può generare in parte in base a data e ora.