Episodio 1 – fondamenti del browser

I browser sono posizionati tra i software più complessi che esistono proprio per la loro estrema flessibilità nell’interpretazione e nella visualizzazione dei documenti ma al contrario di quanto si possa pensare la loro struttura di funzionamento a livello globale è molto semplice.

Quindi in questo articolo cercheremo di spiegare come funzionano ma prima cerchiamo di dare alcuni fondamenti base di programmazione.

Programmazione tradizionale ed a oggetti

La programmazione tradizionale è composta da una serie di procedure (blocchi di codice) che tramite istruzioni condizionali o ricorsive trattano una serie di dati con degli specifici tipi.

Questi tipi nei linguaggi orientati ad oggetti sono realmente degli oggetti con delle specifiche ben precise.

Ma cosa sono gli oggetti?

Gli oggetti in programmazione sono in realtà degli oggetti astratti quasi completamente indipendenti dal sistema. In pratica si scrive una classe che non è nient’altro che il modello dell’oggetto, in questa si inseriscono una serie di proprietà che l’oggetto deve possedere e che non sono in genere visibili al di fuori dell’oggetto, poi si inserisce un costruttore che è una funzione che viene chiamata alla creazione di un nuovo oggetto, ed infine si inseriscono i vari metodi che sono una serie di funzioni che servono a trattare le proprietà interne dell’oggetto.

Per esempio una classe nei linguaggi ECMAScript 4 compatibili potrebbe essere scritto così:

class cPersona extends object
{
private var nome:cNome;
private var cognome:cCognome;
//classe costruttore
public function cPersona(var tNome:cNome, var tCognome:cCognome){
this.nome = tNome;
this.cognome = tCognome;
}
public function datiAnagrafici(){ return (this.nome.toString()+” ”+this.cognome.toString()) }
}

Notiamo innanzitutto che le proprietà interne non sono altro che variabili di un certo tipo raggiungibili con this.nomeproprietà, inoltre che le stesse vengono inizializzate durante la funzione costruttore tramite due variabili richieste al momento della creazione dell’oggetto che potrebbe avvenire così:

var primapersona:cPersona = new cPersona(“Luca”, “Mascaro”);

Al momento che un oggetto viene creato vive di vita propria ed è regolamentato dalle regole inserite al suo interno.

Questo tipo di programmazzione risulta molto efficente perchè permette al sistema di mantenere separati ed indipendenti tutti i suoi moduli che si occupano di gestire le operazioni a loro assegnate.

Nel paradigma ad oggetti vi è un ulteriore macropeculiarità che è la possibilità di estendere una classe sulla base di un altra classe ereditandone tutte le proprietà ed i metodi e permettendo così un ulteriore flessibilità. Inoltre in un sistema orientato agli oggetti tutti le classi e gli oggetti sono dei tipi di dati e tutte derivano dalla classe principale Object.

L’HTML come un linguaggio modellato ad oggetti

L’HTML come sappiamo non è un vero linguaggio di programmazione ma solo di marcatura, ma le sue strutture dati essendo derivate dall’SGML sono molto simili a quelle del paradigma ad oggetti. In pratica ogni nodo di HTML descrive un reale oggetto di programmazione con un tipo che è il nome del tag, delle proprietà dell’oggetto che corrispondono alle proprietà dell’html e dei metodi che sono il funzionamento dello stesso.

Infatti dall’introduzione di javascript questa modellizzazione è stata introdotta anche all’interno dei browser a varie fasi nella lunga storia dei browser (per maggiori informazioni consiglio la lettura del capitolo riguardante i linguaggi dinamici del libro “accessibilità: dalla teoria alla realtà  ”) fino ad arrivare alla standardizzazione del modello introdotta dal W3C con il DOM (Modello ad Oggetti per Documenti) per i linguaggi modellati ad oggetti (sulla base di XML).

In pratica all’interno del browser si è creato un oggetto esteso da “object” che modelli un nodo generico HTML ed è stato chiamato “HTMLobject” da questo oggetto sono poi stati derivati un infinità di altri oggetti che descrivessero tutte le marcature di HTML.

Per esempio se analizziamo via javascript e interfaccia DOM (vedi dopo) l’elemento “body” di una pagina scopriamo che “body” corrisponde al tipo “HTMLBodyElement” e che possiede un infinità di proprietà e metodi. Per vederlo direttamente potete testare i due seguenti codici direttamente nella barra del browser su una qualsiasi pagina HTML:

javascript: alert(document.getElementsByTagName('body').item(0))
javascript: var info; for(var i in document.getElementsByTagName('body').item(0)){ info+=(i+"\n") } alert(info);

Quindi possiamo vedere l’HTML come un insieme di oggetti tipizzati e annidiati tra loro che formano il cosidetto albero DOM, ma il DOM non si ferma solo li, infatti il modello DOM comprende anche tutta una serie di metodi che fungono da interfaccia di trattamento e che ci permette di trattare i dati e le strutture.

A questo punto potremmo dunque pensare che con il modello DOM abbiamo l’interfaccia che usa il browser per trattare l’HTML ma in realtà le interfacce sono due e corrispondono anche alle due interfaccie standard per XML, il DOM e il SAX (Simple API for XML), scopriamole insieme.

Le interfacce di trattamento

Il DOM è il SAX sono entrambe interfacce create originariamente per trattare dati XML e lo fanno con due metodologie completamente opposte.

