Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22028 > unrolled thread

core o lib?

Back to article view | Back to it.comp.www.php

Contents

  core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-11 21:05 +0200
    Re: core o lib? fmassei@gmail.com - 2018-05-11 12:27 -0700
      Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-11 22:09 +0200
        Re: core o lib? fmassei@gmail.com - 2018-05-11 13:23 -0700
          Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-11 22:26 +0200
            Re: core o lib? fmassei@gmail.com - 2018-05-11 13:35 -0700
              Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-11 22:39 +0200
                Re: core o lib? fmassei@gmail.com - 2018-05-11 14:46 -0700
                  Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-12 12:33 +0200
                    Re: core o lib? Alessandro Pellizzari <shuriken@amiran.it> - 2018-05-12 15:38 +0100
                      Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-12 17:42 +0200
                        Re: core o lib? Alessandro Pellizzari <shuriken@amiran.it> - 2018-05-13 09:21 +0100
                          Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-13 21:05 +0200
                            Re: core o lib? fmassei@gmail.com - 2018-05-13 12:42 -0700
                            Re: core o lib? Alessandro Pellizzari <shuriken@amiran.it> - 2018-05-14 10:19 +0100
                              Re: core o lib? alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-05-14 11:46 +0200

#22028 — 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?

[toc] | [next] | [standalone]

#22029

On Friday, May 11, 2018 at 3:08:42 PM UTC-4, alex wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#22030

Il 11/05/2018 21:27, fmassei@gmail.com ha scritto:
> Se levi una "lib" funziona ancora tutto (a parte quello che fa la lib).
> 

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

[toc] | [prev] | [next] | [standalone]

#22031

On Friday, May 11, 2018 at 4:13:24 PM UTC-4, alex wrote:
> Il 11/05/2018 21:27, fmassei@gmail.com ha scritto:
> > Se levi una "lib" funziona ancora tutto (a parte quello che fa la lib).
> > 
> 
> 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!

[toc] | [prev] | [next] | [standalone]

#22032

Il 11/05/2018 22:23, fmassei@gmail.com ha scritto:
> Solo se un'altra lib

Certo.
Il core cmq non dovrebbe mai richiedere una lib, giusto?
Una lib invece può richiedere *qualcosa* al core?

> o l'applicativo finale la richiedeva.

Cioè?

[toc] | [prev] | [next] | [standalone]

#22033

On Friday, May 11, 2018 at 4:29:40 PM UTC-4, alex wrote:
> Il 11/05/2018 22:23, fmassei@gmail.com ha scritto:
> > Solo se un'altra lib
> 
> Certo.
> Il core cmq non dovrebbe mai richiedere una lib, giusto?

In teoria no.

> Una lib invece può richiedere *qualcosa* al core?

Certo.

> > o l'applicativo finale la richiedeva.
> 
> Cioè?

se con lib/core parlavi di framework, la roba che sviluppi te.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22034

Il 11/05/2018 22:35, fmassei@gmail.com ha scritto:
>>> o l'applicativo finale la richiedeva.
>> Cioè?
> 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?

[toc] | [prev] | [next] | [standalone]

#22035

On Friday, May 11, 2018 at 4:42:44 PM UTC-4, alex wrote:
> Il 11/05/2018 22:35, fmassei@gmail.com ha scritto:
> >>> o l'applicativo finale la richiedeva.
> >> Cioè?
> > 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!

[toc] | [prev] | [next] | [standalone]

#22036

Il 11/05/2018 23:46, fmassei@gmail.com ha scritto:
>> Invece un'app non dovrebbe avere librerie, solo un core ed eventuali
>> vendors?
>>
> Quello dipende dalla app, impossibile dirlo in generale.
> 

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?

[toc] | [prev] | [next] | [standalone]

#22037

On 12/05/18 11:33, alex wrote:

> 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?

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.

[toc] | [prev] | [next] | [standalone]

#22039

Il 12/05/2018 16:38, Alessandro Pellizzari ha scritto:
> Se non stai facendo un'app "estendibile" non ti serve niente. Usa solo

App estensbile?
Forse mi sbaglio ma in genere si possono estendere solo framework e 
librerie.

> src per i sorgenti, vendor per i componenti presi da composer, e public

si

> per la directory che esporrai al webserver.

Ma solo se si tratta di una web-app.

> Ed eventualmente bin per gli script da linea di comando (tipicamente
> 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*?

[toc] | [prev] | [next] | [standalone]

#22042

On 12/05/18 16:42, alex wrote:

> Il 12/05/2018 16:38, Alessandro Pellizzari ha scritto:
>> Se non stai facendo un'app "estendibile" non ti serve niente. Usa solo
> 
> App estensbile?
> Forse mi sbaglio ma in genere si possono estendere solo framework e 
> librerie.

Pura semantica, ma volendo stare al gioco, una libreria non dovrebbe
essere estendibile. Un framework sì. Un CMS (che è un'applicazione) anche.

>> Ed eventualmente bin per gli script da linea di comando (tipicamente
>> 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?

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.

[toc] | [prev] | [next] | [standalone]

#22051

Il 13/05/2018 10:21, Alessandro Pellizzari ha scritto:
> Io eviterei core e lib completamente, e userei solo src e vendor (più
> 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 :)

[toc] | [prev] | [next] | [standalone]

#22052

On Sunday, May 13, 2018 at 3:09:20 PM UTC-4, alex wrote:
> Il 13/05/2018 10:21, Alessandro Pellizzari ha scritto:
> > Io eviterei core e lib completamente, e userei solo src e vendor (più
> > 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!

[toc] | [prev] | [next] | [standalone]

#22056

On 13/05/2018 20:05, alex wrote:

> 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.

[toc] | [prev] | [next] | [standalone]

#22057

Il 14/05/2018 11:19, Alessandro Pellizzari ha scritto:
>>
> 
> 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.

Ok, valuterò, grazie a tutti per i consigli :)

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web