Newsgroup: it.comp.www.php
Titolo: piu' siti basati su un unico framework

salve a tutti!!!
Se devo costruire un sito basato ad esempio sul framework CakePhp, 
inserisco tutti i vari file (controller, model, view, ecc.) nelle 
apposite directory (in pratica estendo il framework).
Ma se devo costruire un secondo sito basato sempre sullo stesso 
framework, come si fa?
In pratica devo scaricare una seconda copia del framework, e quindi 
estenderlo come ho fatto per il primo sito?
E se devo fare un terzo sito, devo utilizzare una terza copia?
Non mi pare una soluzione ideale...
 
In pratica, almeno sulla macchina locale, come si può evitare la 
duplicazione del framework originale?


Con un link... :/
 
Ciao!

 Con un link... :/
 
Link inteso come collegamento ipertestuale?
Link inteso link simbolico sul file-system (si può fare solo in ambienti 
*nix)?
 
Hai detto poco...


Fammi capire, fai siti internet e non sai cos'è o come si usa un symlink?
Stiamo messi bene...
 
Ciao!

*nix)?
 
AFAIK, e' possibile anche su NTFS.
 
Leonardo
 
-- 
A stultis ex omnibus gentium varie pictis
A sanctae fidei adeptis, ab eorum odore;
AB insanis Iacobinis, ab eorum ardore
AB idolatris et martyribus odii et terroris;
A paradisi fautoribus dicentibus "est pro amore",
A manichaeis ululantibus "Nisi nobiscum prodes";
LIBERA, libera, libera, libera nos, Domine.


 
è molto che non uso win, non sapevo che le ultime versioni avessero 
mklink, bene!!!
 

 Stiamo messi bene...
 
Leggi l'altro post, è stai tranquillo, che nessuno può sapere tutto di 
tutto.
 

 è stai tranquillo, che nessuno può sapere tutto di tutto.
 
Io sto tranquillissimo, ma fossi in te invece di mettermi a scrivere siti
inizieri a studiare qualcosina più di base... altrimenti non vedo come puoi
andare avanti!
 
Ciao!


non so cake ma con zend sia 1 che 2 il framework lo puoi mettere dove ti 
pare, anche in una dir non del progetto.
 
io ad esempio ho il framework nella webroot
 
/var/www/htdocs/Framework
 
e i progetti nelle sue dir
 
 
/var/www/htdocs/progetto1
/var/www/htdocs/progetto2
/var/www/htdocs/progetto3
 
 
init_autoloader.php
 
if (is_dir('/var/www/htdocs/Framework/ZF2/library')) {
     $zf2Path = '/var/www/htdocs/Framework/ZF2/library';
} elseif (getenv('ZF2_PATH')) {      // Support for ZF2_PATH environment 
variable or git submodule
     $zf2Path = getenv('ZF2_PATH');
} elseif (get_cfg_var('zf2_path')) { // Support for zf2_path directive value
     $zf2Path = get_cfg_var('zf2_path');
}
 
Ciao

mklink, bene!!!
 
Le ultime hanno proprio il symlink, prima ti dovevi "contentare" delle
junction.
 
http://en.wikipedia.org/wiki/NTFS_symbolic_link
 


 andare avanti!
 
Come sopra
 

 }
 
Grazie.


 
Ma per uploadare sul server remoto *solo* le directory di produzione 
(escludendo ad esempio test/, dev/, pending/, esperimenti/, 
git_branches/, ecc.) di solito come ci si organizza?
Si mette il tutto *materiale di produzione* in un'apposita directory 
(prod/)?

(prod/)?
 
Beh, il mio framework si collega da sé a SVN e sa cosa fare :-D
 
