[risolto] php include

[eaghezzi]

c'è un modo per verificare se il file filename verrà effettivamente incluso
ovvero
include filename; dunzionerà ?

tute le funzioni di controllo file es file_exists(),is_file,is_readable() .. non sono adeguate
vogliono il path
include cerca il file nel path corrente e nell'include path
l'unico modo che ho trovato è di controllare manualmente esplodendo get_include_path()
non è molto comodo

[crap0101]

ci sarebbe http://php.net/manual/en/function.get-i ... -files.php
un pò più comoda, ma forse non ti cambia così tanto.

[eaghezzi]

purtroppo se include non trova il file genera un warning , try/catch non l'ho intercetta
l'unico modo è di sopprimere l'errore con @include e poi controllare se file è nell'elenco di quelli inclusi
non so qual'è +brutto

[Zoff]

Partendo dal presupposto che non si dovrebbe mai affidare la logica applicativa agli include e che, per questo motivo, si dovrebbe sapere sempre esattamente dove si trova un file che si include il problema non è in come fare quello che vuoi fare ma proprio nell'approccio che stai tenendo.
Nel 2015 vedere applicazioni affidarsi ad "include dinamici" dovrebbe far venire il mal di pancia.
Suggerisco molto caldamente di affidarsi ad approcci ben piu' ortodossi come l'utilizzo dell'autoload e degli standard PSR-X, almeno almeno PSR-1.

Per rispondere alla domanda comunque:

Codice: Seleziona tutto

$included = @include('quello che vuoi');
if( $included ){
    echo "File included correctly!";
}else{
    echo "File inclusion FAILED!";
}

[SuperStep]

composer e' un manager delle dipendenze molto affidabile. https://getcomposer.org/

automaticamente provvede a caricarti le classi che sono dichiarate negli autoload.

[eaghezzi]

Avete ragione infatti è così le app utilizzano sia PSR-X che composer sono così organizzate

.../.../public/ virtual document root index.php js css html files 'pubblici'
.../.../src/ sorgenti,namespaces e lib terze parti
vendor
namespace(a,b,c)


ed utilizzano l'autoloading

il problema nasce proprio qui
sulle diverse macchine dove vengono installate le app server di sviluppo,...di produzione ....

c'è la necessità di utilizzare un name space che contiene diverse classi di helper
che è posizionato ogni volta in una dir diversa fuori dal tree dell'app

le uniche info che posso usare sono il path_to_ext_lib ed il nome del namespace

volendo generalizzare pensavo di fare così:

Codice: Seleziona tutto

set_include_path(get_include_path().PATH_SEPARATOR.'path_to_ext_lib');
splregister_autoload(array($kernel,'autoloader'));

function autoloader($className){
	//splitto className in nomeClasse nomeNamespace
	if(nomeNamespace=='name space xtlib'){
		require_once $path_to_ext_lib.$nomeClasse.'.cls.php';
	}
	else{
		//replace'\',''
		require_once   $nomeNamespace.PATH_SEPARATOR.$nomelasse.'.cls.php';
	}

}

e cmq controllare prima le require

[Zoff]

che è posizionato ogni volta in una dir diversa fuori dal tree dell'app

perché mai? Scelta bizzarra.

Comunque in un qualche momento dovrà essere effettuato il deploy dell'applicazione su ogni macchina no? Basta inserire il path della macchina specifica nel suo script di deploy.

In realtà se davvero state usando composer non capisco perché non lo usate per tutte le dipendenze.

[eaghezzi]

mi capita di dover installare diverse library con composer nello stesso progetto php,
ogni library ha il proprio compser.json
qual'è il metodo da seguire per installarle ?

[Zoff]

Dare il comando:

Codice: Seleziona tutto

php composer.phar require nomelibreria

Trattandosi di un argomento praticamente identico unisco alla discussione "php include".

[eaghezzi]

usiamo composer per le lib standard / frameworks che già hanno il composer.json
e si siamo pigri e/o non abbiamo mai tempo

scelta strana è vero così facendo abbiamo un .ini con 'solo' 2,3 parametri da cambiare di cui uno il path.

[Zoff]

