Pagina 3 di 4 PrimoPrimo 1234 UltimoUltimo
Mostra risultati da 21 a 30 di 40

Discussione: Progetto a pi mani...

  1. #21
    Data registrazione
    Jan 2010
    Messaggi
    142
    Grazie dati 
    52
    Grazie ricevuti 
    106
    Ringraziato in
    46 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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?

  2. # ADS
    Google Adsense Circuito Adsense
    Data registrazione
    da sempre
    Messaggi
    molti
     
  3. #22
    Data registrazione
    Jan 2010
    Sesso
    Uomo
    Località
    Nel mondo degli svarioni
    Messaggi
    1,403
    Grazie dati 
    149
    Grazie ricevuti 
    471
    Ringraziato in
    421 post

    Riferimento: Progetto a pi mani...

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

  4. #23
    Data registrazione
    Jan 2010
    Messaggi
    142
    Grazie dati 
    52
    Grazie ricevuti 
    106
    Ringraziato in
    46 post

    Riferimento: Progetto a pi mani...

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

  5. #24
    Data registrazione
    Jan 2010
    Sesso
    Uomo
    Località
    Nel mondo degli svarioni
    Messaggi
    1,403
    Grazie dati 
    149
    Grazie ricevuti 
    471
    Ringraziato in
    421 post

    Riferimento: Progetto a pi mani...

    Codice:
    Only registered members can view code.

  6. #25
    Data registrazione
    Jan 2010
    Messaggi
    142
    Grazie dati 
    52
    Grazie ricevuti 
    106
    Ringraziato in
    46 post

    Riferimento: Progetto a pi mani...

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

  7. #26
    Data registrazione
    Jan 2010
    Sesso
    Uomo
    Località
    Nel mondo degli svarioni
    Messaggi
    1,403
    Grazie dati 
    149
    Grazie ricevuti 
    471
    Ringraziato in
    421 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da deathwish Vedi messaggio
    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

  8. #27
    Data registrazione
    Jan 2010
    Messaggi
    142
    Grazie dati 
    52
    Grazie ricevuti 
    106
    Ringraziato in
    46 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    Te l'ho detto che con i vcs faccio a pugni
    solitamente, cosa usi?

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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).

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    Doh! Scusa
    nessun problema (per ora) :)

  9. #28
    Data registrazione
    Jan 2010
    Sesso
    Uomo
    Località
    Nel mondo degli svarioni
    Messaggi
    1,403
    Grazie dati 
    149
    Grazie ricevuti 
    471
    Ringraziato in
    421 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da deathwish Vedi messaggio
    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?

  10. #29
    Data registrazione
    Jan 2010
    Messaggi
    142
    Grazie dati 
    52
    Grazie ricevuti 
    106
    Ringraziato in
    46 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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.

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    "Ni".
    :D

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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.

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    O almeno, questa la mia idea.
    siamo qui per discuterne, no? :)

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    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...

    Citazione Originariamente scritto da pierino_89 Vedi messaggio
    [EDIT]PS: puoi chiudere l'issue #4?
    dimenticanza mia, scusami. ora l'ho chiuso.

  11. #30
    Data registrazione
    Jan 2010
    Sesso
    Uomo
    Località
    Nel mondo degli svarioni
    Messaggi
    1,403
    Grazie dati 
    149
    Grazie ricevuti 
    471
    Ringraziato in
    421 post

    Riferimento: Progetto a pi mani...

    Citazione Originariamente scritto da deathwish Vedi messaggio
    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

Segnalibri

Regole di scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •  
Cookies:direttiva 2009/136/CE (E-Privacy)

Il sito utilizza cookies propri e di terze parti per maggiori informazioni faq - Termini di servizio - Cookies
Il forum non puo' funzionare senza l'uso dei cookies pertanto l'uso della community vincolato dall'accettazione degli stessi, nel caso contrario siete pregati di lasciare la community, proseguendo la navigazione acconsenti alluso dei cookie