Altrimenti, tutti i sistemi di upload hanno dei filtri di esclusione, a volte
anche per categorie (--no-dot-files, --no-[csv|svn|git|tla-rcs].



visto che citi git, di solito "git archive" torna utile (fa un archivio
escludendo i .git e tutto quello che è in .gitignore).
 
Personalmente appena inizio un progetto scrivo anche uno script che, tra le
altre cose, fa un rsync di quello che serve.
Preferisco lo script perché di solito prima e dopo il deploy devi comunque
fare un sacco di cose (far correre i test, gli script di update del db se
presenti, script aggiuntivi per aggiunta/rimozione di roba sul filesystem,
etc.etc.)
 
Ciao!

 Non mi pare una soluzione ideale...
 
E invece lo è, sul lungo termine.
 
So che è uno spreco di spazio, e all'epoca anche io ho fatto il tuo 
stesso ragionamento, ma poi col tempo (e l'aumentare della capacità degli 
HD e l'uso di microframework invece di megaframework) mi sono ricreduto.
 
Se tieni il framework assieme al progetto lo puoi aggiornare 
indipendentemente dagli altri siti, e sai sempre che quel sito funziona 
perché non ha dipendenze esterne. Quando devi aggiornare il framework hai 
il tempo di farlo sito per sito.
Se lo condividi, nel momento in cui aggiorni il framework stai andando a 
modificare tutti i siti che ne dipendono, con la possibilità di 
introdurre errori di cui non ti accorgi.
 
A me è capitato con ZF1, che dalla 1.11 alla 1.12 oltre a _redirect() nei 
controller hanno introdotto redirect(). E naturalmente io mi ero definito 
la mia redirect() in alcuni controller che estendevano il controller di 
ZF. Spaccati una decina di siti in un colpo solo, ho rimesso la 1.11 (per 
fortuna tenevo una cartella per ogni versione e ho solo cambiato il file 
di config con gli include path).
 
Quindi riassumendo i consigli:
- usa un microframework
- integra i pezzi che ti mancano con package appositi
- (derivata dai primi due) usa composer
- usa composer (sì, lo ripeto)
- la cartella col sito deve contenere TUTTO quello che riguarda il sito
- estendi il framework il meno possibile. Se puoi, usa composizione
 
Per farti un esempio, io uso Silex con Aura.PDO per il DB, Monolog per i 
log, Twig quando mi servono template, LESSphp quando uso LESScss, ecc. 
ecc. tutto via composer.
Faccio un composer update quando devo aggiornare, testo in locale, pusho 
tutto in git (compresa la cartella vendor gestita da composer) e faccio 
deploy con un semplice git pull.
 
Bye.

 - (derivata dai primi due) usa composer
 
????
Cioè?
 
 

 Cioè?
 
https://getcomposer.org/
 
 
Questo è un composer.json di un mio progetto recente:
 
{
	"name": "namespace/nomeprogetto",
	"authors": [
		{
			"name": "Alessandro Pellizzari",
			"email": "
shur...@amiran.it
"
		}
	],
	"require": {
		"php": ">=5.3.3",
		"silex/silex": "~1.2",
		"twig/twig": ">=1.8,<2.0-dev",
		"symfony/twig-bridge": "~2.4",
		"symfony/form": "~2.4",
		"symfony/validator": "~2.4",
		"symfony/config": "~2.4",
		"symfony/translation": "~2.4",
		"symfony/locale": "~2.4",
		"symfony/security": "~2.4",
		"monolog/monolog": ">=1.0.0",
		"twbs/bootstrap": "v3.0.0",
		"oyejorge/less.php": "~1.5",
		"monolog/monolog": "~1.4,>=1.4.1",
		"swiftmailer/swiftmailer": "5.*",
		"aura/sql": "2.*"
	},
	"autoload": {
		"psr-4": {
			"": "src/"
		}
	}
}
 
E questo è l'index.php:
 
<?php
 
require_once __DIR__.'/../vendor/autoload.php';
 
$app = new \Silex\Application();
 
// ... configurazione dell'app
 
$app->run();
 
 
Basta mettere il json nella cartella del progetto, e lanciare "composer 
install" la prima volta e "composer update" quando vuoi aggiornare i vari 
pacchetti e fa tutto da solo. Risolve le eventuali dipendenze, scarica la 
versione appropriata in base alle indicazioni che gli dai, crea 
l'autoloader (con tanto di caching, se vuoi)
 
È un po' la differenza tra usare slackware e installare tutti i pacchetti 
a mano e usare Debian e far fare al package manager.
 
Tra l'altro sempre più spesso nei repo su github trovi il capitolo 
"install via composer" con la riga da mettere in require.
Altrimenti vai su 
packagist.org
 e cerchi quello che ti serve.
 
Bye.

 Bootstrap::run();
 
Comunque per accedere rapidamente ai vari file, bisogna per forza usare 
il tuo *sistema* (copiare tutto nella dir del progetto).