Progetto a più mani...

[deathwish]

Voilà. Non ho ben capito come si usa l'aggeggio, ma con queste due dovresti avere tutto.

nope... purtroppo non sono corrette le "patch"... probabilmente manca il changeset in cui hai effettuato l'aggiunta dei file?

[pierino_89]

Boh... Io ho dato "hg export 10" e "hg export 11" e via... Ho saltato la 9 ma era solo una modifica del .hgignore

[deathwish]

anche se hai modificato solamente quel file li, comunque, viene a mancare parte della "storia"...

[pierino_89]

# HG changeset patch
# User pierinz
# Date 1280579653 -7200
# Node ID 32c136e2f0a86e9e650e2ede752f6463aa19bc34
# Parent  71d4f3facf7b2789b39bf9d4a4b05df48924959d
# Parent  c17c2d345fea2ce50340aa91eefcd4f9e32fe245
Merge with c17c2d345fea2ce50340aa91eefcd4f9e32fe245

diff -r 71d4f3facf7b -r 32c136e2f0a8 .hgignore
--- a/.hgignore Sat Jul 31 12:51:23 2010 +0200
+++ b/.hgignore Sat Jul 31 14:34:13 2010 +0200
@@ -0,0 +1,3 @@
+
+syntax: regexp
+\.(.*)
\ No newline at end of file

[deathwish]

per qualche motivo ho dovuto ricreare i commit "a tuo nome"... comunque, ho sistemato.

direi che, data l'esistenza della classe "Database", conviene usarla sempre e comunque (anche nel caso della creazione della struttura)... che ne pensi?

ah... occhio alle tabulazioni. :)

[pierino_89]

per qualche motivo ho dovuto ricreare i commit "a tuo nome"... comunque, ho sistemato.

Te l'ho detto che con i vcs faccio a pugni

direi che, data l'esistenza della classe "Database", conviene usarla sempre e comunque (anche nel caso della creazione della struttura)... che ne pensi?

Che la classe "Database" probabilmente all'inizio della struttura dovrebbe avere "require ('config.php');", che in quel momento non esiste ancora

ah... occhio alle tabulazioni. :)

Doh! Scusa

[deathwish]

Te l'ho detto che con i vcs faccio a pugni

solitamente, cosa usi?

Che la classe "Database" probabilmente all'inizio della struttura dovrebbe avere "require ('config.php');", che in quel momento non esiste ancora

umm... quindi, se capisco cosa intendi, vorresti "cablare" la dipendenza di un modulo generico rispetto ad un file di configurazione? per come l'ho abbozzata ora, la configurazione avviene per mezzo degli argomenti attuali del costruttore, per cui si potrebbe usare tranquillamente...

... ad essere sincero, per quanto possa rappresentare una "comodità", non mi piace molto l'idea di introdurre questa dipendenza.

piuttosto, si potrebbero prevedere che se nel costruttore non sono valorizzati gli argomenti attuali (ad esempio perché sono stringhe di lunghezza zero), si tenta la lettura della configurazione da un file (magari criptato).

Doh! Scusa

nessun problema (per ora) :)

[pierino_89]

solitamente, cosa usi?

Ma guarda, io mi ritrovo sempre nel ruolo dello sviluppatore solitario, quindi basta e avanza rsync per gestire il ramo stabile e quello in testing. Diciamo che ho affrontato il problema con il metodo ignorante

umm... quindi, se capisco cosa intendi, vorresti "cablare" la dipendenza di un modulo generico rispetto ad un file di configurazione? per come l'ho abbozzata ora, la configurazione avviene per mezzo degli argomenti attuali del costruttore, per cui si potrebbe usare tranquillamente...

... ad essere sincero, per quanto possa rappresentare una "comodità", non mi piace molto l'idea di introdurre questa dipendenza.

"Ni".
Prima di tutto, non vedo il vantaggio nell'includere la classe Database nello script di installazione.
Offrirebbe praticamente le stesse funzioni chiamandole in maniera diversa, con lo svantaggio di un include in più e con il possibile problema della retrocompatibilità in futuro quando diventerà più ampia.

Invece mi sembra razionale che sia la classe principale (quella che si occupa di autenticazione e maybe generazione template) a fare il require della configurazione per poi istanziare l'oggetto Database, e che la classe principale sia inutilizzabile in mancanza della stessa, piuttosto che sia ogni pagina a fare il require della configurazione.

O almeno, questa è la mia idea.

piuttosto, si potrebbero prevedere che se nel costruttore non sono valorizzati gli argomenti attuali (ad esempio perché sono stringhe di lunghezza zero), si tenta la lettura della configurazione da un file (magari criptato).

