Spesso infatti si comincia a ragionare su decodifiche della url, salvataggio in sessione o cookie, ma l’html ci mette già a disposizione una soluzione strutturata in cui leggere e scrivere questa informazione.

Attributo lang: come back-end e front-end possono sfruttarlo.

Questa mattina in studio, durante lo sviluppo del nostro nuovo framework, stavamo analizzando proprio la modalità di scambio del dato di localizzazione fra back-end e back-end.
Anche se la url riporta il segmento di localizzazione (it, en-US, …), il front-end dovrebbe eseguire un parsing per estrarla e per farlo dovrebbe conoscere i criteri con cui sono disposti i segmenti. Al contrario, se il back-end, che già conosce questo dato, popolasse l’attributo lang quando serve la pagina html, il front-end lo troverebbe già nel dom e con una sola riga di codice potrebbe estarlo ed eventualmente settare un default nel caso non fosse presente.

var lang = document.documentElement.getAttribute("lang") || "it";

Quali formati standard di localizzazione supporta?

A questo punto, gestendo nel framework, sia le localizzazioni in standard ISO 639-1 (en) sia quelle in BCP 47 (en-US), ci siamo chiesti quali fossero i formati supportati nativamente dall’attributo lang di html. Ecco la risposta:

• ISO 639-1: un codice a due lettere per rappresentare le lingue. Ad esempio, “en” per l’inglese, “fr” per il francese, “it” per l’italiano, ecc.
• ISO 639-2: un codice a tre lettere per rappresentare le lingue. Ad esempio, “eng” per l’inglese, “fra” per il francese, “ita” per l’italiano, ecc.
• ISO 639-3: un codice a tre lettere per rappresentare le lingue, che estende ISO 639-2. Ad esempio, “eng” per l’inglese, “fra” per il francese, “ita” per l’italiano, ecc.
• BCP 47: uno standard utilizzato per rappresentare le lingue in modo più preciso rispetto ai formati ISO 639-1 o ISO 639-2. Consente di specificare non solo la lingua, ma anche la regione, il dialetto e altre caratteristiche linguistiche. Ad esempio, “en-US” per l’inglese negli Stati Uniti, “fr-CA” per il francese in Canada, “it-IT” per l’italiano in Italia, ecc.
• IETF Language Tag Registry: un registro di tag linguistici gestito dall’Internet Engineering Task Force (IETF), che estende BCP 47 e fornisce una maggiore flessibilità nella definizione delle lingue. Ad esempio, “zh-Hans” per il cinese semplificato, “sr-Cyrl-RS” per il serbo in cirillico in Serbia, ecc.

L'articolo Attributo lang html: formati di localizzazione supportati sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Il Builder pattern separa la costruzione di un oggetto complesso dalla sua rappresentazione, così che il processo di costruzione possa creare rappresentazioni diverse.

Il design pattern Builder è un pattern creazionale che viene utilizzato per creare oggetti complessi step by step. Il suo obiettivo principale è quello di separare la costruzione di un oggetto complesso dalla sua rappresentazione, in modo che lo stesso processo di costruzione possa essere utilizzato per creare oggetti differenti.

Il pattern Builder prevede l’utilizzo dei seguenti elementi:

• Oggetto Builder che viene utilizzato per definire le caratteristiche generali e comuni di oggetti omogenei.
• Metodi di “costruzione” che permettono di definire nello specifico l’oggetto finale passo dopo passo.

Scenari di utilizzo

Il pattern Builder può essere utilizzato ovunque ci sia la necessità di creare oggetti complessi in modo flessibile e modulare, e dove i passaggi di costruzione possono essere suddivisi in metodi più piccoli e gestibili.

Esempi concreti di impiego possono essere:

• Creazione di oggetti Model: Il pattern Builder può essere utilizzato per creare oggetti Model complessi passo dopo passo. Ad esempio, se si vuole creare un oggetto Model che rappresenta un Ordine con molti dettagli, il pattern Builder può semplificare il processo di creazione dell’oggetto suddividendo i passaggi in metodi più piccoli e gestibili.
• Costruzione di Query: Il pattern Builder può essere utilizzato per costruire query SQL complesse in modo flessibile e modulare.
• Creazione di oggetti View: Il pattern Builder può essere utilizzato per creare oggetti View complessi passo dopo passo.

Esempio di pattern Builder in PHP

Vediamo ora un esempio di codice in PHP che utilizza il pattern Builder per creare una classe che funga da query builder SQL.

class QueryBuilder {
  private $table;
  private $fields = array();
  private $conditions = array();

  public function table($table) {
    $this->table = $table;
    return $this;
  }

  public function select($fields) {
    $this->fields = $fields;
    return $this;
  }

  public function where($field, $operator, $value) {
    $this->conditions[] = array(
      'field' => $field,
      'operator' => $operator,
      'value' => $value
    );
    return $this;
  }

  public function build() {
    $query = 'SELECT ' . implode(', ', $this->fields) . ' FROM ' . $this->table;
    if (!empty($this->conditions)) {
      $query .= ' WHERE ';
      foreach ($this->conditions as $condition) {
        $query .= $condition['field'] . ' ' . $condition['operator'] . ' ' . $condition['value'] . ' AND ';
      }
      $query = rtrim($query, ' AND ');
    }
    return $query;
  }
}

In questo esempio, la classe QueryBuilder definisce i metodi per creare una query SQL complessa passo dopo passo. Il metodo table imposta la tabella su cui effettuare la query, il metodo select imposta i campi da selezionare, e il metodo where aggiunge una condizione alla clausola WHERE della query. Infine, il metodo build restituisce la query SQL completa.

Vediamo ora come utilizzare il query builder appena creato:

$query = (new QueryBuilder())
          ->table('products')
          ->select(array('id', 'name', 'price'))
          ->where('price', '>', 10)
          ->where('category', '=', 'electronics')
          ->build();
echo $query;
// Output: SELECT id, name, price FROM products WHERE price > 10 AND category = 'electronics'

Nell’esempio di utilizzo, si crea un oggetto QueryBuilder e si chiamano i metodi necessari per costruire la query desiderata, ovvero selezionare l’id, il nome e il prezzo dei prodotti con un prezzo maggiore di 10 e appartenenti alla categoria ‘electronics’. Infine, si chiama il metodo build per ottenere la query SQL completa.

Vantaggi del design pattern builder

• Consente di creare oggetti complessi step by step, separando la costruzione dell’oggetto dalla sua rappresentazione e facilitando il processo di creazione.
• Permette di creare oggetti con diverse configurazioni, utilizzando gli stessi passaggi di costruzione.
• Consente di creare oggetti in modo più flessibile e modulare, aggiungendo o rimuovendo passaggi di costruzione a seconda delle necessità.
• Consente di migliorare la leggibilità del codice, in particolare quando si hanno molti parametri da passare al costruttore.

Svantaggi del design pattern builder

• Può aumentare la complessità del codice, in particolare se si hanno molti passaggi di costruzione da definire.
• Può richiedere l’implementazione di molte classi aggiuntive (interfacce e classi concrete).
• Può introdurre un costo aggiuntivo di tempo di esecuzione a causa dell’utilizzo di oggetti intermedi durante il processo di costruzione.

Conclusioni

Il pattern Builder è un pattern molto utile e flessibile per la creazione di oggetti complessi, ma deve essere utilizzato con cautela e valutando attentamente le specifiche esigenze del progetto.

Per un panoramica generale sui design pattern consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Builder in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Lo Strategy pattern definisce una famiglia di algoritmi, li incapsula e li rende interscambiabili tra di loro. Strategy permette di variare gli algoritmi indipendentemente dai client che li usano.

Il design pattern Strategy è utile quando si desidera selezionare l’algoritmo da utilizzare in fase di esecuzione ed è composto da tre elementi fondamentali:

• L’interfaccia o la classe astratta “Strategy”: definisce il contratto che deve essere implementato dalle classi che rappresentano le diverse strategie di algoritmo. L’interfaccia o la classe astratta può includere un o più metodi, che rappresentano le operazioni che l’algoritmo deve essere in grado di eseguire.
• Le classi concrete delle strategie: queste classi implementano l’interfaccia o la classe astratta “Strategy” e rappresentano le diverse implementazioni degli algoritmi.
• La classe “Context”: rappresenta il contesto in cui viene eseguito l’algoritmo e che utilizza una delle strategie disponibili per l’esecuzione. La classe “Context” deve accettare un’istanza di una delle classi concrete delle strategie attraverso il costruttore e/o un metodo setter.

