Oggetti semantici

La programmazione orientata agli oggetti (OOP), a volte chiamata semplicemente programmazione ad oggetti, è un paradigma di programmazione che permette di definire oggetti software in grado di interagire gli uni con gli altri attraverso lo scambio di messaggi.

Questo approccio è particolarmente adatto nei contesti in cui si possono definire relazioni di interdipendenza tra i concetti da modellare. Alcuni vantaggi della programmazione orientata agli oggetti includono:

Modellazione software degli oggetti: La OOP fornisce un supporto naturale alla modellazione degli oggetti del mondo reale o di modelli astratti da riprodurre.
Gestione e manutenzione semplificate: Permette una più facile gestione e manutenzione di progetti di grandi dimensioni.
Modularità e riuso del codice: L’organizzazione del codice sotto forma di classi favorisce la modularità e il riuso di codice.

I principali concetti della programmazione orientata agli oggetti includono:

Classi: Le classi definiscono i tipi di oggetti e specificano le proprietà e i metodi che gli oggetti di quella classe possono avere.
Oggetti: Gli oggetti sono istanze di classi e rappresentano entità specifiche con attributi e comportamenti.
Incapsulamento: L’incapsulamento implica l’occultamento dei dettagli di implementazione all’esterno dell’oggetto.
Ereditarietà: Consente di creare nuove classi basate su classi esistenti, ereditando le loro proprietà e metodi.
Polimorfismo: Il polimorfismo consente a oggetti di classi diverse di rispondere allo stesso messaggio in modo diverso.

In sintesi, la programmazione orientata agli oggetti offre un approccio strutturato per creare software basato su oggetti che interagiscono tra loro, facilitando la creazione di applicazioni complesse e mantenibili

In breve, HTML e CSS non sono linguaggi di programmazione ad oggetti, ma puoi utilizzare JavaScript per interagire con gli elementi HTML e applicare stili dinamici. Se hai bisogno di funzionalità più avanzate, potresti voler esaminare framework come React o Vue.js, che consentono di creare componenti riutilizzabili e applicare la programmazione ad oggetti in modo più diretto

Si può utilizzare funzioni PHP all’interno di un contesto di programmazione orientata agli oggetti (OOP). In effetti, PHP offre un supporto completo per la programmazione orientata agli oggetti, consentendoti di creare classi, definire metodi e utilizzare funzioni all’interno di tali classi.

Ecco alcune considerazioni:

Metodi di classe: In PHP, i metodi di classe sono essenzialmente funzioni che appartengono a una specifica classe. Puoi definire metodi all’interno di una classe per eseguire operazioni specifiche su oggetti di quella classe.
Utilizzo di funzioni: Puoi richiamare funzioni PHP all’interno dei metodi di una classe. Ad esempio, se hai una classe Car con un metodo startEngine(), all’interno di quel metodo puoi chiamare funzioni PHP per avviare l’engine della macchina.
Funzioni esterne: Anche al di fuori delle classi, puoi utilizzare funzioni PHP come parte del tuo programma orientato agli oggetti. Ad esempio, puoi avere una funzione esterna che calcola il prezzo totale di una serie di oggetti e richiamarla all’interno dei metodi di una classe ShoppingCart.

Ecco un esempio di come potresti utilizzare una funzione PHP all’interno di un metodo di classe:

class Car {
    private $make;
    private $model;

    public function __construct($make, $model) {
        $this->make = $make;
        $this->model = $model;
    }

    public function startEngine() {
        // Esegui alcune operazioni specifiche per avviare l'engine
        // ...
        // Chiamata a una funzione esterna per controllare il livello di carburante
        $fuelLevel = getFuelLevel(); // Richiama la funzione esterna
        if ($fuelLevel > 0) {
            echo "Engine started!";
        } else {
            echo "Out of fuel. Please refuel.";
        }
    }
}

// Funzione esterna per ottenere il livello di carburante
function getFuelLevel() {
    // Simulazione: restituisci un valore casuale tra 0 e 100
    return rand(0, 100);
}

// Creazione di un'istanza della classe Car
$myCar = new Car("Toyota", "Camry");
$myCar->startEngine();

In questo esempio, la funzione getFuelLevel() viene richiamata all’interno del metodo startEngine() della classe Car. Questo è solo un esempio, ma dimostra come le funzioni PHP possano essere integrate in un contesto di programmazione orientata agli oggetti.

La programmazione orientata agli oggetti non si limita alle classi e ai metodi, ma coinvolge anche concetti come l’incapsulamento, l’ereditarietà e il polimorfismo. Occorre esplorare ulteriormente questi concetti per sfruttare al meglio la potenza della OOP in PHP.

A causa di queste operazioni, l’invocazione di una funzione comporta un costo, seppur normalmente modesto, in termini di prestazioni.

In informatica è possibile quindi adottare uno standard che può a sua volta essere definito e programmato come un oggetto.

In parole molto semplici, potremmo dire che le azioni altro non sono che “le cose che un oggetto è in grado di fare” mentre le sue caratteristiche rappresentano i dati che le azioni stesse possono utilizzare per eseguire le operazioni che da esse ci si aspetta.

In OOP, le caratteristiche di un oggetto vengono denominate proprietà e le azioni sono dette metodi. Questi sono due concetti fondamentali ed è molto importante che siano ben chiari prima di introdurre nuove definizioni.

Altrettanto importante, però, è ribadire il contesto in cui abbiamo iniziato a ragionare: non dobbiamo pensare più ad un programma che racchiuda tutto in un unico grande calderone ma dobbiamo iniziare a pensare “ad oggetti”. Dobbiamo, cioè, essere in grado di identificare gli oggetti che entrano in gioco nel programma che vogliamo sviluppare e saperne gestire l’interazione degli uni con gli altri.

In un programma di tipo procedurale, si è soliti iniziare a ragionare in maniera top-down, partendo cioè dal main e creando mano a mano tutte le procedure necessarie. Tutto questo non ha più senso nella programmazione ad oggetti, dove serve invece definire prima le classi e poi associare ad esse le proprietà ed i metodi opportuni.

All’interno ad esempio di un portale web i div, nella loro accezione di sezioni, diventano parti fondamentale della struttura, servizi indipendenti e spesso prvenienti da server dislocati che necessitano di essere assemblati a contesti più ampi.

Attualmmente abbiamo la facoltà di accedere a un div di una pagina HTML tramite un sistema di login. Tuttavia, è importante comprendere che il login è un meccanismo di autenticazione che verifica l’identità dell’utente e concede l’accesso a determinate risorse o funzionalità. Il div in sé non è direttamente coinvolto nel processo di login, ma può essere reso visibile o nascosto in base allo stato di autenticazione.

Ecco come è possibile farlo:

Creazione del form di login: Innanzitutto, crea un form di login con campi per l’username e la password. Questo form dovrebbe inviare i dati a un server (ad esempio, tramite PHP) per la verifica delle credenziali.
Verifica delle credenziali: Sul server, verifica le credenziali inserite dall’utente. Se l’utente è autenticato con successo, puoi impostare una variabile di sessione o un cookie per segnalare che l’utente è loggato.
Accesso al div: Nel tuo codice HTML, puoi utilizzare condizioni per mostrare o nascondere il div in base allo stato di autenticazione. Ad esempio:

<!DOCTYPE html>
<html>
<head>
    <title>Accesso al Div</title>
</head>
<body>
    <?php
    // Verifica se l'utente è autenticato
    $isAuthenticated = true; // Esempio: dovresti verificare le credenziali qui

    if ($isAuthenticated) {
        // Mostra il div solo se l'utente è autenticato
        echo '<div id="myDiv">Contenuto del div visibile dopo il login</div>';
    }
    ?>
</body>
</html>

In questo esempio, il div con l’id “myDiv” verrà visualizzato solo se l’utente è autenticato. Puoi personalizzare ulteriormente questa logica in base alle tue esigenze specifiche.

La sicurezza è fondamentale quando si tratta di autenticazione e accesso a risorse. Assicurati di utilizzare pratiche di sicurezza adeguate, come l’hashing delle password e la protezione contro gli attacchi di forza bruta.

I metodi sono le azioni che un oggetto è in grado di compiere

Come detto, un metodo rappresenta una azione che può essere compiuta da un oggetto. Una delle domande principali da porsi quando si vuole creare un oggetto è: “Cosa si vuole che sia in grado di fare?”.

In effetti, quando ci si pone questa domanda, si sta involontariamente dando per buono il fatto che qualsiasi oggetto sia in qualche modo capace di eseguire delle azioni, trattandolo come se avesse natura umana. Eppure, anche se inizialmente può apparire quantomeno curioso e insolito, questo approccio rappresenta un importante riferimento nella fase di disegno e creazione degli oggetti.

In generale, potremmo delineare almeno tre buone regole per identificare i metodi da associare ad un oggetto:

Un oggetto che abbia uno o due soli metodi deve fare riflettere. Potrebbe essere perfettamente lecito definire un oggetto del genere (ed è sicuramente possibile farlo praticamente) ma, spesso, un oggetto creato con questi requisiti indica la necessità di “mescolarlo” con un altro oggetto con simile definizione.
Ancora più da evitare sono gli oggetti con nessun metodo. È bene che un oggetto incapsuli (vedremo meglio in seguito cosa si intenda con tale terminologia) dentro sé sia informazioni (le proprietà), sia azioni (i metodi, appunto). In linea di massima, un oggetto senza metodi può facilmente essere convertito in uno o più attributi da assegnare ad un altro oggetto.
Sicuramente da evitare sono anche gli oggetti con troppi metodi. Un oggetto, in generale, dovrebbe avere un insieme facilmente gestibile di proprie responsabilità. Assegnare ad un oggetto troppe azioni, potrebbe rendere ardua la manutenzione futura dello stesso oggetto. È consigliabile, in questo caso, cercare di spezzare l’oggetto in due oggetti più piccoli e semplificati.

Le proprietà: informazioni su cui opera un oggetto

Le proprietà rappresentano i dati dell’oggetto, ovvero le informazioni su cui i metodi possono eseguire le loro elaborazioni.

Uno degli errori più comuni che si commette quando si definiscono le proprietà di un oggetto è quello di associare ad esso quante più proprietà possibili, ritenendo che questo possa, in qualche modo, facilitare la stesura del programma. Un oggetto, invece, per essere ben definito deve contenere le proprietà che, effettivamente, gli competono e non tutte quelle che gli si potrebbero comunque attribuire.

Questa regola di buona programmazione nasce, oltretutto, dall’esigenza di rendere più facile la fase di disegno e quella di debug che altrimenti risulterebbero certamente complesse.

Per evitare, dunque, l’inconveniente di ritrovarsi dei super-oggetti sarà bene porsi la seguente domanda nella fase di definizione: «quali proprietà sono necessarie affinché l’oggetto sia in grado di eseguire le proprie azioni?»

In generale, esistono tre tipologie di proprietà:

Gli attributi rappresentano quelle proprietà che descrivono le caratteristiche peculiari di un oggetto (ad esempio, riferendoci ad una persona: altezza, peso).
I componenti, invece, sono identificabili in quelle proprietà che sono atte a svolgere delle azioni (testa, corpo, mani, gambe).
Infine, i peer objects definiscono delle proprietà che a loro volta sono identificate e definite in altri oggetti (ad esempio: l’automobile posseduta da una persona).

Esempi di possibili applicazioni sono dati da iPeer, una piattaforma che offre un inventario completo di strumenti e risorse per l’apprendimento assistito da pari. Comprende vari aspetti dell’educazione tra pari, comprese le metodologie pedagogiche, i modelli di competenza e i sistemi di valutazione1. Ecco alcuni componenti chiave:

Metodologia pedagogica: iPeer fornisce un quadro pedagogico per l’implementazione dell’apprendimento assistito da pari. Questa metodologia guida gli educatori nella progettazione di esperienze di apprendimento efficaci che coinvolgono la collaborazione tra pari.

Ampio inventario: la piattaforma offre un ampio inventario di strumenti e risorse digitali. Questi includono strumenti pedagogici all’avanguardia, risorse di tutoraggio e materiali di apprendimento empatico.

Curriculum di apprendimento assistito da pari: iPeer supporta lo sviluppo di programmi di apprendimento assistito da pari. Gli educatori possono esplorare e integrare varie strategie per migliorare il coinvolgimento degli studenti e la condivisione delle conoscenze

Modello di competenza e sistema di valutazione: iPeer incorpora un modello di competenze che delinea le abilità e le competenze necessarie per un apprendimento tra pari di successo. Inoltre, fornisce un sistema di valutazione per valutare l’efficacia degli approcci assistiti da pari.

Probabilmente, il termine più importante e rappresentativo nella Programmazione ad Oggetti è quello di Classe.

Riprendiamo ancora l’esempio del masterizzatore. Sappiamo benissimo che non esiste un solo tipo di masterizzatore ma, a secondo delle caratteristiche, è possibile citarne tanti modelli: ci sono, ad esempio, quelli in grado di scrivere su CD e DVD o quelli che scrivono solo su CD.

Sicuramente, però, tutti sono in grado di eseguire la scrittura di dati o file multimediali su CD e tutti hanno, altresì, le proprietà esposte nelle lezioni precedenti.

Diremo allora che più oggetti software che hanno le stesse proprietà e gli stessi metodi possono essere raggruppati in una classe ben definita di oggetti: nel nostro caso particolare, nella classe masterizzatore.