Beh, si potrebbe verificare se il file è presente e ridirigere alla pagina di installazione se non è stato trovato. Criptare il file mi pare poco furbo, dal momento che se si cambia db non si può poi modificare facilmente i dati di connessione, mentre sarebbe questione di attimi per un ladro decifrare la stringa (difatti non ho mai visto nessun applicativo cifrare password che non possano essere salvate come hash).

[EDIT]PS: puoi chiudere l'issue #4?

[deathwish]

Ma guarda, io mi ritrovo sempre nel ruolo dello sviluppatore solitario, quindi basta e avanza rsync per gestire il ramo stabile e quello in testing. Diciamo che ho affrontato il problema con il metodo ignorante

capisco.

molto spesso anche io lavoro "in solitaria" (ad eccezione del lavoro "d'ufficio" dove negli anni ho utilizzato SCM di volta in volta differenti)... a volte non è semplice superare la "pigrizia" e fare uso di un VCS... soprattutto se è necessario mettere in piedi un server (come avviene con CVS, SVN e compagnia bella)...

... ora che i DVCS sono una realtà utilizzabile, però, trovo sia assurdo non farne uso. sono di una praticità incredibile e ci sono solo benefici nell'utilizzarli.

"Ni".

:D

Prima di tutto, non vedo il vantaggio nell'includere la classe Database nello script di installazione.
Offrirebbe praticamente le stesse funzioni chiamandole in maniera diversa, con lo svantaggio di un include in più e con il possibile problema della retrocompatibilità in futuro quando diventerà più ampia.

mi viene il dubbio che stiamo utilizzando i termini in modo diverso... per "includere" ovviamente non intendevo "fare copia-e-incolla" ma usare la direttiva "include()" (o "require()").

perchè dovrebbe esserci il problema della retrocompatibilità? se cambia l'interfaccia della classe "Database" (cosa che, secondo best-practices della OOP va fatta con la dovuta cautela) allora si adegua anche lo script... non vedo il problema.

Invece mi sembra razionale che sia la classe principale (quella che si occupa di autenticazione e maybe generazione template) a fare il require della configurazione per poi istanziare l'oggetto Database

su questo sono d'accordo... ma attualmente questa classe manca, per cui...

e che la classe principale sia inutilizzabile in mancanza della stessa, piuttosto che sia ogni pagina a fare il require della configurazione.

se per "classe principale" intendi la classe che rappresenta la "sessione di utilizzo" sono d'accordo... ma non vedo, appunto, come questo debba influenzare la classe "Database" che rappresenta solo un'astrazione nell'uso del DB...

O almeno, questa è la mia idea.

siamo qui per discuterne, no? :)

Beh, si potrebbe verificare se il file è presente e ridirigere alla pagina di installazione se non è stato trovato. Criptare il file mi pare poco furbo, dal momento che se si cambia db non si può poi modificare facilmente i dati di connessione, mentre sarebbe questione di attimi per un ladro decifrare la stringa (difatti non ho mai visto nessun applicativo cifrare password che non possano essere salvate come hash).

infatti, non sono nemmeno io propenso alla soluzione "cifrata". l'ideale è, appunto, un file PHP che definisce le variabili...

[EDIT]PS: puoi chiudere l'issue #4?

dimenticanza mia, scusami. ora l'ho chiuso.

[pierino_89]

a volte non è semplice superare la "pigrizia" e fare uso di un VCS... soprattutto se è necessario mettere in piedi un server (come avviene con CVS, SVN e compagnia bella)...

... ora che i DVCS sono una realtà utilizzabile, però, trovo sia assurdo non farne uso. sono di una praticità incredibile e ci sono solo benefici nell'utilizzarli.

Ma guarda, l'infrastruttura è il meno. È che ho un talento innato nel corrompere tutto il repo alla quinta volta che lo rigenero in genere mi stufo e lascio perdere.

mi viene il dubbio che stiamo utilizzando i termini in modo diverso... per "includere" ovviamente non intendevo "fare copia-e-incolla" ma usare la direttiva "include()" (o "require()").

perchè dovrebbe esserci il problema della retrocompatibilità? se cambia l'interfaccia della classe "Database" (cosa che, secondo best-practices della OOP va fatta con la dovuta cautela) allora si adegua anche lo script... non vedo il problema.

No no parlavo anch'io di include(), la mia questione è sull'utilità pratica di avere la dipendenza da una classe che potrebbe diventare enorme per poi usarne 3 funzioni che fanno esattamente la stessa cosa di quelle predefinite di php.

infatti, non sono nemmeno io propenso alla soluzione "cifrata". l'ideale è, appunto, un file PHP che definisce le variabili...

Direi che è uno standard ormai