Scenario di utilizzo

Il desgin pattern Strategy è utile in situazioni in cui è necessario avere la possibilità di cambiare il comportamento di un’operazione in modo flessibile e senza dover modificare il codice dell’operazione stessa.

Esempi concreti di impiego possono essere:

• Nel controller di un framework MVC, è possibile utilizzare il pattern Strategy per incapsulare la logica di business associata a un’azione specifica. Ad esempio, se un’azione richiede la validazione dei dati di input, è possibile utilizzare una classe di validazione Strategy per gestire questo compito in modo indipendente dalla logica di business principale.
• Nel modello di un framework MVC, è possibile utilizzare il pattern Strategy per gestire la connessione ai diversi database utilizzati dall’applicazione. In questo modo, è possibile rendere la scelta del database dinamica e intercambiabile a runtime.
• Nel template di un framework MVC, è possibile utilizzare il pattern Strategy per definire diverse strategie di rendering a seconda del tipo di visualizzazione richiesta. Ad esempio, è possibile utilizzare una classe di rendering HTML per le visualizzazioni web e una classe di rendering JSON per le API REST.

Esempio di pattern Strategy in PHP

Supponiamo di dover calcolare il prezzo di un prodotto in un negozio online, ma il prezzo può variare in base a diversi fattori, come il tipo di sconto, le imposte applicabili e le tariffe di spedizione.

Invece di creare un metodo per ogni combinazione possibile di fattori, possiamo utilizzare il design pattern Strategy per creare un insieme di algoritmi, o strategie, che possono essere scelti in fase di esecuzione in base ai fattori specifici.

Vediamo ora il codice di base per implementare questo pattern.

// Creazione dell'interfaccia della strategia
interface PricingStrategy {
    public function calculatePrice($product);
}

// Implementazione della prima strategia: nessuno sconto
class NoDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice();
    }
}

// Implementazione della seconda strategia: sconto del 10%
class TenPercentDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice() * 0.9;
    }
}

// Implementazione della terza strategia: sconto del 20%
class TwentyPercentDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice() * 0.8;
    }
}

// Implementazione della classe prodotto
class Product {
    private $price;
    private $pricingStrategy;
    
    public function __construct($price, $pricingStrategy) {
        $this->price = $price;
        $this->pricingStrategy = $pricingStrategy;
    }
    
    public function getPrice() {
        return $this->pricingStrategy->calculatePrice($this);
    }
    
    public function setPricingStrategy($pricingStrategy) {
        $this->pricingStrategy = $pricingStrategy;
    }
}

// Utilizzo del codice
$product = new Product(100, new NoDiscountStrategy());
echo $product->getPrice(); // output: 100

$product->setPricingStrategy(new TenPercentDiscountStrategy());
echo $product->getPrice(); // output: 90

$product->setPricingStrategy(new TwentyPercentDiscountStrategy());
echo $product->getPrice(); // output: 80

In questo esempio, abbiamo creato un’interfaccia PricingStrategy che definisce un metodo calculatePrice(), che viene implementato dalle classi NoDiscountStrategy, TenPercentDiscountStrategy e TwentyPercentDiscountStrategy.

Abbiamo quindi creato una classe Product che accetta un oggetto PricingStrategy nel suo costruttore e ha un metodo getPrice() che utilizza la strategia selezionata per calcolare il prezzo del prodotto.

Infine, abbiamo creato un oggetto Product con un prezzo di 100 e senza sconto, e abbiamo utilizzato il metodo setPricingStrategy() per selezionare le altre strategie di sconto e calcolare il prezzo del prodotto in base ad esse.

Vantaggi del design pattern strategy

• Consente di isolare la logica di business in classi separate, rendendo il codice più modulare e facile da testare.
• Permette di sostituire gli algoritmi utilizzati in modo semplice e senza dover modificare il codice esistente.
• Favorisce l’estendibilità del codice, poiché nuovi algoritmi possono essere facilmente aggiunti senza dover modificare la struttura esistente.

Svantaggi del design pattern strategy

• L’uso del pattern Strategy può portare a un aumento della complessità del codice, poiché richiede la creazione di molte classi aggiuntive.
• Il pattern Strategy potrebbe non essere necessario in tutti i casi e potrebbe rappresentare una soluzione eccessiva in alcune situazioni.

Conclusioni

Il design pattern Strategy può essere una soluzione potente per creare codice modulare e flessibile, ma deve essere utilizzato con cautela e solo quando è effettivamente necessario.

Per un panoramica generale consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Strategy in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

L'articolo Ripristinare Memo perdute in macos Big Sure (Stikies) sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Amo la tecnologia e l’informatica da quando misi le mani sulla tastiera di un 286, ho vissuto l’evoluzione dei pc e vivo quotidianamente questa passione nel mio lavoro. Già nel 2016 avevo colto diversi segnali e scritto un articolo sulla mia visione di un futuro ARM. Apple M1 rappresenta oggi il punto di svolta della mia visione.

Apple M1: la nuova era dei personal computer

Con il chip Apple M1 inizia una nuova era per i personal computer. Dopo ormai 40 anni di assemblaggio di pc con il pattern CPU + GPU + RAM finalmente è arrivata una nuova architettura, un nuovo modo di elaborare.

Cosa ha portato a questo cambiamento? L’evoluzione! Si sono evolute le esigenze degli utenti, si sono evoluti i software, si sono evoluti i processi produttivi. Aumentare i Ghz ed i core delle CPU non era più sufficiente, anzi efficiente. Il nuovo SoC Apple M1 (system on a chip) compie questo salto, un ecosistema con 16 miliardi di transistor che integra CPU, GPU, Neural Engine, crittografia, I/O su un unico circuito.

Non solo chip Apple M1

Apple non è l’unica ad aver sviluppato SoC di questo tipo. ARM, ora di Nvidia, ha presentato pochi giorni fa il suo Cortex-A78C che sfida direttamente Apple M1. Ci sono poi gli Snapdragon di Qualcomm sui Surface di Microsoft ed Amazon che utilizza il suo Graviton2 nei suoi server AWS.

Allora, cos’ha il chip Apple M1 che gli altri non hanno? Oltre alla possibilità economica di investire nello sviluppo, il vero x-factor è l’impronta della visione di Jobs di un sistema totalmente integrato tra hardware e software incentrato sull’esperienza dell’utente. Da sempre i Mac hanno dato molto di più con (molto) meno grazie ad un sistema operativo ottimizzato per un hardware specifico che non producevano direttamente… fino ad oggi!

Il lato oscuro dell’era Mac con ARM

Il passaggio di architettura è stato a mio avviso ben studiato da Apple così come l’esperienza utente che offrirà. Sono stati forniti diversi strumenti per consentire la migrazione, da Rosetta2 per l’esecuzione dei i software compilati per x86, alle app universal che potranno girare “facilmente” su iOS, iPadOs e macOS.

Quindi solo aspetti positivi? Speriamo, ma mi rimangono diversi dubbi su quanto il sistema operativo verrà chiuso e quali saranno le politiche per la distribuzione del software. L’utenza di iPhone ed iPad è diversa da quella dei mac ed un’eccessiva chiusura, così come l’imposizione del passaggio da App Store e dalla “tassa” del 30% sulla vendita del software, potrebbero portare alla scomparsa di diversi software da questo sistema.

Il futuro ARM dei personal computer

Sicuramente assisteremo ad un passaggio, neppure troppo graduale, verso queste architetture da parte di tutti i produttori di PC ed in buona parte degli ambiti applicativi, dall’office al gaming passando per i server. Intel dovrà darsi una mossa perché rischia di finire come Nokia nel passaggio dal cellulare allo smartphone.
Guardando ad Apple, sulla carta è tecnologicamente favorita, ma conteranno molto le politiche commerciali relative alla distribuzione del software che deciderà di adottare.

L'articolo Apple M1 (Silicon): il futuro dei personal computer secondo me. sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

HTTP messages are the foundation of web development.

