Newsgroup: it.comp.www.php
Titolo: core o lib?

In molti progetti (applicazioni o framework) vedo che oltre alla 
directory lib, c'è anche la dir. core.
Di solito cosa deve stare dentro questa dir.?
Classi che devono essere modificate solo in casi eccezionali (che 
possono compromettere il funzionamento o la struttura del progetto)?
O magari solo classi astratte, traits e interfacce (e tutte le classi 
ereditate nella dir. lib)?
Insomma quel'è la scuola di pensiero più comune?


Se levi una "lib" funziona ancora tutto (a parte quello che fa la lib).
 
 
Ciao!

 
 
Se levo una lib (una libreria, non un plugin) però in genere provoco un 
catastrofico *class not found*.


Solo se un'altra lib o l'applicativo finale la richiedeva.
 
Ciao!

 o l'applicativo finale la richiedeva.
 
Cioè?

 Cioè?
 
se con lib/core parlavi di framework, la roba che sviluppi te.
 
 
Ciao!

 se con lib/core parlavi di framework, la roba che sviluppi te.
 
Invece un'app non dovrebbe avere librerie, solo un core ed eventuali 
vendors?


Quello dipende dalla app, impossibile dirlo in generale.
 
 
Ciao!

 
 
Fammi capire.
Ad esempio ho un app strutturata così:
 
bin/ # script eseguibili
core/ # componenti principali
lib/
vendor/ # librerie di terze parti
 
In lib/ cosa andrebbe messo, o meglio, in quali casi un'app dovrebbe 
avere librerie?

 avere librerie?
 
Una directory core di solito la usano i CMS o i framework per dire
"questi sono i pezzi fondamentali dell'applicazione. Senza questi non
funziona niente".
 
In lib (o plugins, o addons o un milione di altri nomi) ci sono i pezzi
opzionali. Se non ci sono, funziona lo stesso. Se ci sono fanno qualcosa
in più. Se li togli, di solito devi farlo nell'ordine giusto e togliendo
le config dai posti giusti.
 
Se non stai facendo un'app "estendibile" non ti serve niente. Usa solo
src per i sorgenti, vendor per i componenti presi da composer, e public
per la directory che esporrai al webserver.
 
Ed eventualmente bin per gli script da linea di comando (tipicamente
migration del DB, script di sincronizzazione, cron jobs, ecc. ecc.)
 
Bye.

 migration del DB, script di sincronizzazione, cron jobs, ecc. ecc.)
 
Quindi ad es. ho due script (a.php e b.php) che devono accere alla 
funzione console_verbose() memorizzata nel file console.php.
 
a.php e b.php li metto in *bin*.
 
Mentre console.php dove lo metto?
In *lib*?
In *core*?

 Mentre console.php dove lo metto?
 
Cosa è "console.php"? Una classe (= libreria) che fornisce solo funzioni
di utilità? Allora forse va in core, forse in lib, forse in vendor (da
un pacchetto esterno)
 
È qualcosa che puoi lanciare da riga di comando? Allora va in bin e non
dovrebbe esportare funzioni usate da altri.
 
Onestamente trovo la discussione troppo fumosa. Ogni progetto va
organizzato in base a quello che serve a te e al tuo team.
 
Cercare di capire dal nome di un file o di una directory cosa dovrebbe
fare è un esercizio inutile.
 
Io eviterei core e lib completamente, e userei solo src e vendor (più
public e bin, come ho detto, se serve).
 
Quando fai una libreria, la metti in un pacchetto a parte che includi
tramite composer.
 
Bye.

 public e bin, come ho detto, se serve).
 
Io invece in src ci metto tutto il progetto.
 
Io parto sempre con due dir.: src e tests.
In scr, il progetto vero e poprio.
In tests (che replica più o meno la stessa struttura di src) invece ci 
sono i vari test.
Poi eventualmente c'è vendor (per le libreie di terze parti), docker 
(ambiente virtualizzato per fare i test).
Dopo di che nella root non ci deve essere più nient'altro.
 
Quindi se scendo in src, ho le dir. bin, config, web, resources.
Poi ci sono le solite famigerate parti di codice (classi per lo più) che 
in genere vengono richieste da varie parti dell'app; dove li metto?
Tu li metti in src, tale dir invece la uso per mettere tutto il 
materiale di produzione.
Quindi boh :)


Come ha già scritto Alessandro tra le righe, dipende dal flow del tuo team
o, se sei da solo, da quello che tu stesso ti imponi.
 
Teoricamente nessuno t'impedisce di spargere i file su tutto il disco in
maniera casuale, così come nessuno t'impedisce di metterli tutti in una
cartella.
 
Chiaro che la struttura core/ lib/ app/ etc. è più o meno standard, quindi
aiuta sia gli sviluppatori (per non perdersi nel codice), che i tool OOTB,
e.g. gli autoloader standard (tipo quello di composer). Quindi perché no.
 
Alla fine sta sempre a te che crei progetto definirne anche la struttura,
quindi pensa un po' a tutti i tuoi requisiti e trova quella che meglio si
adatta al tuo caso. Non è che i progettisti son pupazzi, alle volte devono
anche pensare ;)
 
 
Ciao!

 Io invece in src ci metto tutto il progetto.
 
Questo è quello che si avvicina di più a quello che faccio io:
 
https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
 
 
Per un sito, di solito in public/index.php c'è solo l'include di 
composer, il new del componente App (o Router, o quello che è) e l'avvio 
dell'applicazione.
 
In src ho solo un file per classe PHP (con namespaces, naturalmente)
 
Quello che lui chiama templates io lo chiamo views, e quello che chiama 
resources di solito lo chiamo assets, ma l'idea è la stessa.
 
Bye.
 

 resources di solito lo chiamo assets, ma l'idea è la stessa.
 
Ok, valuterò, grazie a tutti per i consigli :)