DOM si crea un albero di tutti i nodi in un area di memoria e poi ogni oggetto mette a disposizione una serie di metodi per la ricerca e la navigazione tra i vari nodi e le proprieta.

Mette inoltre a disposizione dei metodi che permettono l’inserimento, la modifica, la copia e l’eliminazione di qualunque metodo o proprietà. Per queste peculiarità DOM è molto potente nel trattamento dei dati in real time durante qualunque fase d’esecuzione e secondo una logica di trova l’oggetto, puntalo e poi modificalo il che è esattamente quello che si farebbe in un sistema orientato agli oggetti. Il punto debole di questo sistema però è che più è grande il numero di nodi più è grande la memoria occupata e quindi più è lento il sistema. Questo principio vale anche per i browser dato che, come abbiamo visto e vedremo più in dettaglio, usano DOM per il trattamento dei dati HTML.

Il SAX è invece molto più elegante, infatti si tratta di un principio che usa la memoria al contrario, in pratica si memorizzano in memoria delle sequenze pattern associate a delle istruzioni, e si fa scorrere l’albero dom nodo per nodo senza doverlo caricare in memoria. Se il pattern dei nodi corrisponde le istruzioni vengono eseguite sul nodo selezionato e poi si va avanti. Questo sistema permette di non caricare mai la memoria eccessivamente ma ha la limitazione di non poter essere usato in real time, quindi per ogni operazione bisogna farsi ripassare l’intero documento ed infatti SAX è stato pensato per quei linguaggi di trasformazione come XSL o CSS.

Ora che abbiamo diversi fondamenti di programmazione diamo un occhiata generale al funzionamento dei browser.

Come funziona un browser?

Il funzionamento di un browser è paragonabile ad una catena di montaggio, infatti è composto da tante piccole parti indipendenti che in sequenza trattano i dati. Questa sequenza è quasi identica in tutti i browser e si svolge tramite i seguenti passaggi:

  1. Caricamento dati: il browser carica un documento HTML come fosse normale testo in un oggetto in memoria.
  2. Parsing e correzzione errori: il browser si legge tutte le istruzioni contenute nel testo le corregge e le trasforma in oggetti DOM specifici con impostazioni di default.
  3. Rendering: il browser renderizza e visualizza la struttura dati con gli attributi di default dati dall’albero DOM (il rendering continuerà perennemente da qui in avanti)
  4. Trasformazione: il browser interpreta ed esegue i documenti di trasformazione e modifica l’albero DOM
  5. Dinamismo: il browser carica in memoria le strutture dati supplementari date dai linguaggi dinamici e di scripting eseguendone le istruzioni
  6. Uso: il browser visualizza le strutture secondo le regole fissate nell’albero DOM e in caso di dinamicismo esegue le operazioni associate agli eventi
  7. Distruzione: al termine della consultazione del documento la memoria viene svuotata ed è pronta ad ospitare nuove strutture dati

In tutto questo percorso vi è una serie infinita di operazioni e caricamenti paralleli che vengono chiamati e che assieme ad un analisi estesa del funzionamento dei browser verrà esposta dettagliatamente nei prossimi articoli.

Potrebbero interessarti anche i seguenti articoli

  • Episodio 3 – l’azione del BrowserEpisodio 3 – l’azione del Browser Nel precedente articolo eravamo rimasti al punto di avere il nostro documento html caricato e la sua struttura DOM istanziata ed in attesa delle varie fasi di […]
  • La triologia del browserLa triologia del browser I linguaggi di marcatura e le relative marcature sono oramai conosciuti in tutti i possibili usi e combinazioni e anche lo sviluppatore alle prime armi con HTML, XHTML, […]
  • Episodio 2 – la preparazione del browserEpisodio 2 – la preparazione del browser Nel precedente articolo abbiamo visto alcune tecniche base di programmazione e sopprattutto la sequenza di operazioni che il browser effettua quando carica un […]
  • Finanziamenti per l’editoria? Ricordiamoci degli obblighi di accessibilità!Finanziamenti per l’editoria? Ricordiamoci degli obblighi di accessibilità! La legge 4/2004 così come aggiornata dal decreto crescita 2.0 prevede che chiunque beneficia di fondi pubblici per lo sviluppo di siti Web deve crearli accessibili a […]
  • Il colore come informazioneIl colore come informazione I problemi legati alla percezione del colore sono più diffusi di quanto si pensi ed hanno cause ed effetti diversi: si pensi che addirittura una persona su dodici […]
Condividi:

Informazioni sull'autore

Luca Mascaro
Luca Mascaro
Luca Mascaro è uno User Experience Architect che si occupa da anni della progettazione di interfacce utente e dell'esperienza utente su piattaforme software web e multimediali. Dirige la SketchIn, un azienda che si occupa di progettazione e consulenza strategica sulla user experience ed è CTO di una software house, la Phiware Engineering. Attualmente fa parte di diversi associazioni internazionali tra cui l'IWA/HWG, l'ACM, l'UPA e l'IOSHI di cui è presidente. Partecipa a gruppi di lavoro del W3C (HTML, WCAG, Web Application e Device Indipendence) e dell'ISO (Software Ergonomics) in ambito di interazione e interfacce.

Commenti

Nessun commento

    Rispondi

    Link e informazioni