Standardizzare questo aspetto è importantissimo poiché i messaggi Http sono le fondamenta dello sviluppo web. I browser ed i client come cURL inviano richieste Http al server che fornisce un’adeguata risposta Http.

Di seguito analizzeremo le interfacce proposte dal PSR-7 che rappresentano astrazioni dei messaggi Http e degli elementi che li compongono. Per il significato delle parole chiave presenti nell’articolo si rimanda alle note dell’articolo sul PSR-1.

Http Request

Iniziamo esaminando il contenuto di una Http Request.

POST /path HTTP/1.1
Host: example.com

foo=bar&baz=bat

La prima riga, detta “request line”, contiene il metodo della richiesta Http, il target della richiesta Http, solitamente una URI assoluta o un percorso sul server web, la versione del protocollo Http utilizzato. A questo seguono una o più intestazioni Http, una riga vuota ed il corpo del messaggio.

Http Response

Esaminiamo ora il contenuto di una Http Response.

HTTP/1.1 200 OK
Content-Type: text/plain

This is the response body

La prima riga di una Http Response, detta “status line”, contiene la versione del protocollo Http, il codice di stato Http ed una descrizione comprensibile del codice di stato. Come per il messaggio di richiesta, questa riga è seguita da una o più intestazioni Http, una riga vuota ed il corpo del messaggio.

PSR-7: specifiche

Messaggi Http

Un messaggio Http è una richiesta da un client ad un server o una risposta da un server ad un client. PSR-7 definisce le rispettive interfacce per i messaggi Http: Psr\Http\Message\RequestInterface e Psr\Http\Message\ResponseInterface.

Entrambe estendono Psr\Http\Message\MessageInterface.
Mentre <a href="#MessageInterface">Psr\Http\Message\MessageInterface</a> PUÒ essere implementato direttamente, gli implementatori DOVREBBERO implementare Psr\Http\Message\RequestInterface e Psr\Http\Message\ResponseInterface.
Per migliorare la lettura dell’articolo, da qui in avanti verrà omesso il namespace Psr\Http\Message per riferirsi a queste interfacce.

HTTP Headers

Nomi case-insensitive nei campi di intestazione.

I messaggi Http possono includere vari campi nell’intestazione (header) senza distinzione tra maiuscole e minuscole. Allo stesso modo dovranno essere recuperate dalle classi che implementano <strong><em><a href="#MessageInterface">MessageInterface</a></em></strong>.
Ad esempio, il recupero dell’intestazione foo restituirà lo stesso risultato del recupero dell’intestazione FoO. Allo stesso modo, l’impostazione dell’intestazione Foo sovrascriverà qualsiasi valore di intestazione foo precedentemente impostato.

$message = $message->withHeader('foo', 'bar');

echo $message->getHeaderLine('foo');
// Outputs: bar

echo $message->getHeaderLine('FOO');
// Outputs: bar

$message = $message->withHeader('fOO', 'baz');

echo $message->getHeaderLine('foo');
// Outputs: baz

Nonostante le intestazioni possano essere recuperate senza distinzione tra maiuscole e minuscole, il case originale DEVE essere rispettato nell’implementazione, in particolar modo quando viene recuperato con getHeaders(). Questo perché applicazioni Http non conformi possono dipendere da un determinato caso.

Campi di intestazione con valori multipli

Per gestire campi di intestazione con più valori e fornire una migliore flessibilità nella gestione, le intestazioni possono essere recuperate da un’istanza di <strong><em>MessageInterface</em></strong> come array o stringa. Nel primo caso useremo <strong>getHeader()</strong>, nel secondo <strong>getHeaderLine()</strong>.

$message = $message
    ->withHeader('foo', 'bar')
    ->withAddedHeader('foo', 'baz');

$header = $message->getHeaderLine('foo');
// $header contiene: 'bar,baz'

$header = $message->getHeader('foo');
// ['bar', 'baz']

Da notare che non tutti i valori di intestazione possono essere concatenati con la virgola (es: Set-Cookie). In questo caso gli utilizzatori DOVREBBERO usare metodo getHeader() per recuperare tali intestazioni multivalore.

Intestazione “Host”

Nelle richieste, l’intestazione Host riporta l’host dell’URI, nonché l’host utilizzato per stabilire la connessione Tcp. Le specifiche del protocollo Http consentono però all’intestazione Host di differire da entrambi. Le implementazioni, se non viene fornita alcuna intestazione Host, DEVONO tentare di impostarla da un URI predefinito .

<strong>RequestInterface :: withUri (UriInterface $uri, $preserveHost = false)</strong>, per impostazione predefinita, sostituirà l’intestazione Host della richiesta restituita con quella dell’oggetto di tipo <strong>UriInterface</strong> passatogli. Per mantenere il valore originale basterà passare true al secondo argomento ($preservHost). Ciò manterrà invariata l’intestazione Host a patto che il messaggio ne contenga una.

Questa tabella mostra cosa restituirà getHeaderLin('Host') per una richiesta restituita da withUri() con l’argomento $preservHost impostato su true in varie richieste iniziali e URI.

1. Valore dell’intestazione host prima dell’operazione.
2. Componente host dell’URI composto nella richiesta prima dell’operazione.
3. Componente host dell’URI settato tramite withUri().

Streams

I messaggi Http sono costituiti da una riga iniziale, alcune intestazioni ed un corpo che può essere anche molto grande. Rappresentare il body di un messaggio come una stringa potrebbe consumare molta memoria fino a precludere la possibiltà di lavorare con body di grandi dimensioni. <strong>StreamInterface</strong> viene utilizzato proprio per nascondere i dettagli di implementazione quando un flusso di dati viene letto o scritto. Per le situazioni in cui una stringa sarebbe un’implementazione del messaggio appropriata, è possibile utilizzare flussi incorporati come php://memory e php://temp.

StreamInterface espone diversi metodi che consentono di leggere, scrivere e scorrere gli stream in modo efficace.

Gli stram espongono le loro capacità utilizzando tre metodi: isReadable(), <strong>isWritable()</strong> e <strong>isSeekable()</strong>. Gli oggetti che vogliono utilizzare uno stream possono utilizzare questi metodi per determinare se è in grado di soddisfare determinati requisiti.

Ogni istanza di uno stream avrà diverse funzionalità: può essere di sola lettura, di sola scrittura o di lettura/scrittura. Può consentire un accesso casuale arbitrario (ricerca in avanti o indietro in qualsiasi posizione) o solo accesso sequenziale come nel caso di socket, pipe, o callback-based stream.

Infine, StreamInterface definisce un metodo __toString() per recuperare o inviare l’intero contenuto del corpo in una sola volta.

A differenza delle interfacce di Request e Response, StreamInterface interagisce con gli stream che, per loro natura, possono mutare durante il loro utilizzo. La raccomandazione di Php-Fig è di utilizzare flussi di sola lettura per le richieste lato server e le risposte lato client.

Target della richiesta ed URI

Secondo lo standard RFC 7230 i messaggi di richiesta contengono uno dei seguenti tipi di “target”:

• origin-form: costituito da percorso e, se presente, stringa della query. È solitamente definito come un URL relativo. I messaggi trasmessi via Tcp sono tipicamente di tipo origin-form; i dati di scheme e authority sono presenti tramite variabili CGI.
• absolute-form: costituito da scheme, authority (“[user-info@]host[:port]”, dove gli elementi tra parentesi sono facoltativi), percorso (se presente), stringa della query (se presente) e fragment ( se presente). È solitamente definito come un URI assoluto ed è l’unico che consente di specificare una URI come descritto nel RFC 3986. Questo modulo è comunemente usato quando si effettuano richieste ai proxy Http
• authority-form: costituito dalla sola authority. È solitamente utilizzato nelle CONNECT Request per stabilire una connessione tra un client Http e un server proxy.
• asterisk-form: costituito unicamente dalla stringa asterisco ( ” * ” ). È solitamente utilizzato con il metodo OPTIONS per determinare le capacità generali di un server web.

Oltre a questi target di richiesta, c’è spesso un “URL effettivo” che è separato dal target di richiesta. L’URL effettivo non viene trasmesso all’interno di un messaggio Http, ma viene utilizzato per determinare il protocollo (http / https), la porta e l’host-name per effettuare la richiesta.