Quindi da qualche parte l'informazione sul Path c'è... Basta leggerla da lì

[eaghezzi]

esatto
il mio ragionamento è il seguente
spl_autoload_register() in implementazione std non riconosce correttamente maiuscole,minuscole nei file system come linux quindi non riesce a risolvere correttamente l'asociazione \namespace\classe con il relativo file quindi scrivo un autoloader custom che mantiene il corretto case
uso come root namespace .../.../src cui aggancio sub dir <namespace...a,b,c>
all'include path aggiungo il path delle librerie esterne
a questo punto
se classname contiene il namespace delle lib ext lo strippo la require troverà il nome file della classe perchè nell'include path
se classname ha un altro name space converto backslash in slash e troverò cmq il file della classe nella subdir del namespace

quello che volevo fare è un controllo preventivo per evitare errori alla fine sono riuscito trovare la funzione

Codice: Seleziona tutto

string stream_resolve_include_path ( string $filename )

non solo verifica se $filename verrà incluso ma torna il full path risolto (sempre sulla base dell include_path)

[Zoff]

Io ancora non ho capito una cosa, se usate composer e le librerie sono conformi agli standard PSR, perché non passate semplicemente il path della libreria nella configurazione di composer?

[eaghezzi]

le app sviluppate sono conformi, le lib standard che usiamo 'twig','silex' e qualche orm anche
tutto tranne queste lib 'legacy' che sono fuori dal ns 'dominio'
così facendo è sufficiente avere nel .ini il path del resto non si tocca nulla
tutte le app che sviluppiamo hanno un set di classi base più quelle nuove specifiche per ogni app, il resto possibilmente non si tocca.
sembra essere più un problema 'politico' che tecnico
ahimè la vita è così

[Zoff]

Questo però non risponde all'ultima domanda.
Perché non configurate le librerie legacy in composer?

[eaghezzi]

pur non essendo la situazione migliore e concordo, piace di più l'idea di modificare un parametro nell'ini, attività che può essere fatta in qualunque momento di vita dell'app e sopratutto senza modificare alcun file sorgente, json compreso.

[Zoff]

Mi sfugge perché un file json è considerato sorgente e un file ini no.
JSON non è un linguaggio di programmazione, può essere utilizzato solo per rappresentare dati.

Comunque se con l'if che ti ho suggerito hai risolto scrivilo nel titolo.

[eaghezzi]

anche a me
opero in un contesto molto strutturato i programmatori sono responsabili del loro codice
tutto il resto è fatto da altri
la gestione del versioning dal pm
il db e l'ambiente di esecuzione dai sistemisti
pubblicazione e rilascio sono del pm
che personalizza il .ini

il pm non conoscendo json probabilmente pensa che sia codice quindi ricade sotto la responsabilità del prg.

detto questo rivediamo insieme la soluzione per verificare se un file verrà effettivamente incluso

Codice: Seleziona tutto

<?php
    /* bene riepilogando per testare se il $filename verrà incluso 
	 * con include o require vedere la funzione can_include
	 */
	 
	 
	 function can_include($filename)
	 {
	 	//metodo proposto da Zoff che testa l'errore
	 	$included = @include($filename);
		
		//utilizzo funzione php 
		$included=(stream_resolve_include_path ($filename )!==FALSE);
		
		return $included;
		 
	 }
?>

mi piace molto la funzione stream_resolve_include_path perchè in caso positivo torna il full path del file.

Grazie a tutti.

[Zoff]

Il nome della funzione è fuorviante, la funzione non controlla se un file è stato importato ma tenta di importarlo e ti restituisce un booleano che indica se il file è nell'include path.

[eaghezzi]

questa volta non sono daccordo
la funzione fa esattamente quello che dice il nome
stream_resolve_include_path($filename)

se $filename è nell'include path e quindi verrà incluso (quando richiesto con require o include)
ritorna il path

altrimenti ritorna ===FALSE

non volevo una funzione per includere un file, ma una funzione per controllare se il file sarebbe stato incluso senza generare errori.
tenendo presente che si può farlo canonicamente basta esplodere get_include_path() e controllare ogni singola dir con le funzioni
di filesystem apposite come is_readable(),is_file ()...