L'applicazione richiede una specifica versione di PHP, ma il codice per verificare se la versione è adeguata non può essere eseguito se la versione non è adeguata (problema di pollo e uova)

4

Un framework che sto scrivendo (per l'apprendimento) richiede una versione PHP specifica per l'esecuzione, quindi sto implementando un "controllo versione PHP" per garantire che la versione in PHP sia il minimo richiesto per il quadro.

Impostazione di base

htaccess reindirizza tutto a index.php (front controller);
index.php carica bootstrap.php (nient'altro);
bootstrap.php carica i componenti principali (impostazione di visualizzazione degli errori, registrazione degli errori, impostazioni dell'utente, quindi instrada l'URI richiesto);

Problema

Se la versione controllo codice o qualsiasi cosa caricata prima richiede una versione PHP superiore a quella in esecuzione, il controllo stesso e qualsiasi cosa prima fallirà.

Opzione grezza

Il caricamento del codice di controllo della versione prima funzionerebbe, ma il framework ha una struttura logica, con classi in luoghi specifici chiamati come necessario con SPL e DI. E per farlo funzionare dovrebbe essere un condizionale di base in index.php (front controller), ma sto cercando di evitarlo perché:

  1. index.php non è un posto per tale codice
  2. Non avrà accesso ad altre funzionalità del framework e output non sarebbe attraverso il modello di struttura ma un messaggio non elaborato: %codice%
  3. La versione richiesta di PHP (ad esempio "50400") è "config" e dovrebbe vivere in exit('invalid PHP version'); . Aggiornamento / gestione del richiesto la versione non è l'ideale in index.php

Inoltre, il codice di controllo della versione ha un requisito di versione PHP.
per esempio. Il controllo utilizza core/config/ per ottenere la versione PHP corrente in esecuzione, che richiede PHP 5.2.7.
Potrei usare un altro metodo, ma in realtà poi sto accumulando tutti i tipi di codice in index.php, e non dovrebbe essere così.

Quindi il codice che viene prima caricato in index.php ed essendo un condizionale mi fa rabbrividire, come dovrebbe essere una bella classe che chiama Core config (etc) e non appartiene come questo in front controller come condizionale a basso costo.
Ma forse non ho scelta.

Ad esempio, il primo codice in index.php (quindi il primo codice da eseguire prima di ogni altra cosa):

if (!defined('PHP_VERSION_ID') || (PHP_VERSION_ID < 50400)) {
  exit ('Insufficient PHP Version');
}

Non riesco davvero a vederlo in questo modo, dato che con le classi (ecc.) il framework ha bisogno di una certa versione di PHP per arrivare anche a una classe per controllare la versione, e se la versione è troppo bassa avrà un errore e anche la classe di controllo della versione non verrà eseguita.
È il problema del "pollo e dell'uovo".

Domanda

Sto cercando una soluzione su come risolvere questo problema, in termini di una migliore architettura software e approccio alla progettazione.
Oppure, sono bloccato come penso di essere perché la funzionalità viene eseguita prima che il controllo della versione significhi un potenziale errore dell'applicazione?

O ..

Sto cercando di risolvere qualcosa che non ha bisogno di essere risolto?
E invece basta solo dichiarare "Questo framework ha bisogno di PHP v X.X.X, l'esecuzione su una versione più bassa porterà problemi".

    
posta James 12.07.2015 - 21:50
fonte

1 risposta

4

Partire dall'ultima domanda, documentare i requisiti del framework è un must, ma avere il controllo della versione sarà utile a chi è abbastanza sciocco da non leggere la documentazione.

Avere la versione minima come opzione configurabile non ha senso, poiché la versione minima è una proprietà intrinseca del codice stesso, non qualcosa di esterno al codice che potrebbe variare da sito a sito. È nella stessa categoria del numero di versione del framework, della licenza e del sito Web principale (sebbene queste siano tutte proprietà estrinseche). Se sposti la versione minima dalla configurazione ai metadati del pacchetto, il problema diventa molto più semplice.

Poiché il controllo della versione è parte dell'inizializzazione del framework, ha senso aggiungerlo allo script di inizializzazione "bootstrap.php", sia inline che chiamando qualche funzione o metodo con i controlli di integrità. Quest'ultima sarebbe una buona scelta se altri requisiti, come per le estensioni non core, esistono o sono suscettibili di apparire.

Un altro progetto ragionevole è quello di aggiungere controlli dei requisiti alla procedura di installazione, se ce n'è uno. Si tratta di un'ottimizzazione (non c'è bisogno di controllare i requisiti con ogni richiesta di pagina) e ha un senso concettuale, poiché l'installazione è l'inizializzazione globale. Ciò presuppone che la configurazione del server in merito ai requisiti del framework non cambierà o che qualsiasi modifica apportata non influirà sui requisiti (ad esempio, i requisiti di versione sono solo per versioni minime e nessun componente verrà declassato), che sono abbastanza ragionevoli ipotesi (fino a quando PHP-next capita di venire in giro). Se non si desiderano queste ipotesi, è possibile aggiungere un modulo fingerprinting del server in base ai requisiti. Se l'impronta digitale cambia, il server è cambiato e i controlli dei requisiti vengono rieseguiti. Il controllo delle impronte digitali può essere eseguito su richiesta per tutte le pagine o solo per le pagine di amministrazione. Ovviamente, il calcolo delle impronte digitali & il controllo può essere più costoso del controllo dei requisiti, quindi potrebbe non offrire alcun vantaggio.

Il controllo dei requisiti potrebbe essere gestito durante l'installazione o l'inizializzazione per richiesta è un buon supporto per l'argomento che i controlli stessi dovrebbero essere in un modulo separato, piuttosto che in linea.

Il problema rimanente è come gestire l'errore di controllo della versione in base alle migliori pratiche. Poiché bootstrap.php non dovrebbe preoccuparsi di visualizzare nulla, dovrebbe solo rilevare la versione. La visualizzazione di un messaggio di errore dovrebbe essere lasciata ad alcuni componenti del framework. Per evitare un altro ciclo di dipendenza, è possibile progettare un componente con requisiti minimi che gestisca gli errori fatali (come errori dei requisiti, errori del database e simili) caricati dalla prima cosa di bootstrap. Questo potrebbe far parte del controller, se ha (o può essere fatto per avere) requisiti minimi.

    
risposta data 13.07.2015 - 00:59
fonte

Leggi altre domande sui tag