L’URL effettivo è rappresentato da <strong>UriInterface</strong>. UriInterface rappresenta gli URI Http e Https fornendo i metodi per interagire con le varie parti dell’URI evitendo un’analisi ripetuta dell’URI. Specifica inoltre un metodo __toString() per rappresentare la URI come stringa.

Quando si recupera la destinazione della richiesta con <strong>getRequestTarget()</strong>, per impostazione predefinita questo metodo utilizzerà l’oggetto URI ed estrarrà tutti i componenti necessari per costruire l’origin-form che è il request-target più comune.

Se si desidera utilizzare uno degli altri tre tipi di target o se l’utente desidera sovrascrivere esplicitamente il target della richiesta si utilizzerà il metodo <strong>withRequestTarget()</strong>. La chiamata a questo metodo non influisce sull’URI, poiché viene restituito da <strong>getUri()</strong>.

Ad esempio, un utente potrebbe voler effettuare una richiesta in formato asterisco a un server:

$request = $request
    ->withMethod('OPTIONS')
    ->withRequestTarget('*')
    ->withUri(new Uri('https://example.org/'));

L’esempio creerebbe questo tipo di richiesta Http:

OPZIONI * HTTP / 1.1

Il client Http sarà poi in grado di utilizzare l’URL effettivo (getUri()) per determinare il protocollo, l’host-name e la porta Tcp.

Un client Http DEVE ignorare i valori di <strong>Uri::getPath()</strong> e <strong>Uri::getQuery()</strong> ed utilizzare il valore restituito da <strong>getRequestTarget()</strong> che concatena questi due valori.

I client che scelgono di non implementare 1 o più dei 4 request-target form, DEVONO comunque utilizzare <strong>getRequestTarget()</strong>. Questi client DEVONO rifiutare request-target che non supportano e NON DEVONO utilizzare i valori di <strong>getUri()</strong>.

<strong>RequestInterface</strong> fornisce metodi per recuperare il target della richiesta o creare una nuova istanza specificando il target. Per impostazione predefinita, se non viene specificato il request-target, <strong>getRequestTarget()</strong> restituirà l’origin-form della URI composta o ” / ” se non è stata composta una URI. withRequestTarget($requestTarget) crea una nuova istanza con il request-target specificato ed è utile per creare connessioni verso un server.

Richieste Server-side

• <strong>RequestInterface</strong> permette di rappresentare un messaggio di richiesta Http, ma le richieste lato server side richiedono un’attenzione particolare. I processi server-side devono tener conto della Common Gateway Interface (CGI) e dell’interazione di PHP con essa attraverso le sue via Server API (SAPI) . PHP ci fornisce una semplificazione per la gestione degli input attraverso variabili superglobali:
• <strong>$_COOKIE</strong>: deserializza e fornisce un accesso ai cookie Http.
• <strong>$_GET</strong>: deserializza e fornisce un accesso agli argomenti della query string.
• $_POST: deserializza e fornisce un accesso per i parametri inviati tramite. Post Http. Può essere considerato il risultato dell’analisi del message body.
• $_FILES: fornisce metadati relativi ai caricamenti dei file.
• $_SERVER: fornisce l’accesso alle variabili d’ambiente CGI / SAPI che includono il metodo di richiesta, lo schema di richiesta, l’URI della richiesta e le intestazioni.

ServerRequestInterface estende RequestInterface per fornire un’astrazione su questi variabili superglobali riducendo l’accoppiamento.

La richiesta server-side fornisce una proprietà aggiuntiva, gli “attributi”, che consentono di esaminare, scompore e cercare match in modo da interpretare la richiesta in base alle specifiche necessità nell’applicativo.

Upload dei file

<strong>ServerRequestInterface</strong> specifica un metodo per recuperare una rappresentazione dei file caricati attraverso una struttura normalizzata in cui ogni elemento è un’istanza di <strong>UploadedFileInterface</strong>.

$_FILES ha alcuni problemi noti, ad esempio se si tenta di inviare da un form molteplici file attraverso campi di input aventi name “files”, l’array risultante verrà così rappresentato da PHP:

array(
    'files' => array(
        'name' => array(
            0 => 'file0.txt',
            1 => 'file1.html',
        ),
        'type' => array(
            0 => 'text/plain',
            1 => 'text/html',
        ),
        /* etc. */
    ),
)

Mentre ci si aspetterebbe una rappresentazione di questo tipo:

array(
    'files' => array(
        0 => array(
            'name' => 'file0.txt',
            'type' => 'text/plain',
            /* etc. */
        ),
        1 => array(
            'name' => 'file1.html',
            'type' => 'text/html',
            /* etc. */
        ),
    ),
)

Gli utilizzatori devono conoscere quindi i dettagli dell’implementazione nel linguaggio PHP e scrivere il codice per interpretare correttamente i dati di un determinato caricamento.

In alcuni casi poi $_FILES non viene popolato con i dati relativi ai file caricati:

• Quando il metodo Http non è POST.
• Quando si esegue una unit test.
• Quando si opera in un ambiente non SAPI come ad esempio ReactPHP.

In questi casi si dovranno utilizzare approcci diversi, ad esempio:

• Un processo potrebbe analizzare il message body per scoprire i file caricati.
• Negli scenari di unit test, gli sviluppatori devono essere in grado di bloccare e/o simulare i metadati di caricamento del file per convalidare e verificare i diversi scenari.

<strong>getUploadedFiles()</strong> fornisce una struttura normalizzata e l’implementazione dovrebbe:

• Aggregare tutte le informazioni per un determinato caricamento di file e usarle per popolare un’istanza <strong>Psr\Http\Message\UploadedFileInterface</strong>.
• Ricreare la struttura ad albero inviata in cui ogni foglia rappresenti un’istanza di <strong>Psr\Http\Message\UploadedFileInterface</strong> appropriata.
• La struttura ad albero dovrebbe seguire la struttura dei nomi in cui sono stati inviati i file.

Vediamo un esempio con un singolo campo di input con un “name semplice”:

<input type="file" name="avatar" />

In questo caso, la struttura di $ _FILES sarebbe:

array(
    'avatar' => array(
        'tmp_name' => 'phpUxcOty',
        'name' => 'my-avatar.png',
        'size' => 90996,
        'type' => 'image/png',
        'error' => 0,
    ),
)

Mentre la forma normalizzata restituita da getUploadedFiles() potrebbe essere:

array(
    'avatar' => /* UploadedFileInterface instance */
)

Vediamo invece un caso di campo di input che utilizza crea un array nell’attributo nome:

<input type="file" name="my-form[details][avatar]" />

In questo caso il contenuto di $_FILES sarà

array (
    'my-form' => array (
        'name' => array (
            'details' => array (
                'avatar' => 'my-avatar.png',
            ),
        ),
        'type' => array (
            'details' => array (
                'avatar' => 'image/png',
            ),
        ),
        'tmp_name' => array (
            'details' => array (
                'avatar' => 'phpmFLrzD',
            ),
        ),
        'error' => array (
            'details' => array (
                'avatar' => 0,
            ),
        ),
        'size' => array (
            'details' => array (
                'avatar' => 90996,
            ),
        ),
    ),
)

E l’albero corrispondente restituito da getUploadedFiles() dovrebbe essere:

array(
    'my-form' => array(
        'details' => array(
            'avatar' => /* UploadedFileInterface instance */
        ),
    ),
)

Vediamo ora il caso di un array di file:

Upload an avatar: <input type="file" name="my-form[details][avatars][]" />
Upload an avatar: <input type="file" name="my-form[details][avatars][]" />

Ecco cosa conterrà $_FILES:

array (
    'my-form' => array (
        'name' => array (
            'details' => array (
                'avatar' => array (
                    0 => 'my-avatar.png',
                    1 => 'my-avatar2.png',
                    2 => 'my-avatar3.png',
                ),
            ),
        ),
        'type' => array (
            'details' => array (
                'avatar' => array (
                    0 => 'image/png',
                    1 => 'image/png',
                    2 => 'image/png',
                ),
            ),
        ),
        'tmp_name' => array (
            'details' => array (
                'avatar' => array (
                    0 => 'phpmFLrzD',
                    1 => 'phpV2pBil',
                    2 => 'php8RUG8v',
                ),
            ),
        ),
        'error' => array (
            'details' => array (
                'avatar' => array (
                    0 => 0,
                    1 => 0,
                    2 => 0,
                ),
            ),
        ),
        'size' => array (
            'details' => array (
                'avatar' => array (
                    0 => 90996,
                    1 => 90996,
                    3 => 90996,
                ),
            ),
        ),
    ),
)