Dunque, una classe rappresenta, sostanzialmente, una categoria particolare di oggetti e, dal punto di vista della programmazione, è anche possibile affermare che una classe funge da tipo per un determinato oggetto ad essa appartenente (dove con tipo si intende il tipo di dato, come lo sono gli interi o le stringhe).

Diremo, inoltre, che un particolare oggetto che appartiene ad una classe costituisce un’istanza della classe stessa. In altre parole, un’istanza della classe masterizzatore sarà costituita da un oggetto di tale classe che è in grado di scrivere solo su CD mentre un’altra istanza potrà essere rappresentata da un oggetto che è in grado di masterizzare anche i DVD.

È anche possibile creare due o più istanze separate di oggetti uguali (sarebbe meglio dire di oggetti che hanno le proprietà valorizzate allo stesso modo) ma ciò non vorrà dire che in un determinato istante nel corso del programma tutte queste istanze eseguano la medesima operazione o che, in generale, siano necessariamente correlati.

L’univocità di ogni istanza viene definita con il termine di identità (identity): ogni oggetto ha una propria identità ben distinta da quella di tutte le altre possibili istanze della stessa classe a cui appartiene l’oggetto stesso.

Naturalmente, le proprietà di un oggetto possono avere valori che variano nel tempo. Ad esempio, la velocità di scrittura potrebbe essere selezionata dall’utente e, pertanto, potrebbe variare nel corso del programma. Si definisce stato di un oggetto, l’insieme dei valori delle sue proprietà in un determinato istante di tempo. Se cambia anche una sola proprietà di un oggetto, il suo stato varierà di conseguenza.

L’insieme dei metodi che un oggetto è in grado di eseguire viene definito, invece, comportamento (behavior).

Insomma, appare sempre più chiaro come un oggetto rappresenti un’entità a sé stante, ben definita che, nel corso dell’elaborazione, sia soggetta ad una creazione, ad un suo utilizzo e, infine, alla sua distruzione.

Inoltre, un oggetto non dovrebbe mai manipolare direttamente i dati interni (le proprietà) di un altro oggetto ma ogni tipo di comunicazione tra oggetti dovrebbe essere sempre gestita tramite l’uso di messaggi, ovvero tramite le chiamate ai metodi che un oggetto espone all’esterno.

Si è detto che i metodi rappresentano le azioni che un oggetto è in grado di eseguire. Ma, in base a quale criterio vengono scatenate ed eseguite tali azioni? Semplicemente rispondendo alle “sollecitazioni” provenienti da altri oggetti.

Quando, ad esempio, l’oggetto masterizzatore esegue il metodo Scrivi_CD, un altro oggetto (per esempio, il controller) gli avrà precedentemente inviato una simile richiesta sollecitandone l’azione di scrittura.

Tali sollecitazioni costituiscono quelli che, in un programma che utilizza il paradigma OOP, vengono definiti messaggi. Questi ultimi rappresentano il cuore del modello ad oggetti ovvero un insieme di oggetti che eseguono determinate azioni in concomitanza di messaggi e che inviano messaggi a loro volta ad altri oggetti.

Probabilmente tali concetti possono suscitare, inizialmente, un po’ di confusione ma sono più semplici di quanto si possa ritenere. Per fare maggiore chiarezza aggiungiamo che un oggetto può inviare dei messaggi soltanto alle sue proprietà, in particolare a quelle che sono definite a loro volta come oggetti. Si faccia riferimento, a tal proposito, alla definizione di peer object. Quindi, con riferimento al nostro esempio, potremo dire che l’oggetto controller avrà al suo interno una proprietà masterizzatore, alla quale sarà in grado di inviare dei messaggi ogni qual volta si desideri che il masterizzatore compia una delle sue azioni.

Si è soliti suddividere i messaggi nelle seguenti categorie:

Costruttori

I Costruttori costituiscono il momento in cui viene creato un oggetto. Essi devono essere richiamati ognivolta che si vuole creare una nuova istanza di un oggetto appartenente ad una classe e, solitamente, svolgono al loro interno funzioni di inizializzazione.

Distruttori

I Distruttori, come si intuisce facilmente dal nome, svolgono la funzione inversa dei costruttori: distruggono un oggetto (ovvero ne eliminano la allocazione dalla memoria). All’interno di questi metodi viene, solitamente, effettuata anche una sorta di pulizia del codice, rimuovendo eventuali variabili allocate sulla memoria dinamica (heap).