L’array sopra riportato corrisponderebbe alla seguente struttura restituita da <strong>getUploadedFiles()</strong>:

array(
    'my-form' => array(
        'details' => array(
            'avatars' => array(
                0 => /* UploadedFileInterface instance */,
                1 => /* UploadedFileInterface instance */,
                2 => /* UploadedFileInterface instance */,
            ),
        ),
    ),
)

Per accedere all’elemento [1]:

$request->getUploadedFiles()['my-form']['details']['avatars'][1];

Seguendo il nostro esempio avremo:

$file0 = $request->getUploadedFiles()['files'][0];
$file1 = $request->getUploadedFiles()['files'][1];

printf(
    "Received the files %s and %s",
    $file0->getClientFilename(),
    $file1->getClientFilename()
);

Poiché le inforazioni sui file caricati, oltre che da $_FILES, possono derivare da altri elementi della richiesta, è presente il metodo <strong>withUploadedFiles()</strong> che consente di delegare la normalizzazione ad un altro processo.

Lo standard PSR-7 considera anche le implementazioni in ambienti non SAPI. Pertanto, UploadedFileInterface fornisce metodi per garantire che le operazioni funzionino indipendentemente dall’ambiente. In particolare:

• moveTo($targetPath) viene fornito come alternativa sicura e consigliata per richiamare move_uploaded_file() sul file di caricamento temporaneo. Le implementazioni rileveranno il corretto funzionamento da utilizzare in base all’ambiente.
• <strong>getStream()</strong> restituirà un’istanza StreamInterface. In ambienti non SAPI, una possibilità proposta è quella di eseguire il parsing dei file caricati nello stream php://temp.

Ad esempio:

// Move a file to an upload directory
$filename = sprintf(
    '%s.%s',
    create_uuid(),
    pathinfo($file0->getClientFilename(), PATHINFO_EXTENSION)
);
$file0->moveTo(DATA_DIR . '/' . $filename);

// Stream a file to Amazon S3.
// Assume $s3wrapper is a PHP stream that will write to S3, and that
// Psr7StreamWrapper is a class that will decorate a StreamInterface as a PHP
// StreamWrapper.
$stream = new Psr7StreamWrapper($file1->getStream());
stream_copy_to_stream($stream, $s3wrapper);

PSR-7: Interfacce

Psr\Http\Message\MessageInterface

interface MessageInterface {
    /**
     * Recupera la versione del protocollo HTTP (Es: "1.1", "1.0")
     *
     * @return string HTTP protocol version.
     */
    public function getProtocolVersion();

    /**
     * Restituisce un'istanza con una specifica versione del protocollo HTTP
     *
     * @param string $version HTTP protocol version
     * @return static
     */
    public function withProtocolVersion($version);

    /**
     * Recupera tutti i valori di intestazione del messaggio
     *
     * @return string[][] Returns an associative array of the message's headers.
     */
    public function getHeaders();

    /**
     * Verifica se esiste un'intestazione in base al nome senza distinzione tra maiuscole e minuscole.
     *
     * @param string $name Case-insensitive header field name.
     * @return bool
     */
    public function hasHeader($name);

    /**
     * Recupera un valore di intestazione del messaggio in base al nome senza distinzione tra maiuscole e minuscole.
     *
     * @param string $name Case-insensitive header field name.
     * @return string[] An array of string values as provided for the given header.
     */
    public function getHeader($name);

    /**
     * Recupera una stringa separata da virgole dei valori per una singola intestazione.
     *
     * @param string $name Case-insensitive header field name.
     * @return string A string of values as provided for the given header concatenated together using a comma.
     */
    public function getHeaderLine($name);

    /**
     * Restituisce un'istanza sostituendo il valore dell'intestazione specificata.
     *
     * @param string $name Case-insensitive header field name.
     * @param string|string[] $value Header value(s).
     * @return static
     * @throws \InvalidArgumentException for invalid header names or values.
     */
    public function withHeader($name, $value);

    /**
     * Restituisce un'istanza appendendo un valore al campo di intestazione specificato.
     *
     * @param string $name Case-insensitive header field name to add.
     * @param string|string[] $value Header value(s).
     * @return static
     * @throws \InvalidArgumentException for invalid header names or values.
     */
    public function withAddedHeader($name, $value);

    /**
     * Restituisce un'istanza eliminando l'intestazione specificata.
     *
     * @param string $name Case-insensitive header field name to remove.
     * @return static
     */
    public function withoutHeader($name);

    /**
     * Ottiene il corpo del messaggio.
     *
     * @return StreamInterface Returns the body as a stream.
     */
    public function getBody();

    /**
     * Restituisce un'istanza con il corpo del messaggio specificato.
     *   
     * @param StreamInterface $body Body.
     * @return static
     * @throws \InvalidArgumentException When the body is not valid.
     */
    public function withBody(StreamInterface $body);
}

L'articolo PSR-7 Http Message: standard php per Request e Response. sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

The main goal is to allow libraries to receive a Psr\Log\LoggerInterface object and write logs to it in a simple and universal way.

L’obiettivo è quello di far sì che le varie componenti software possano utilizzare un oggetto di tipo Psr\Log\LoggerInterface per scrivere messaggi di log in modo semplice ed universale.

Anche gli applicativi più complessi come i framework POTREBBERO estendere l’interfaccia del logger per arricchirla di funzioni, ma DOVREBBERO assicurarsi di mantenerne la compatibilità. In questo modo tutti i componenti e le librerie utilizzate potrebbero scrivere nei log centralizzati dell’applicativo.

La parola implementatore (<strong>implementor</strong>) utilizzata nel testo dello standard PSR3 rappresenta qualcuno che implementa la <strong><em>LoggerInterface</em></strong> per inserire un logger in una libreria o framework .
Gli utenti dei logger vengono definiti utenti (user).

Per il significato delle altre parole chiave si rimanda alle note dell’articolo sul PSR-1.

PSR-3: specifiche

LoggerInterface: l’Interfaccia di base

La <strong><em>LoggerInterface</em></strong> espone otto metodi per scrivere i log utilizzando i rispettivi livelli dello standard RFC 5424: debug, info, notice, warning, error, critical, alert, emergency. Tali livelli vengono definiti come costanti.

<?php

namespace Psr\Log;

class LogLevel
{
    const EMERGENCY = 'emergency';
    const ALERT     = 'alert';
    const CRITICAL  = 'critical';
    const ERROR     = 'error';
    const WARNING   = 'warning';
    const NOTICE    = 'notice';
    const INFO      = 'info';
    const DEBUG     = 'debug';
}

Un nono metodo <strong>log</strong> accetta come primo argomento il livello di log.
La chiamata a questo metodo con una delle costanti di livello DEVE avere lo stesso effetto della chiamata al metodo specifico del relativo livello. Chiamare questo metodo con un livello non definito DEVE lanciare un’eccezione di tipo <em>Psr\Log\InvalidArgumentException</em> se l’implementazione non prevede tale livello. Gli utenti NON DOVREBBERO utilizzare un livello personalizzato senza essere certi che l’attuale implementazione lo supporti.

Psr\Log\LoggerInterface: il codice

Di seguito il codice dell’interfaccia <strong><em>LoggerInterface</em></strong>.

<?php

namespace Psr\Log;

interface LoggerInterface
{
    /**
     * Il sistema è inutilizzabile
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function emergency( $message, array $context = [] );

    /**
     * È necessario agire immediatamente.
     *
     * Esempio: Il sito web è down, database non disponibile, ... 
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function alert( $message, array $context = [] );

    /**
     * Condizione critica
     *
     * Esepio: Componente non trovato, eccezione inaspettata, ...
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function critical( $message, array $context = [] );

    /**
     * Errori di runtime che non richiedono un'azione immediata 
     * ma in genere dovrebbero essere loggati e monitorati.
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function error( $message, array $context = [] );

    /**
     * Occorrenze eccezionali che non sono errori
     * Esempio: uso di api deprecate.
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function warning( $message, array $context = [] );

    /**
     * Eventi normali ma significativi.
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function notice( $message, array $context = [] );

    /**
     * Eventi interessanti
     * Esempio: Log-in utente, esecuzione query, ...
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function info( $message, array $context = [] );

    /**
     * Informazioni dettagliate sul debug.
     *
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     */
    public function debug( $message, array $context = [] );