Molti linguaggi orientati agli oggetti (come ad esempio Java e C#) non forniscono un uso diretto dei distruttori ma prevedono una rimozione automatica dell’oggetto quando questo esce dal contesto dell’applicazione (per approfondimenti in merito, si guardi il concetto di Garbage Collector in Java).

Accessori (Accessors)

I messaggi di tipo “Accessors” vengono utilizzati per esaminare il contenuto di una proprietà di una classe. Solitamente si utilizzano questi metodi per accedere alle variabili dichiarate con visibilità Private (vedremo il significato di questo termine nel prossimo paragrafo). Una particolarità: i metodi di tipo selectors (Selettori) eseguono un confronto tra due o più elementi prima di restituire il valore di ritorno.

Modificatori (Mutators)

I Modificatori rappresentano tutti i messaggi che provocano una modifica nello stato di un oggetto.

Ma, in questa area dell’informatica, un ruolo fondamentale e di primaria importanza è sicuramente offerto dal Cloud.

Function-as-a-Service, o FaaS, è un tipo di servizio di cloud computing che consente agli sviluppatori di creare, eseguire e gestire i pacchetti applicativi come funzioni, senza dover mantenere un’infrastruttura propria.

FaaS, è un modello di esecuzione basato su eventi, che viene eseguito in container stateless; le funzioni gestiscono la logica e lo stato sul lato server utilizzando i servizi di un provider FaaS.

Le soluzioni FaaS sono disponibili sui principali cloud pubblici; il provisioning può essere eseguito on premise, garantendo un aumento netto delle capacità ai reparti IT enterprise che si occupano di sviluppo delle app. Scarica la guida alla tua strategia cloud native per implementare un approccio serverless con FaaS.

Alcuni esempi di FaaS molto diffusi sono:

IBM Cloud Functions

Amazon AWS Lambda

Google Cloud Functions

Microsoft Azure Functions (open source)

OpenFaaS (open source)

FaaS offre agli sviluppatori un’astrazione per eseguire le applicazioni web in risposta a eventi, senza gestire i server. Ad esempio, l’upload di un file genera un codice personalizzato che transcodifica il file in diversi formati.

L’infrastruttura FaaS viene in genere misurata on demand dal provider di servizi, principalmente mediante un modello di esecuzione basato su eventi; in questo modo è presente quando necessario, senza tuttavia richiedere l’esecuzione costante dei processi server in background, come accade con il modello platform-as-a-service (PaaS).

Le moderne soluzioni PaaS offrono capacità serverless integrate nei comuni flussi di lavoro utilizzati dagli sviluppatori per distribuire le applicazioni, rendendo meno evidenti i confini tra PaaS e FaaS.

Nella realtà, intere applicazioni sono composte da una combinazione di funzioni, microservizi e servizi a lunga esecuzione.

Scalabilità dinamica con FaaS

Un provider rende la funzione disponibile tramite una interfaccia di programmazione delle applicazioni (API) e gestisce l’allocazione delle risorse. Essendo basate sugli eventi, le funzioni sono facilmente scalabili e la scalabilità consente di ottenere maggiore efficienza e valore aziendale.

Esistono vincoli architettonici per poter sfruttare alcuni di questi vantaggi, ad esempio limiti di tempo per l’esecuzione di una determinata funzione; per questa ragione, una funzione deve poter essere avviata ed eseguita rapidamente.

Le funzioni si avviano in millisecondi ed elaborano le singole richieste. In presenza di numerose richieste simultanee, il sistema crea il numero di copie della funzione necessarie per soddisfare la domanda.

Al diminuire della domanda, l’applicazione procede automaticamente con l’eliminazione delle copie non necessarie. La scalabilità dinamica è un vantaggio del modello FaaS; è anche conveniente, poiché i provider addebitano solo il costo delle risorse utilizzate e non dei tempi morti.

Nell’esecuzione on premise, questa dinamicità può aumentare la densità della piattaforma, consentendo l’esecuzione di più carichi di lavoro e l’ottimizzazione del consumo e della funzionalità delle risorse.

Un servizio basato su eventi che richiede la scalabilità orizzontale può funzionare bene come funzione, così come le applicazioni RESTful.

Il modello FaaS è perfetto per transazioni con volumi elevati e carichi di lavoro con frequenza sporadica come la generazione di report, l’elaborazione di immagini o attività programmate. Esempi di utilizzo comuni sono l’elaborazione dei dati, i servizi IoT e le app mobile o web.

FaaS consente di realizzare un’applicazione totalmente serverless oppure in parte serverless e in parte costituita da componenti di microservizi convenzionali per sfruttare appueno le tecnologie più recenti e sistemi di orchestrazione dei container come Kubernetes.

Scopri le procedure consigliate per la migrazione alle applicazioni containerizzate

I vantaggi di FaaS

Maggiore produttività degli sviluppatori e tempi di sviluppo più rapidi

Nessuna responsabilità per la gestione dei server

Scalabilità facilitata, con estensione orizzontale gestita dalla piattaforma

Vengono addebitate solo le risorse consumate e in base alle esigenze

È possibile scrivere le funzioni utilizzando qualsiasi linguaggio di programmazione

Quali sono le differenze tra FaaS e serverless computing?

Inizialmente, FaaS e serverless indicavano concetti piuttosto simili. Nel tempo, il significato di serverless si è ampliato per includere un insieme più vasto di schemi e pratiche architetturali che utilizzano in modo esteso servizi comuni in aggiunta alla logica di business personalizzata codificata in FaaS.

Il modello serverless può essere utilizzato dai microservizi e dalle app tradizionali, a condizione che questi siano containerizzati e rispettino i requisiti di scalabilità dinamica e gestione dello stato.

Il termine “serverless” viene utilizzato anche per indicare servizi gestiti come database e sistemi di messaggistica, che non prevedono l’intervento di uno sviluppatore o di un amministratore perché sono, appunto, gestiti da un provider cloud o da un’azienda terza.

La combinazione di servizi FaaS e servizi di back-end comuni, come database, messaggistica e autenticazione, connessi principalmente tramite un’architettura basata su eventi, è ciò che consente agli sviluppatori in ambito serverless di ottenere i maggiori vantaggi.

XaaS: Il Modello Anything as a Service

A volte sembra che ci siano troppi acronimi aziendali da ricordare. Con la rapida evoluzione dei progressi tecnologici e l’avvento del cloud computing, nuove categorie continueranno a spuntare. XaaS è una delle ultime aggiunte.

La maggior parte delle persone del settore conosce il SaaS (Software as a Service), lo IaaS (Infrastructure as a Service) e il PaaS (Platform as a Service). Ma avete già sentito parlare di XaaS?

XaaS (Anything as a Service) è un termine onnicomprensivo: ora tutto può essere un servizio.

Sembra un concetto grosso da assimilare, ma non preoccupatevi, vi spiegheremo tutto. In questo articolo vedremo cos’è lo XaaS e passeremo in rassegna i diversi tipi di aziende XaaS.

XaaS sta per Anything as a Service.

Il termine XaaS è entrato in uso dopo che alcune tecnologie e innovazioni sono state inserite in una rete e si sono convertite in prodotti.

XaaS sfrutta il cloud computing invece del software locale in loco per fornire vari servizi e raggiungere i clienti. Vi dà più flessibilità nel gestire il vostro business sui server ospitati in un deposito o in loco.

L’industria XaaS si sta evolvendo e attrarrà su di sé sempre più riflettori nei prossimi anni. Dire che è stato trasformativa per il modo in cui le aziende operano sarebbe un eufemismo.

Sempre più aziende si stanno rivolgendo a XaaS per alimentare e far crescere le loro imprese. Il mercato globale XaaS sta attualmente crescendo a un tasso di crescita annuale composto di circa il 26%, e gli esperti prevedono che questa tendenza continuerà almeno fino al 2025.

Le aziende XaaS usano il cloud computing per fornire i loro servizi a milioni di clienti in tutto il mondo.

I loro prodotti sono tipicamente piattaforme online disponibili in ogni momento per gli utenti che vi accedono. Gli utenti troveranno uno spazio di lavoro facile da usare che spesso è ospitato direttamente nel loro browser.

Dopo aver apportato modifiche o scaricato dati da questo spazio di lavoro, il browser invierà la richiesta alla piattaforma. Tipicamente, la piattaforma viene eseguita su server on-premise, un provider di cloud o una rete basata sul web.

Le aziende XaaS offrono una piattaforma per aiutare il vostro business. (Fonte)

Una piattaforma XaaS vi evita la preoccupazione di costruire un ampio magazzino in loco, servizi web, hardware o software personalizzato. Dipende ovviamente da quale servizio la specifica azienda XaaS sta offrendo.

Invece di costruire tutto in-house, le aziende possono acquistare una licenza di prodotto XaaS per un periodo prolungato e approfittare della sua vasta infrastruttura.

Finché il prodotto XaaS è disponibile, questo modello può essere redditizio.

“Qualsiasi cosa” è però una categoria ampia, che a volte può rendere il concetto di aziende XaaS difficile da afferrare.

Per comprendere appieno le diverse aziende XaaS attualmente sul mercato, diamo un’occhiata a 10 dei più comuni tipi di aziende XaaS esistenti.

Creazione di collegamenti da backend a frontend

Spesso è necessario creare collegamenti dall’applicazione back-end all’applicazione front-end. Poiché l’applicazione frontend può contenere le proprie regole di gestione URL, è necessario duplicarle per l’applicazione back-end denominandola in modo diverso:

return [
    'components' => [
        'urlManager' => [
            // here is your normal backend url manager config
        ],
        'urlManagerFrontend' => [
            'class' => 'yii\web\UrlManager',        // class is required on custom named url managers!
            'hostInfo' => 'https://example.com',    // the full base domain name to use for the links
            // here is your frontend URL manager config
        ],

    ],
];

Il gestore URL non conosce magicamente l’URL radice di un’altra app su un altro sottodominio. Qui è dove il parametro entra. Definisce il dominio completo con cui il gestore URL può generare collegamenti assoluti .hostInfo

Potrebbe essere necessario generare collegamenti al frontend o a qualsiasi altra app (ad esempio: topic-adding-more-apps.md). Puoi avere più gestori URL per più app su più sottodomini.

return [
    'components' => [
        'urlManager' => [
            // here is your normal backend URL manager config
        ],
        'urlManagerFrontend' => [
            'class' => 'yii\web\UrlManager',        // class is required on custom named URL managers!
            'hostInfo' => 'https://example.com',    // the full base domain name to use for the links
            // here is your frontend URL manager config
        ],
        'urlManagerBlog' => [
            'class' => 'yii\web\UrlManager',            // class is required on custom named URL managers!
            'hostInfo' => 'https://blog.example.com',   // the full base domain name to use for the links
            // here is your blog URL manager config
        ],

    ],
];

Al termine, è possibile ottenere un URL che punta al frontend come il seguente:

echo Yii::$app->urlManagerFrontend->createAbsoluteUrl(...);

Quando hai regole personalizzate che devono essere ripetute su più app, devi inserirle nelle loro propri file di “regole”. In questo modo, quando è necessario apportare una modifica, è necessario modificare solo un file.

Nella directory, creare una nuova cartella denominata . Questo ospiterà tutte le regole del tuo gestore URL.common/configrules

Quindi creare un file denominato e un altro denominato .backend-rules.phpfrontend-rules.php

Se la rispettiva app non ha / ha bisogno di regole, basta che il file delle regole restituisca un array vuoto.

<?php
return [];

Ecco un esempio di come appare con alcune regole personalizzate:

<?php
return [
    'aff/<id:\d+>' => 'affiliate/index',
    'lp/<id:\d+>' => 'landing/index',
];
Ora basta includere/richiedere i rispettivi file di regole per i gestori URL corrispondenti:
return [
    // ...
    'components' => [
        'urlManager' => [
            // backend URL manager
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => require Yii::getAlias('@common/config/rules/backend-rules.php'),
        ],
        'urlManagerFrontend' => [
            'class' => 'yii\web\UrlManager',        // class is required on custom named url managers!
            'hostInfo' => 'https://example.com',    // the full base domain name to use for the links
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => require Yii::getAlias('@common/config/rules/frontend-rules.php'),
        ],
        // ...

    ],
    // ...
];
Hardcoded hostInfo URL
Gli esempi di cui sopra servono a illustrare ciò che ci si aspetta sul campo. si aspetta un nome di dominio completo come o . Avere un dominio hardcoded nella tua configurazione non è molto pratico. Soprattutto per la gestione di più ambienti (locale, allestimento, produzione, ecc.).hostInfohttps://example.comhttps://backend.example.com
Ci sono alcuni modi per farlo. Il modo seguente consente di utilizzare gli ambienti di Yii e il processo.init
Per prima cosa dobbiamo caricare le funzioni all'inizio durante il caricamento automatico di Composer.
Nel file aggiungere quanto segue:composer.json
"autoload": {
    "files": [
        "common/functions.php"
    ]
}
Ora crea :common/functions.php
<?php
/**
 * Requires `define('USE_HTTPS', true)` to be in your `index.php` file!
 */
function getUrlScheme()
{
    return (USE_HTTPS === true) ? 'https' : 'http';
}

/**
 * Requires `define('DOMAIN_NAME', 'example.tld')` to be in your `index.php` file!
 */
function getDomain($subDomain = null)
{
    $sub = $subDomain ? $subDomain . '.' : '';
    return getUrlScheme() . '://' . $sub . DOMAIN_NAME;
}
Ora dobbiamo definire le nostre costanti nei file corrispondenti. Ecco i percorsi per gli ambienti predefiniti.web/index.php
environments/dev/backend/web/index.php
environments/dev/frontend/web/index.php
environments/prod/backend/web/index.php
environments/prod/frontend/web/index.php

Nelle copie, useremo il nostro nome di dominio di sviluppo locale (ad esempio: mylocalsite.test) e nelle copie useremo il dominio reale (ad esempio: example.com).devprod

Aggiungi all’inizio dei file indice:

environments/dev/backend/web/index.php
define('USE_HTTPS', true);
define('DOMAIN_NAME', 'mylocalsite.test');
environments/dev/frontend/web/index.php
define('USE_HTTPS', true);
define('DOMAIN_NAME', 'mylocalsite.test');
environments/prod/backend/web/index.php
define('USE_HTTPS', true);
define('DOMAIN_NAME', 'example.com');
environments/prod/frontend/web/index.php
define('USE_HTTPS', true);
define('DOMAIN_NAME', 'example.com');

Eseguire e inizializzare l’ambiente appropriato per sovrascrivere le modifiche../init

Possiamo utilizzare direttamente le funzioni o creare alias. Creiamo alias.

Aggiungere quanto segue in :common/config/bootstrap.php

Yii::setAlias('@frontendDomain', getDomain());              // ex: https://somedomain.tld
Yii::setAlias('@backendDomain', getDomain('backend'));      // ex: https://backend.somedomain.tld

Ricorda che è un sottodominio, quindi passalo come uno se lo usi in questo modo: wwwgetDomain(‘www’)

Infine, con tutta questa configurazione, puoi semplicemente utilizzare gli alias nei tuoi file di configurazione principali:

return [
    // ...
    'components' => [
        'urlManager' => [
            // backend URL manager
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => require Yii::getAlias('@common/config/rules/backend-rules.php'),
        ],
        'urlManagerFrontend' => [
            'class' => 'yii\web\UrlManager',        // class is required on custom named URL managers!
            'hostInfo' => Yii::getAlias('@frontendDomain'),    // the full base domain name to use for the links
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => require Yii::getAlias('@common/config/rules/frontend-rules.php'),
        ],
        // ...

    ],
    // ...
];

Struttura globale di un documento HTML

Un documento HTML si compone di tre parti:

1.una riga contenente informazioni sulla versione di HTML,

2.una sezione esplicativa di intestazione (delimitata dall’elemento HEAD),

3.un corpo, che contiene il contenuto effettivo del documento. Il corpo può essere implementato per mezzo dell’elemento BODY o dell’elemento FRAMESET.

Ecco qui un esempio di un semplice documento HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
   <HEAD>
      <TITLE>Il mio primo documento HTML</TITLE>
   </HEAD>
   <BODY>
      <P>Ciao mondo!
   </BODY>
</HTML>

Un documento HTML valido dichiara quale versione di HTML è usata nel documento. La dichiarazione del tipo di documento menziona la definizione del tipo di documento (DTD) in uso per il documento (si veda [ISO8879]).

L’HTML 4.01 specifica tre DTD, così gli autori devono includere nei loro documenti una delle seguenti dichiarazioni del tipo di documento. Le DTD differiscono negli elementi che esse supportano.

•La DTD rigorosa di HTML 4.01 include tutti gli elementi e gli attributi che non sono stati disapprovati o che non appaiono nei documenti con frame. Per documenti che usano questa DTD, si adoperi la seguente dichiarazione del tipo di documento:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">

•La DTD transitoria di HTML 4.01 include tutto ciò che fa parte della DTD rigorosa più gli elementi e gli attributi disapprovati (la maggior parte dei quali riguardano la presentazione visuale).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">

•La DTD a frame di HTML 4.01 include la DTD transitoria completac con più i frame.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
        "http://www.w3.org/TR/html4/frameset.dtd">

L’URI presente in ciascuna dichiarazione del tipo di documento consente ai programmi utente di scaricare la DTD e tutti gli insiemi di entità necessari.

I seguenti URI (relativi) rimandano alle DTD e agli insiemi di entità per l’HTML 4:

•"strict.dtd" -- DTD rigorosa predefinita
•"loose.dtd" -- DTD non rigorosa
•"frameset.dtd" -- DTD per documenti con frame
•"HTMLlat1.ent" -- Entità latin-1
•"HTMLsymbol.ent" -- Entità symbol
•"HTMLspecial.ent" -- Entità speciali

Il legame tra identificatori pubblici e file può essere specificato usando un file di catalogo che segue il formato raccomandato dall’Oasis Open Consortium (si veda [OASISOPEN]). Un file di catalogo esemplificativo per HTML 4.01 è incluso all’inizio della sezione sulle informazioni di riferimento SGML per HTML.

Le ultime due lettere della dichiarazione indicano la lingua della DTD. Per l’HTML, questa è sempre l’inglese (“EN”).

A partire dalla versione del 24 Dicembre di HTML 4.01, Il Gruppo di lavoro su HTML rimanda alla seguente linea programmatica:

•Qualsiasi modifica alle future DTD di HTML 4 non invaliderà i documenti che sono conformi alle DTD delle presenti specifiche. Il Gruppo di lavoro su HTML si riserva il diritto di correggere bachi conosciuti.

•Software conformi alle DTD delle presenti specifiche possono ignorare caratteristiche delle future DTD di HTML 4 che essi non riconoscono.

Ciò significa che in una dichiarazione del tipo di documento, gli autori possono usare in tutta sicurezza un identificatore di sistema che rimanda all’ultima versione di una DTD di HTML 4. Gli autori possono anche scegliere di usare un identificatore di sistema che si riferisce ad una specifica (datata) versione di una DTD di HTML 4, quando è richiesta la conformità a quella particolare DTD.

Il W3C farà ogni sforzo per conservare i documenti d’archivio indefinitamente disponibili presso i loro indirizzi originali nella loro forma originale.

L’elemento HTML

<!ENTITY % html.content "HEAD, BODY">

<!ELEMENT HTML O O (%html.content;)    -- elemento radice del documento -->
<!ATTLIST HTML
  %i18n;                               -- lang, dir --
  >

Dopo la dichiarazione del tipo di documento, la parte rimanente di un documento HTML è contenuta all’interno dell’elemento HTML. Pertanto un tipico documento HTML ha questa struttura:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
...L'intestazione, il corpo, ecc. vanno qui...
</HTML>

L’elemento HEAD

<!-- %head.misc; definito precedentemente come "SCRIPT|STYLE|META|LINK|OBJECT" -->
<!ENTITY % head.content "TITLE & BASE?">

<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- intestazione del documento -->
<!ATTLIST HEAD
  %i18n;                               -- lang, dir --
  profile     %URI;          #IMPLIED  -- dizionario designato di metainformazioni --
  >

Definizioni di attributo

profile = uri [CT] Questo attributo specifica la locazione di uno o più profili di metadati, separati da spazio bianco. In vista di future estensioni, i programmi utente dovrebbero considerare il valore come un elenco anche se queste specifiche considerano solo il primo URI come significativo.

L’elemento HEAD contiene informazioni circa il documento corrente, quali il suo titolo, le parole chiave che possono essere utili ai motori di ricerca, ed altri dati che non sono considerati come contenuto del documento. I programmi utente generalmente non riproducono gli elementi che appaiono in HEAD come contenuto. Essi possono, tuttavia, rendere disponibili agli utenti attraverso altri meccanismi le informazioni presenti in HEAD.

L’elemento TITLE

<!– L’elemento TITLE non è considerato come parte del flusso di testo.

Esso dovrebbe essere visualizzato, ad esempio, come intestazione della pagina o come titolo della finestra. È richiesto esattamente un titolo per documento.–>

<!ELEMENT TITLE - - (#PCDATA) -(%head.misc;) -- titolo del documento -->
<!ATTLIST TITLE %i18n>

Ogni documento HTML deve avere un elemento TITLE nella sezione HEAD.

Gli autori dovrebbero usare l’elemento TITLE per identificare i contenuti di un documento. Poiché gli utenti consultano spesso documenti fuori contesto, gli autori dovrebbero fornire titoli ricchi di informazioni contestuali. Così, invece di un titolo come “Introduzione”, che non presenta granché di restroscena contestuale, gli autori dovrebbero fornire un titolo del tipo “Introduzione all’apicoltura medioevale”.

Per ragioni di accessibilità, i programmi utente devono sempre rendere il contenuto dell’elemento TITLE disponibile agli utenti (con l’inclusione degli elementi TITLE che sono presenti nei frame). Il meccanismo per ottenere ciò dipende dal tipo di programma utente (es., come una didascalia, come parlato).

I titoli possono contenere entità carattere (per i caratteri accentati, i caratteri speciali, ecc.), ma non possono contenere altro codice di marcatura (compresi i commenti). Ecco qui un esempio tipico di titolo di documento:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Uno studio sulla dinamica della popolazione</TITLE>
... altri elementi d'intestazione...
</HEAD>
<BODY>
... corpo del documento...
</BODY>
</HTML>

L’attributo title

Definizioni di attributo

title = text [CS]Questo attributo offre informazioni per la consultazione relative all’elemento per il quale è impostato.

A differenza dell’elemento TITLE, che offre informazioni su un intero documento e può apparire una volta soltanto, l’attributo title può chiosare un qualsiasi numero di elementi. Si consulti la definizione di un elemento per verificare se esso supporta questo attributo.

I valori dell’attributo title possono essere rappresentati dai programmi utente in una varietà di modi. Per esempio, i browser visuali mostrano frequentemente il titolo come un “consiglio utile” (un breve messaggio che appare quando il dispositivo di puntamento si ferma su un oggetto). I programmi utente di tipo acustico possono, in un contesto analogo, dire a voce l’informazione presente nel title. Ad esempio, impostare tale attributo in un collegamento consente ai programmi utente (visuali e non visuali) di dire agli utenti qualcosa sulla natura della risorsa collegata:

…del testo…

Ecco una foto di <A href=”http://someplace.com/neatstuff.gif” title=”Una mia immersione con l’autorespiratore”> me in immersione con l’autorespiratore l’estate scorsa</A>

…dell’altro testo…

L’attributo title ha una funzione aggiuntiva quando usato insieme con l’elemento LINK per designare un foglio di stile esterno. Si consulti per dettagli la sezione su collegamenti e fogli di stile.

Nota. Per migliorare la qualità della sintesi vocale nei casi trattati in modo insoddisfacente per mezzo delle tecniche standard, future versioni dell’HTML potranno includere un attributo per la codifica di informazioni fonematiche e prosodiche.

I metadati

Nota. Il Resource Description Framework [Sistema di Descrizione delle Risorse] del W3C (si veda [RDF10]) divenne una Raccomandazione W3C nel Febbraio 1999. RDF consente agli autori di specificare metadati leggibili da macchine relativi a documenti HTML e ad altre risorse accessibili via rete.

L’HTML lascia agli autori la possibilità di specificare dei metadati — informazioni su un documento piuttosto che il contenuto di un documento — in una varietà di modi.

Per esempio, per specificare l’autore di un documento, si può usare l’elemento META come segue:

<META name="Author" content="Dave Raggett">

L’elemento META specifica una proprietà (in questo caso “Author”) e le assegna un valore (in questo caso “Dave Raggett”).

Queste specifiche non definiscono un insieme di proprietà legali dei metadati. Il significato di una proprietà e l’insieme dei valori legali per quella proprietà dovrebbero essere definiti all’interno di un lessico di riferimento chiamato profilo. Ad esempio, un profilo progettato per aiutare i motori di ricerca ad indicizzare i documenti dovrebbe definire proprietà quali “author”, “copyright”, “keywords”, ecc.

Specificare i metadati

In generale, specificare i metadati richiede due passi:

1.Dichiarare una proprietà ed un valore per quella proprietà. Questo può essere fatto in due modi: 1.Dall’interno di un documento, per mezzo dell’elemento META.

2.Dall’esterno di un documento, attraverso un collegamento ai metadati effettuato per mezzo dell’elemento LINK (si veda la sezione sui tipi di collegamento).

2.Rinviare ad un profilo dove la proprietà ed i suoi valori legali sono definiti. Per designare un profilo, si usi l’attributo profile dell’elemento HEAD.

Si noti che, una volta che è stato definito un profilo per l’elemento HEAD, il medesimo profilo si applica a tutti gli elementi META e LINK presenti nell’intestazione del documento.

Non si richiede ai programmi utente di supportare i meccanismi dei metadati. Per quelli che scelgono di supportare i metadati, queste specifiche non definiscono come i metadati dovrebbero essere interpretati.

L’elemento META

<!ELEMENT META - O EMPTY               -- metainformazione generica -->
<!ATTLIST META
  %i18n;                               -- lang, dir, da usare con content --
  http-equiv  NAME           #IMPLIED  -- nome dell'intestazione HTTP di risposta --
  name        NAME           #IMPLIED  -- nome della metainformazione --
  content     CDATA          #REQUIRED -- informazioni associate --
  scheme      CDATA          #IMPLIED  -- modello di contenuto scelto --
  >

Definizioni di attributo

Per i seguenti attributi, i valori consentiti e la loro interpretazione sono dipendenti dal profilo:

name = name [CS] Questo attributo identifica un nome di proprietà. Queste specifiche non elencano valori legali per tale attributo.

content = cdata [CS] Questo attributo specifica un valore di proprietà. Le presenti specifiche non elencano valori legali per questo attributo.

scheme = cdata [CS] Questo attributo designa uno schema da adoperarsi per interpretare il valore di una proprietà (si veda la sezione sui profili per dettagli).

http-equiv = name [CI] Questo attributo può essere usato al posto dell’attributo name. I server HTTP usano questo attributo per raccogliere informazioni per le intestazioni dei messaggi di risposta HTTP.

L’elemento META può essere usato per identificare delle proprietà di un documento (es., autore, data di scadenza, un elenco di parole chiave, ecc.) ed assegnare valori a quelle proprietà. Queste specifiche non definiscono un insieme normativo di proprietà.

Ogni elemento META specifica una coppia proprietà/valore. L’attributo name identifica la proprietà e l’attributo content specifica il valore della proprietà.

Per esempio, la seguente dichiarazione imposta un valore per la proprietà Author:

<META name="Author" content="Dave Raggett">

L’attributo lang può essere usato con META per specificare la lingua per il valore dell’attributo content. Ciò consente ai sintetizzatori vocali di applicare regole di pronuncia dipendenti dalla lingua.

In questo esempio, il nome dell’autore è dichiarato essere francese:

<META name="Author" lang="fr" content="Arnaud Le Hors">

Nota. L’elemento META è un meccanismo generico per specificare metadati. Tuttavia alcuni elementi ed attributi HTML già trattano certi frammenti di metadati e possono essere usati dagli autori al posto di META per specificare quei frammenti: l’elemento TITLE, l’elemento ADDRESS, gli elementi INS e DEL, l’attributo title e l’attributo cite.

Nota. Quando una proprietà specificata da un elemento META ha come valore una URI, alcuni autori preferiscono specificare i metadati per mezzo dell’elemento LINK. Così, la seguente dichiarazione di metadati:

<META name="DC.identifier"
      content="http://www.ietf.org/rfc/rfc1866.txt">

potrebbe anche essere scritta nella forma:

<LINK rel="DC.identifier"
         type="text/plain"
         href="http://www.ietf.org/rfc/rfc1866.txt">

META e intestazioni HTTP

L’attributo http-equiv può essere usato al posto dell’attributo name ed ha un’importanza particolare quando i documenti sono recuperati attraverso Hypertext Transfer Protocol (HTTP) [Protocollo di Trasferimento degli Ipertesti]. I server HTTP possono usare il nome della proprietà specificata dall’attributo http-equiv per creare un’intestazione basata su [RFC822] nella risposta HTTP. Si vedano le specifiche HTTP ([RFC2616]) per dettagli sulle intestazioni HTTP valide.

La seguente dichiarazione META di esempio:

<META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">

avrà come risultato l’intestazione HTTP:

Expires: Tue, 20 Aug 1996 14:25:27 GMT

Questa può essere usata dalle memorie cache per determinare quando andare a prelevare una copia aggiornata del documento associato.

Nota. Alcuni programmi utente supportano l’uso di META per rinnovare la pagina corrente dopo un determinato numero di secondi, con l’opzione di sostituirla con un URI differente. Gli autori non dovrebbero usare questa tecnica per rinviare gli utenti a pagine differenti, poiché tale sistema rende la pagina inaccessibile per alcuni utenti. Al contrario, l’inoltro automatico di una certa pagina dovrebbe essere fatto usando i reindirizzamenti lato server.

META e motori di ricerca

Un uso comune di META è di specificare le parole chiave che un motore di ricerca può adoperare per accrescere la qualità dei risultati della ricerca. Quando una serie di elementi META fornisce informazioni dipendenti dalla lingua su un documento, i motori di ricerca possono attivare un filtro sull’attributo lang per visualizzare i risultati della ricerca in base alle preferenze linguistiche dell’utente. Ad esempio,

<– Per chi parla l’inglese americano –>

<META name="keywords" lang="en-us" 
         content="vacation, Greece, sunshine">
<-- Per chi parla l'inglese britannico -->
<META name="keywords" lang="en" 
         content="holiday, Greece, sunshine">
<-- Per chi parla francese	 -->
<META name="keywords" lang="fr" 
         content="vacances, Gr&egrave;ce, soleil">

L’efficacia dei motori di ricerca può essere accresciuta anche usando l’elemento LINK per specificare collegamenti a traduzioni del documento in altre lingue, collegamenti a versioni del documento per altri media (es., PDF), e, quando il documento è parte di un insieme, collegamenti ad un punto di partenza appropriato per scorrere l’insieme.

META e PICS

La “Platform for Internet Content Selection” [Piattaforma per la Selezione dei Contenuti di Internet] (PICS, descritto in [PICS]) è un’infrastruttura per associare etichette (metadati) con contenuti di Internet. Progettata in origine per aiutare genitori e insegnanti nel controllo delle risorse a cui i bambini possono accedere su Internet, essa agevola anche altri usi delle etichette, comprese firme cifrate, riservatezza e gestione dei diritti di proprietà intellettuale.

Questo esempio illustra come si può usare una dichiarazione META per includere un’etichetta PICS 1.1:

<HEAD>
 <META http-equiv="PICS-Label" content='
 (PICS-1.1 "http://www.gcf.org/v2.5"
    labels on "1994.11.05T08:15-0500"
      until "1995.12.31T23:59-0000"
      for "http://w3.org/PICS/Overview.html"
    ratings (suds 0.5 density 0 color/hue 1))
 '>
  <TITLE>... titolo del documento ...</TITLE>
</HEAD>

L’elemento META può essere usato per specificare le informazioni predefinite per un documento nei seguenti casi:

•Il linguaggio di scripting predefinito.

•Il linguaggio di fogli di stile predefinito.

•La codifica dei caratteri del documento.

L’esempio seguente specifica la codifica dei caratteri per un documento come ISO-8859-5:

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-5">

L’attributo profile dell’elemento HEAD specifica l’ubicazione di un profilo dei metadati. Il valore dell’attributo profile è un URI. I programmi utente dovrebbero usare questo URI in due modi:

•Come un nome univoco a livello globale. I programmi utente possono essere in grado di riconoscere il nome (senza recuperare effettivamente il profilo) e di portare a termine una certa attività basata su convenzioni note per quel profilo. Ad esempio, i motori di ricerca potrebbero fornire un’interfaccia per effettuare ricerche attraverso cataloghi di documenti HTML, dove questi documenti usano tutti il medesimo profilo allo scopo di rappresentare voci del catalogo.

•Come un collegamento. I programmi utente possono de-referenziare lo URI ed eseguire una certa attività basata sulle definizioni effettivamente presenti all’interno del profilo (es., autorizzare l’impiego del profilo all’interno del documento HTML corrente). Queste specifiche non definiscono formati per i profili.

Questo esempio rimanda ad un ipotetico profilo che definisce proprietà utili per l’indicizzazione del documento. Le proprietà definite da questo profilo — con l’inclusione di “author”, “copyright”, “keywords” e “date” — ricevono i loro valori dalle successive dichiarazioni META.

 <HEAD profile="http://www.acme.com/profili/base">
  <TITLE>Come completare le copertine del Rapporto</TITLE>
  <META name="author" content="Mario Rossi">
  <META name="copyright" content="&copy; 1997 Acme S.p.A.">
  <META name="keywords" content="aziendale,direttive,catalogazione">
  <META name="date" content="1994-11-06T08:49:37+00:00">
 </HEAD>

L’attributo scheme permette agli autori di fornire ai programmi utente maggiori informazioni contestuali per la corretta interpretazione dei metadati. A volte tali informazioni aggiuntive possono essere decisive, come nel caso in cui è possibile specificare i metadati in formati differenti. Un autore, ad esempio, potrebbe indicare una data nel formato (ambiguo) “10-9-97”: significa 9 Ottobre 1997 o 10 Settembre 1997? Il valore “Month-Day-Year” [“Mese-Giorno-Anno”] dell’attributo scheme renderebbe non più ambiguo questo valore di data.

Altre volte l’attributo scheme può fornire ai programmi utente informazioni utili ma non critiche.

Ad esempio, la seguente dichiarazione dell’attributo scheme può aiutare un programma utente a determinare che il valore della proprietà “identifier” è un numero di codice ISBN:

<META scheme="ISBN" name="identifier" content="0-8230-2355-9">

I valori per l’attributo scheme dipendono dal nome della proprietà e dal profilo associato.

scheme attribute (meta)

This attribute contains additional information for the exact determination of meta content. For example, it may contain a standard for dates used in the meta section.

Possible values:

String that sets the scheme to use.

Default: this attribute has no default value.

Un profilo campione è il Dublin Core (si veda [DCORE]). Questo profilo definisce un insieme di proprietà raccomandate per le descrizioni bibliografiche in formato elettronico e mira a promuovere l’interoperabilità tra disparati modelli di descrizione.

list of uri scheme Download