    /**
     * Creazione del Log con un livello arbitrario.
     *
     * @param mixed   $level
     * @param string  $message
     * @param mixed[] $context
     *
     * @return void
     *
     * @throws \Psr\Log\InvalidArgumentException
     */
    public function log( $level, $message, array $context = [] );
}

La gestione dell’eccezione di <em>Psr\Log\InvalidArgumentException</em> estende la classe nativa di php <a rel="noreferrer noopener" href="https://www.php.net/manual/en/class.invalidargumentexception.php" target="_blank"><em>InvalidArgumentException</em></a> e deve essere lanciata dal logger qualora vengano passati ai metodi dei paramentri non corretti.

<?php

namespace Psr\Log;

class InvalidArgumentException extends \InvalidArgumentException {
    // class body
}

PSR-3: messaggi

Ogni metodo accetta una stringa come messaggio o un oggetto con un metodo __toString (). Gli implementatori POSSONO implementare una gestione personalizzata per gli oggetti passati al metodo. In caso contrario, gli implementatori DEVONO eseguire il type casting del valore passato in stringa.

Il messaggio PUÒ contenere un placeholder che gli implementatori possono sostituire con i valori presi dall’array del parametro context.

I nomi dei placeholder DEVONO corrispondere alle chiavi del context array.

I nomi dei placeholder DEVONO essere delimitati fra due parentesi graffe singole {placeholder}. NON DEVE esserci spazio tra i delimitatori e il nome placeholder.

I nomi dei placeholder DOVREBBERO essere composti solo dai caratteri A-Z, a-z, 0-9, underscore _, e punto .. L’uso di altri caratteri è riservato per future modifiche delle specifiche dei placeholder.

Gli implementatori POSSONO usare i placeholder per implementare escaping strategy o gestire la traduzione dei messagi. Gli utenti non DOVREBBERO effettuare l’escape preventivo dei placeholder poiché non possono sapere in quale contesto i dati inseriti nei messaggi verranno visualizzati.

Il PHP-FIG fornisce una semplice funzione di esempio per comprendere meglio la funzione dei placeholder nei messaggi di log.

<?php

/**
 * Sostituisce i placeholder dei messaggi con i rispettivi valori.
 */
function interpolate($message, array $context = []) {
    // Crea l'array delle sostituzioni
    $replace = array();
    foreach ($context as $key => $val) {
        // controlla che il valore possa essere usato come stringa.
        if (!is_array($val) && (!is_object($val) || method_exists($val, '__toString'))) {
            $replace['{' . $key . '}'] = $val;
        }
    }

    // Sostituisce i placeholder con i rispettivi valori.
    return strtr($message, $replace);
}

// Messaggio contenente il placeholder fra graffe
$message = "User {username} created";

// Il context array con i dati da sostituire ai placeholder
$context = array('username' => 'bolivar');

// stampa "User bolivar created"
echo interpolate($message, $context);

Context data

Ogni metodo accetta un array contenente dati contestuali (context data) per gestire ulteriori informazioni che non possano essere ridotte alla stringa del messagio. L’array può contenere qualsiasi tipo di dato. Gli implementatori DEVONO utilizzare i dati di contesto con moderazione. Un context data NON DEVE generare un’eccezione né errori php di tipo error, warning o notice

Se nei context data viene passato un oggetto di tipo <em>Exception</em>, questo DEVE essere passato nella chiave 'exception'. Poiché il log delle eccezioni è un’esigenza diffusa, questa regola dello standard PSR-3 consente di registrare questo tipo di evento ed il relativo stack trace. Gli implementatori DEVONO verificare che il dato contenuto nella chiave 'exception' sia realmente un oggetto di tipo Exception dato che l’elemento dell’array potebbe contenere qualsiasi tipo di dato.

PSR-3: classi helper ed interfacce

La classe di esempio <em>Psr\Log\AbstractLogger</em> facilita l’implementazione di <em>LoggerInterface</em> estendendola e implementando il metodo log generico. Gli altri otto metodi richiamano il metodo <em>log</em> passandogli la corretta costante di livello, messaggio ed eventuale contesto.

<?php

namespace Psr\Log;

abstract class AbstractLogger implements LoggerInterface {

    public function emergency($message, array $context = []) {
        $this->log(LogLevel::EMERGENCY, $message, $context);
    }

    public function alert($message, array $context = []) {
        $this->log(LogLevel::ALERT, $message, $context);
    }

    public function critical($message, array $context = []) {
        $this->log(LogLevel::CRITICAL, $message, $context);
    }

    public function error($message, array $context = [])) {
        $this->log(LogLevel::ERROR, $message, $context);
    }

    public function warning($message, array $context = []) {
        $this->log(LogLevel::WARNING, $message, $context);
    }

    public function notice($message, array $context = []) {
        $this->log(LogLevel::NOTICE, $message, $context);
    }

    public function info($message, array $context = []) {
        $this->log(LogLevel::INFO, $message, $context);
    }

    public function debug($message, array $context = []) {
        $this->log(LogLevel::DEBUG, $message, $context);
    }
}

Similmente ad AbstractLogger è possibile creare un trait <em>Psr\Log\LoggerTrait</em> utile nel caso si voglia implementare il logger in diverse classi. Poiché i traits non possono implementare delle interfacce, in questo caso si dovrà di fatto riscrivere il codice di LoggerInterface.

namespace Psr\Log;

trait LoggerTrait {

    public function emergency($message, array $context = []) {
        $this->log(LogLevel::EMERGENCY, $message, $context);
    }

    public function alert($message, array $context = []) {
        $this->log(LogLevel::ALERT, $message, $context);
    }

    public function critical($message, array $context = array[]) {
        $this->log(LogLevel::CRITICAL, $message, $context);
    }

    public function error($message, array $context = [])) {
        $this->log(LogLevel::ERROR, $message, $context);
    }

    public function warning($message, array $context = []) {
        $this->log(LogLevel::WARNING, $message, $context);
    }

    public function notice($message, array $context = [])
    {
        $this->log(LogLevel::NOTICE, $message, $context);
    }

    public function info($message, array $context = [])
    {
        $this->log(LogLevel::INFO, $message, $context);
    }

    public function debug($message, array $context = [])
    {
        $this->log(LogLevel::DEBUG, $message, $context);
    }

    abstract public function log($level, $message, array $context = []);
}

Veniamo ora al “piuttosto che niente”! <em>Psr\Log\NullLogger</em> implementa <em>AbstractLogger</em> e PUÒ essere usato dagli utenti, se non gli viene fornito un apposito log, da utilizzare con una fall-back. E’ una sorta di “black hole” in cui inviare qualcosa che potrà essere loggato.

<?php

namespace Psr\Log;

class NullLogger extends AbstractLogger
{
    /**
     * Logs with an arbitrary level.
     *
     * @param mixed  $level
     * @param string $message
     * @param array  $context
     *
     * @return void
     *
     * @throws \Psr\Log\InvalidArgumentException
     */
    public function log($level, $message, array $context = array())
    {
        // class body
    }
}

<em>Psr\Log\LoggerAwareInterface</em> contiene solo un metodo setLogger(LoggerInterface $logger) che PUÒ essere utilizzato dai framework per collegarsi automaticamente a istanze del logger.

<?php

namespace Psr\Log;

interface LoggerAwareInterface {
    public function setLogger(LoggerInterface $logger);
}

Il trait Psr\Log\LoggerAwareTrait PUÒ essere utilizzato per implementare facilmente la medesima interfaccia in qualsiasi classe così da avere accesso all’oggetto $this->logger.

PSR-3 Logger package

Le interfacce e le classi descritte, nonché le relative classi di eccezione e una suite di test per verificare l’implementazione sono fornite come parte del pacchetto psr/log sul sito ufficiale di PHP-FIG

L'articolo PSR-3 Logger Interface: standard log per PHP sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Prima di procedere con la lettura della lezione sullo standard PSR1 consiglio di leggere le note in fondo alla pagina. Inoltre, nella sezione “Lezioni“, è possibile trovare altro materiale sugli standard PHPFIG.

PSR-1: in breve

• I file PHP DEVONO usare solo i tag <?php e <?=,
• DEVONO usare solo la codifica UTF-8 priva di BOM,
• DOVREBBERO dichiarare classi, funzioni, costanti, … OPPURE DOVREBBERO eseguire altri tipi di azioni logiche come generare output, modificare parametri di configurazione del php.ini, includere file … ma NON DOVREBBERO fare entrambe le cose.
• I Namespaces e i Class Names DEVONO seguire lo standard per “autoloading” PSR-4: una sola classe in un solo file, namespace di almeno un livello indicante il vendor-name.
• I Class Names DEVONO essere dichiarati in StudlyCaps.
• Le costanti DEVONO essere dischiarate in maiuscolo utilizzando l’underscore come separatore.
• I nomi dei metodi DEVONO essere dichiarati in camelCase.

PSR-1: files

PHP Tags

Il codice PHP deve essere dichiarato attraverso i tag <?php ?> oppure gli short-echo <?= ?> tags. NON DEVE utilizzare altre varianti di tag dichiarativi (es: <? ?>).

Codifica dei caratteri

Il file PHP DEVE utilizzare solo la codifica UTF-8 ed essere privo di BOM.

Dichiarazioni ed effetti collaterali (side effects)

Un file DOVREBBE dichiarare nuovi “simboli” (classi, funzioni, costanti, …) senza causare altri “effetti collaterali” OPPURE DOVREBBE eseguire una logica con effetti collaterali, MA NON DOVREBBE fare entrambe le cose.

Lo standard spiega che l’espressione “effetti collaterali” (side effects) indica l’esecuzione di una logica non direttamente correlata alla dichiarazione di classi, funzioni, costanti, ecc, ma correlata direttamente all’inclusione del file stesso.

Vengono poi fatti alcuni esempi di “effetti collaterali” a titolo esemplificativo: generazione di output, uso esplicito di require o include, connessione a servizi esterni, modifica di parametri del php.ini, generazione di errori o eccezioni, modifica di variabili statiche o globali, lettura/scrittura di file, …

Ecco un esempio di file non conforme allo standard con la coopresenza di dichiarazioni ed “effetti collaterali”.

<?php
// effetto collaterale: cambio ini setting
ini_set('error_reporting', E_ALL);

// effetto collaterale: carico un file
include "file.php";

// effetto collaterale: genero output
echo "<html>\n";

// dichiarazione una funzione
function foo() {
    // function body
}

Il seguente esempio mostra un file conforme allo standard contenete solo delle dichiarazioni:

<?php
// dichiarazione una funzione
function foo() {
    // function body
}

// la dichiarazione condizionale non è un effetto collaterale.
if (! function_exists('bar')) {
    function bar() {
        // function body
    }
}

PSR-1: namespace e class names

I namespaces ed i class names DEVONO essere conformi ad allo standard per l’autoloading PSR-4.

Ciò significa che ogni classe DEVE essere dichiarata in un file dedicato e DEVE trovarsi in un Namespace di almeno un livello indicante il vendor-name, in pratica l’indicazione dello sviluppatore.

I class names DEVONO essere dichiarati in StudlyCaps.

ll codice scritto da PHP 5.3 in avanti DEVE utilizzare namespaces formali.

<?php
// PHP 5.3 e successivi:
namespace Vendor\Model;

class Foo {
  // Class body
}

Il codice scritto per PHP 5.2 e versioni precedenti DOVREBBE usare la convenzione pseudo-namespacing con prefissi Vendor_ nei nomi delle classi.

<?php
// PHP 5.2.x e versioni precedenti:
class Vendor_Model_Foo {
  // Class body
}

PSR-1: costanti di classe, proprietà e metodi

Il termine “class” si usa qui in senso più ampio per riferirsi a tutte le classi, le interfacce ed i traits.

Costanti

Le costanti di classe DEVONO essere dischiarate in maiuscolo utilizzando l’underscore come separatore. Personalmente applico questa regola a tutte le costanti comprese quelle definite con define().

<?php
namespace Vendor\Model;

class Foo {
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';
}

Proprietà

Lo standard evita intenzionalmente di fornire consigli riguardanti l’uso dei nomi di prorpietà $StudlyCaps, $camelCase, or $under_score property names.

Qualunque sia la convenzione di denominazione utilizzata DOVREBBE essere applicato in modo coerente.

Metodi

I nomi dei metodi DEVONO essere dichiarati in camelCase().

PSR1 nel lavoro di tutti i giorni

Il nuovo framework CoreBox che stiamo sviluppando alla Communication Box adererisce perfettamente allo standard PSR1. Questo facilita notevolmente lo sviluppo poiché ogni componente del team trova sempre una certa familiarità nel leggere il codice scritto dai colleghi.

Note

Quando si legge un documento del PHP-FIG le parole DEVE (MUST), NON DEVE (MUST NOT), RICHIESTO (REQUIRED), POTRÀ (SHALL), NON POTRÀ (SHALL NOT), DOVREBBE (SHOULD), NON DOVREBBE (SHOULD NOT), RACCOMANDATO (RECCOMANDED), PUÒ (MAY) e OPZIONALE (OPTIONAL) vanno interpretati secondo quanto descritto nel documento RFC 2119.

Lo stile StudlyCaps, noto anche come PascalCase, impone che la prima lettera di ogni parola sia in maiuscolo. Una stringa in questo stile deve iniziare sempre con la lettera maiuscola.

Lo stile camelCase, proprio come in un cammello, impone che le gobbe siano solo in mezzo. Una stringa in questo stile deve iniziare sempre con la lettera minuscola.

L'articolo PSR-1: regole per la scrittura di codice PHP sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Il Singleton pattern assicura che una sola istanza di una classe esista, fornendo un punto di accesso globale a tale istanza.

Il pattern Singleton impedisce la creazione di più istanze di una classe garantendo che ne esista solo una e fornisce un modo per accedere a quell’istanza unica da qualsiasi parte dell’applicazione.

Il singleton prevede tre elementi fondamentali:

• Costruttore privato: impedisce la creazione di istanze della classe dal di fuori della classe stessa.
• Variabile statica privata: mantiene l’istanza unica della classe. Deve essere privata per evitare che altri oggetti accedano ad essa direttamente.
• Metodo statico di accesso all’istanza: restituisce l’istanza unica della classe. Se l’istanza non esiste ancora, il metodo crea l’istanza e la restituisce, altrimenti restituisce semplicemente l’istanza esistente.

Scenari di utilizzo

Il pattern singleton può essere utilizzato quando un certo oggetto deve essere “unico” all’interno del nostro applicativo, per un ruolo di coordinamento o per ottimizzare le risorse. Ecco alcuni esempi concreti di utilizzo:

• Registro / Storage condiviso
• Log / Debug
• Connessione a DB persistente

Esempio di pattern Singleton in PHP

Vediamo ora il codice di base per implementare questo pattern.

class MySingleton {

    /**
     * Istanza unica del singleton
     * @var object
     */
    private static object $instance;

    /**
     * Costruttore privato per prevenire che venga istanziato da codice esterno.
     */
    private function __construct() {
        echo 'Faccio qualcosa...';
    }

    /**
     * Metodo pubblico per l'accesso all'istanza unica di classe.
     * @return object|MySingleton
     */
    public static function getInstance() {
        if ( !isset(self::$instance) ) {
            self::$instance = new MySingleton();
        }
        return self::$instance;
    }
}

Se proviamo ad istanziare due volte il singleton noteremo che il messaggio “Faccio qualcosa…” presente nel costruttore verrà mostrato una sola volta. poiché il sistema utilizzato per implementarlo garantisce l’unicità dell’istanza (oggetto).

Per rendere il codice più riutilizzabile possiamo apportare una piccola modifica all’interno del metodo getIstance() in modo che il nome della classe istanziata con new sia valorizzato automaticamente. Sfruttiamo la costante magica __CLASS__ che restituisce il nome della classe nella quale è richiamata.

if ( !isset(self::$instance) ) {
    $className = __CLASS__;
    self::$instance = new $className;
}

Vantaggi del design pattern singleton

• Garantisce una sola istanza: Il pattern Singleton garantisce che una sola istanza di una classe esista in un determinato momento, il che può essere utile in alcune situazioni, ad esempio per gestire le connessioni al database o le impostazioni globali dell’applicazione.
• Facile accesso globale: Il pattern Singleton fornisce un punto di accesso globale all’istanza unica, il che significa che possiamo accedere all’istanza ovunque e in qualsiasi momento senza dover preoccuparci di passare l’istanza esplicitamente a ogni parte dell’applicazione.
• Riduzione del consumo di memoria: Poiché una sola istanza esiste in un determinato momento, il pattern Singleton può aiutare a ridurre il consumo di memoria del sistema.

Svantaggi del design pattern singleton

Alcuni puristi della programmazione ad oggetti (OOP) possono storcere il naso quando si parla di singleton definendolo un anti-pattern. Le principali critiche al singleton sono le seguenti:

• Viola il Single Responsibility Principle (SRP) se crea delle dipendenze nei componenti che lo utilizzano. L’SRP vorrebbe infatti ogni componente assegnato ad una singola funzione o responsabilità.
• Difficile da testare poiché l’istanza unica esiste in tutta l’applicazione e non può essere facilmente sostituita con una mock o una versione di prova.
• Difficile da estendere poiché impone l’esistenza di una sola istanza di una classe in un determinato momento, può essere difficile estendere il pattern se si desidera introdurre più istanze della classe.
• Crea accoppiamento forte: poiché ogni parte dell’applicazione che utilizza il Singleton dipende dal suo stato globale.
• Viene utilizzato erroneamente per sostituire le variabili globali che, per definizione, non devono essere influenzate dall’applicativo.

Conclusioni

Il singleton si può rivelare molto utile in specifiche situazioni, ma non bisogna abusarne così come non bisogna abusare delle implementazioni statiche nella programmazione ad oggetti. Può essere utile valutare anche altri tipi di soluzioni come la Dependency Injectiono il pattern Factory.

Per un panoramica generale consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Singleton in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Progettare software ad oggetti è difficile, ma lo è ancora di più renderne i suoi componenti riutilizzabili. La scomposizione dell’applicativo in oggetti deve tener conto di molteplici fattori: incapsulamento, granularità, dipendenza, performance, ridondanza, riusabilità, modularità, estendibilità nel tempo.

I design pattern vengono in nostro soccorso indicandoci soluzioni a problemi ricorrenti così da rendere il nostro codice riutilizzabile e mantenibile.

La genesi

Il concetto di design pattern è stato mutuato dall’ingegneria del software direttamente dall’architettura. Fu l’architetto austriaco Cristopher Alexander a formalizzare tale concetto nel 1977 all’interno del libro Pattern Language: Towns, Buildings, Construction.

Il pattern è una soluzione architetturale che può risolvere problemi in contesti eterogenei.

La trasposizione del concetto di design pattern in ambito informatico è attribuita invece alla cosiddetta Gang of Four (GoF) formata da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Dopo quatro anni di confronto condensarono tutta la loro esperienza in un libro del 1994 che è diventato la “Bibbia della programmazione ad oggetti”: Design Patterns: elements of reusable object oriented software“ (Elementi per il riuso di software ad oggetti).

Il design pattern descrive un problema ricorrente e fornisce una soluzione che può essere riutilizzata infinite volte senza doverla applicare mai nello stesso identico modo

Design Pattern: classificazione

La GoF cataloga i suoi 23 pattern suddividendoli in 3 macro categorie:

• Pattern creazionali: soluzioni per creare oggetti.
• Pattern strutturali: soluzioni per la composizione strutturale di classi e oggetti.
• Pattern comportamentali: soluzioni per gestire le responsabilità delle classi e degli oggetti.

Una seconda classificazione viene fatta in base al loro ambito applicativo:

• Class pattern: soluzioni tramite classi e sottoclassi in relazioni statiche tra loro.
• Object Pattern: soluzioni dinamiche basate sugli oggetti.

Infine ogni pattern viene descritto in base agli elementi che lo caratterizzano:

• Nome/Alias: sintentizza l’essenza del pattern.
• Scopo: cosa fa il pattern.
• Motivazione: scenario del problema e soluzione offerta.
• Applicabilità: situazioni di esempio in cui si può usare il pattern.
• Struttura: rappresentazione grafica delle classi del pattern.
• Partecipanti: classi/oggetti interessati e relative responsabilità
• Collaborazioni: dei partecipanti per poter assumersi le responsabilità.
• Conseguenze: pro e contro del pattern.
• Implementazione: tecniche e consigli per implementare il pattern.
• Codice d’esempio: in C++ e SmallTalk.
• Utilizzi noti: esempi reali in sistemi esistenti.
• Correlazioni: legami con altri pattern e differenze.

I 23 pattern definiti dal GoF possono essere quindi così schematizzati:

Design Pattern: il catalogo della GoF

Riporto qui una sintesi del catalogo composto dai 23 design pattern in modo da avere un’idea di massima del loro utilizzo.
Ricordo che con il termine “interfaccia” si intende qui l’insieme delle richieste a cui un oggetto può rispondere cioè l’insieme delle proprietà e dei metodi pubblici di un oggetto. Attenzione quindi a non confondersi con le “interface” di Php!

• Abstract Factory: fornisce un’interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare o conoscere le classi concrete.
• Adapter: converte l’interfaccia di una classe in un’altra interfaccia richiesta dal client permettendo la collaborazione fra classi tra loro incompatibili.
• Bridge: disaccoppia un’astrazione dalla sua implementazione in modo che le due possano variare indipendentemente.
• Builder: separa la costruzione di un oggetto complesso dalla sua rappresentazione così che lo stesso processo di creazione possa creare rappresentazioni diverse.
• Chain of Responsability: disaccoppia il mittente di una richiesta dal suo destinatario. Si ordinano gli oggetti destinatari e la richiesta viene passata di oggetto in oggetto finché non viene gestita.
• Command: incapsula una richiesta in un oggetto.
• Composite: raggruppa oggetti in strutture ad albero permettendo ai client di trattare oggetti singoli e raggruppamenti in modo uniforme.
• Decorator: aggiunge dinamicamente responsabilità ad un oggetto. E’ un’aternativa flessibile all’ereditarietà.
• Facade: definisce un’interfaccia di più alto livello per facilitare l’utilizzo di un sottosistema più complesso.
• Factory Method: permette ad una classe di delegare la creazione di un oggetto alle sue sottoclassi.
• Flyweight: usa la condivisione per gestire numerosi oggetti a granularità fine.
• Interpreter: permette di implementare un proprio linguaggio con la sua grammatica ed il relativo interprete.
• Iterator: permette di accedere agli elementi di un contenitore sequenzialmente senza esporre la struttura sottostante.
• Mediator: favorisce un basso accoppiamento evitando che gli oggetti facciano riferimento l’un l’altro.
• Memento: esplicita lo stato interno di un oggetto così da poterlo riportare al suo stato originale.
• Observer: definisce una dipendenza uno-a-molti fra oggetti così che quando un oggetto cambia stato tutti gli oggetti dipendenti vengano notificati ed aggiornati.
• Prototype: specifica gli oggetti da creare utilizzando un’istanza prototipale.
• Proxy: fornisce un surrogato di un oggetto pper controllare l’accesso a quest’ultimo.
• Singleton: forza una classe ad avere una sola istanza e ne fornisce un accesso globale.
• State: permette ad un oggetto di modificare il proprio comportamento quando il suo stato interno cambia. Sembrerà che l’oggetto abbia cambiato la sua classe.
• Strategy: definisce una famiglia di algoritmi, li incapsula e li rende interscambiabili tra di loro.
• Template Method: definisce lo scheletro principale dell’algoritmo in un metodo delegando alcuni passi alle sottoclassi.
• Visitor: permette di definire nuove operazioni senza cambiare le classi degli elementi su cui opera.

Riferimenti

Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Pearson Education

https://designpatternsphp.readthedocs.io

https://refactoring.guru/design-patterns

L'articolo Design Pattern GoF – Guida sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.