PDA

Visualizza versione completa : Progetto a più mani...



deathwish
27-07-10, 15: 15
buondì a tutti i volenterosi (e i curiosi) giunti fin qui.

come avrete forse letto in questa discussione, il nostro buon Asterix ha chiesto un aiuto motivo dall'esigenza personale di poter svolgere un'attività per la quale non è stato in grado di trovare un prodotto adeguato.

dopo qualche riflessione, si è pensato che potrebbe essere interessante fare un esperimento collaborativo e tentare di realizzare tutti insieme quanto richiesto facendo uso degli strumenti che oggi come oggi l'open-source mette a nostra disposizione.

i volenterosi che desiderano collaborare, si facciano vivi da queste parti scrivendo in poche righe che tipo di contributo desiderano apportare.

da parte mia, ho iniziato realizzando una "bozza" (moooolto abbozzata) che sto continuando a modificare.

di seguito, alcuni dettagli sulle modalità di hosting e gestione del progetto.


----------

GESTIONE DEL PROGETTO

Per la gestione del progetto, si è scelto di utilizzare Mercurial (cfr. http://mercurial.selenic.com). Il repository di riferimento per il progetto è raggiungibile all'indirizzo

http://ezoffer.codeplex.com

Per una interessante introduzione allo strumento (anche se si consiglia di fare un po' di pratica con il suddetto DVCS prima ancora di avventurarsi nella collaborazione) si veda

http://www.tekpub.com/codeplex

Per collaborare con il progetto è richiesto, prima di tutto, di creare un'utenza in CodePlex. Nella scelta del nome utente si suggerisce di utilizzare lo stesso
usato in CollectionTricks. Se questo non è disponibile, si suggerisce di aggiungere il suffisso "_ct" (oppure un suo surrogato se ancora una volta non
disponibile). Ad esempio, se il nickname in CollectionTricks è "utente01" si proveranno, in seguenza, i seguenti nomi utente

"utente01"
"utente01_ct"
"utente01_collectiontricks"
"utente01_ctrick"
...

Una volta creato l'utente CodePlex, deve essere fatta richiesta (in questa discussione o tramite messaggio privato) di essere aggiunti come collaboratori.

COME COLLABORARE

Le attività di modifica/miglioramento del progetto sono, di volta in volta, molteplici. Punto di riferimento costante per l'accentramento di queste è rappresentato dall'Issue-Tracker (in seguito, IT) di CodePlex.

Per evitare di perdere la bussola, non si accettano modifiche che non sia correlate ad un elemento tracciato nell'IT.

Nota: nel messaggio di commit del changeset deve essere ben chiaro il l'elemento dell'IT correlato.

In ogni momento, chiunque ha la possibilità di creare un elemento nel'IT. Nel caso si tratti di un argomento di rilievo, è preferibile discuterne anche
collettivamente in questo thread.

PROPORRE UN CONTRIBUTO

Il modo preferito per proporre un contributo al progetto è per mezzo di una "patch" di Mercurial. Questa deve essere inviata come allegato nella discussione
(non si accettano patch nei messaggi privati).

Nota: il nome utente usato in CodePlex deve essere utilizzato come nome utente per i changeset di Mercurial.

Il coordinatore provvederà, quindi, a verificarla e ad inserirla nella linea di sviluppo principale.

Per modifiche molto estese, esiste la possibiltà di realizzare un "fork" del progetto ed effettuare una "pull request". Tuttavia, vista la natura del progetto è auspicabile questo avvenga solamente in un ridotto numero di casi.

LINEE GUIDA

In ordine sparso, alcune indicazioni di carattere generico

quando si apporta una modifica al codice sorgente del prodotto, assicurarsi che l'editor usato sia configurato in modo da usare tabulazioni di quattro (4) caratteri automaticamente "esplose" in spazi.
sono accettati file con terminatori di riga sia DOS che UN*X (con preferenza per i primi).
le modifiche deve essere ben commentate.
i commenti, così come i messaggi di commit dei changeset, devono essere in lingua inglese (alla stregua, si utilizzi un traduttore automatico).

pierino_89
28-07-10, 01: 16
Purtroppo sono molto preso in questo momento, ma dato che si parlava di php direi che può rientrare nel mio campo d'azione. Non sono riuscito ad afferrare perfettamente lo scopo finale dell'applicativo, ma probabilmente sono solo troppo stanco per connettere. In ogni caso, la mia lettura selettiva ha determinato che vi possono servire due cose che io posso riciclarvi:
- codice per elaborare file xls e caricarne i dati su database (usa una libreria che ho trovato online): mi sembra di capire che il "database" attualmente sia un file xls, quindi potrebbe fare comodo poter effettuare una importazione.
- codice per convertire una pagina html in pdf decentemente (usando wkhtml o come si chiama): per stampare l'ordine finale mi sembra utile.

Insomma, se servono idee e atrocità in php, jquery o xhtml potete contare su di me. Ma con la dovuta calma :lol:

deathwish
28-07-10, 10: 16
Purtroppo sono molto preso in questo momento, ma dato che si parlava di php direi che può rientrare nel mio campo d'azione.


bene, ti ringrazio per la risposta.



- codice per elaborare file xls e caricarne i dati su database (usa una libreria che ho trovato online): mi sembra di capire che il "database" attualmente sia un file xls, quindi potrebbe fare comodo poter effettuare una importazione.


attualmente, almeno in questa fase iniziale, si è preferito utilizzare un tracciato testuale su file con delimitatore di campi.

per esperienza, più semplice e generico è il formato utilizzato più si limitano i problemi... tanto più che passare da un documento excel ad un file di testo come quello descritto è banale.



- codice per convertire una pagina html in pdf decentemente (usando wkhtml o come si chiama): per stampare l'ordine finale mi sembra utile.


wkhtmltopdf è, comunque, un applicativo client... ma potrebbe essere utile, eventualmente.



Insomma, se servono idee e atrocità in php, jquery o xhtml potete contare su di me. Ma con la dovuta calma :lol:

bene.

tieni presente che, al momento, AJAX non è stato volutamente preso in considerazione perchè nelle intenzioni iniziali si vorrebbe rendere il codice facilmente comprensibile anche ai meno smaliziati.

pierino_89
28-07-10, 20: 39
attualmente, almeno in questa fase iniziale, si è preferito utilizzare un tracciato testuale su file con delimitatore di campi.

per esperienza, più semplice e generico è il formato utilizzato più si limitano i problemi... tanto più che passare da un documento excel ad un file di testo come quello descritto è banale.
Sapevo che l'avreste pensato :tong2. Ma excel ha dei bug nella creazione di csv, e ogni programma fa i csv a modo suo. Quindi tanto per provare va bene, ma in produzione no... Inoltre anche con la codifica ogni tanto succedono cose strane.



wkhtmltopdf è, comunque, un applicativo client... ma potrebbe essere utile, eventualmente.

Lo so, ma è l'unico strumento che data una pagina html sputi esattamente quel che vedi... :triste

Asterix
29-07-10, 09: 53
Bene bene

ragazzi io non metterei un vincolo sull'import in quanto, questo progetto implica un inserimento a mano dei dati in quanto essi necessitano di essere formattati cosa che excel non puo' fare, quindi sul form di inserimento articoli necessita prevedere una sorta di Editor WYSIWYG

lo so le cose sono sempre più complicate ma necessitano

deathwish
29-07-10, 10: 32
Lo so, ma è l'unico strumento che data una pagina html sputi esattamente quel che vedi... :triste

beh... si potrebbe produrre direttamente un report PDF e la pagina HTML potrebbe essere unicamente un'anteprima...


ragazzi io non metterei un vincolo sull'import in quanto, questo progetto implica un inserimento a mano dei dati in quanto essi necessitano di essere formattati cosa che excel non puo' fare, quindi sul form di inserimento articoli necessita prevedere una sorta di Editor WYSIWYG

avevo pensato anche io a questa funzionalità.

infatti, l'import "batch" dei dati è solamente una modalità alternativa che può essere utile in prima battuta per popolare la base di dati.

nell'uso concreto gli articoli verranno inseriti/modicati uno ad uno e un editor visuale (con tanto di formattazione) è fondamentale.

lo aggiungo nell'issue-tracker come feature, intanto.

--- EDIT ---

Per gli interessati, il progetto ora è stato pubblicato su CodePlex.

Se qualcuno con un po' di sensibilità artistica ha voglia e tempo per cimentarsi nella creazione di un logo, ben venga. :)

pierino_89
29-07-10, 20: 16
beh... si potrebbe produrre direttamente un report PDF e la pagina HTML potrebbe essere unicamente un'anteprima...
Era per scrivere la pagina una volta sola, tutte le librerie php che ho trovato per generare i pdf usano latex o linguaggi inventati.


Per quanto riguarda xls, pensavo che effettivamente ci fosse già un file di excel contenente tutti i dati di uso comune (mi era già successo con un sito per la regione).
Se non esiste niente del genere, allora è inutile pensarci :eye



Per gli interessati, il progetto ora è stato pubblicato su CodePlex.
Come l'hai chiamato?

deathwish
29-07-10, 22: 07
Era per scrivere la pagina una volta sola, tutte le librerie php che ho trovato per generare i pdf usano latex o linguaggi inventati.

mah... a dire il vero, volendo generare direttamente i dati binari di un PDF non ci si mette poi molto (l'ho fatto qualche tempo fa, anche se in C/C++)...


Come l'hai chiamato?

presumo tu non abbia letto il primo post di questa discussione, che ho modificato ancora ieri, vero? :)

pierino_89
30-07-10, 03: 20
presumo tu non abbia letto il primo post di questa discussione, che ho modificato ancora ieri, vero? :)Esatto :lol:

Ho clonato, sono registrato come pierinz.

Commenti:
- perché usi le short tags di php? In genere sono sconsigliate, anche perché poi rischia di fare casino con xml...
- in che codifica sono i file? Eclipse non mi carica le lettere accentate
- i tag html vanno scritti minuscoli (poi va beh, ci sono molte altre cose perché la pagina sia valida)

Idee:
- dato che bisognerà effettuare l'autenticazione (indi la connessione al db) si potrebbe iniziare a creare una classe che alla creazione apra la connessione e salvi la risorsa, ottenibile tramite opportuna funzione, e la chiuda al destroy. In questo modo non c'è pericolo di lasciare connessioni appese.
- visto che hai creato delle funzioni di wrapper per mysql_query, ne approfitterei per passare la query a mysql_real_escape().
- in linea di massima, io inizierei a lavorare sulla classe succitata lasciando perdere per il momento l'autenticazione ma creando qualche funzione per creare le pagine tutte con la stessa struttura, ad esempio io ho scritto una funzione genPage(titolo pagina, aggiunte head, contenuto pagina, acl)

Per il resto boh, domani provo a tirare su apache e vedere cosa appare, così faccio anche critiche serie, adesso non ce la posso fare.
Notte!

deathwish
30-07-10, 09: 32
Ho clonato, sono registrato come pierinz.


abbi pazienza... perché non come "pierino_89" come richiesto?



- perché usi le short tags di php? In genere sono sconsigliate, anche perché poi rischia di fare casino con xml...


più che altro per abitudine... tieni presente che PHP non è il mio pane quotidiano. l'ho uso per un po' di tempo, ma non ci lavoro tutti i giorni...



- in che codifica sono i file? Eclipse non mi carica le lettere accentate


classica codepage Windows-1252...



- i tag html vanno scritti minuscoli (poi va beh, ci sono molte altre cose perché la pagina sia valida)


sì, è vero che si consiglia di scriverli minuscoli effettivamente... ma anche qui, per abitudine "dal passato"...



- dato che bisognerà effettuare l'autenticazione (indi la connessione al db) si potrebbe iniziare a creare una classe che alla creazione apra la connessione e salvi la risorsa, ottenibile tramite opportuna funzione, e la chiuda al destroy. In questo modo non c'è pericolo di lasciare connessioni appese.


l'avevo pensato anche io... ed effettivamente ce l'avrei anche pronta la suddetta classe (tempo fa ne avevo realizzare alcune con medesima interfaccia in modo da poter usare tipologie di memorizzazione diverse in modo interfambiabile)...

... a questo punto, considerato che non l'ho introdotta per mantenere il progetto "comprensibile il più possibile", bisognerà fare chiarezza su questo punto.

considerata che la richiesta iniziale di Asterix era di avere un ESEMPIO di come realizzare uno strumento di generazione offerte di questo tipo, ho pensato di mantenere il profilo del progetto MOLTO BASSO... niente sofisticazioni, niente voli pindarici... anche a costo di fare le cose in modo "non proprio consono" (è evidente a tutti il concetto di riuso modulare del software, così come la necessità di applicare almeno il pattern MVC)...

... tuttavia, se si vuole essere un po' ambiziosi, bisogna anche alzare un po' il tiro e complicare almeno un po' l'essenza del progetto.



- visto che hai creato delle funzioni di wrapper per mysql_query, ne approfitterei per passare la query a mysql_real_escape().


ribadisco, le funzioni wrapper sono state realizzate come compromesso fra chiarezza e (minima) modaluarizzazione... comunque, buona idea.



lasciando perdere per il momento l'autenticazione


sono d'accordo, anche perché aggiungerla in un secondo tempo tutto sommato non è una lavoro oneroso e al momento complicherebbe la verifica rapida...



ma creando qualche funzione per creare le pagine tutte con la stessa struttura, ad esempio io ho scritto una funzione genPage(titolo pagina, aggiunte head, contenuto pagina, acl)


anche qui... sono assolutamente d'accordo (vedi il mio discorso sul MVC), ma deve essere stabilito il livello di compromesso...

... per dire, a me non dispiacerebbe nemmeno usare strumenti come Smarty... ma, poi, mi domando quanto sarebbe semplice per i meno smaliziati personalizzare le pagine?



Per il resto boh, domani provo a tirare su apache e vedere cosa appare, così faccio anche critiche serie, adesso non ce la posso fare.

ottimo.

e, mi raccomando, domani è richiesta una buona giustificazione sul perché non hai creato l'utente "pierino_89". :)

intanto, io apporto alcune delle modifiche che hai suggerito.

pierino_89
30-07-10, 12: 53
abbi pazienza... perché non come "pierino_89" come richiesto?
Perché sono registrato ovunque così, tranne qui che ho usato il vecchio nickname in onore di p2pforum. Ma ora che p2pforum non c'è più, probabilmente chiederò di farmi cambiare il nick anche qui.



più che altro per abitudine... tieni presente che PHP non è il mio pane quotidiano. l'ho uso per un po' di tempo, ma non ci lavoro tutti i giorni...
Ok, era per capire



classica codepage Windows-1252...

Ehm, le pagine web dovrebbero essere in iso-8859-15 o in utf-8, preferibilmente quest'ultimo. È vero che si può abusare delle html entities, però è più comodo.



l'avevo pensato anche io... ed effettivamente ce l'avrei anche pronta la suddetta classe (tempo fa ne avevo realizzare alcune con medesima interfaccia in modo da poter usare tipologie di memorizzazione diverse in modo interfambiabile)...

... a questo punto, considerato che non l'ho introdotta per mantenere il progetto "comprensibile il più possibile", bisognerà fare chiarezza su questo punto.

considerata che la richiesta iniziale di Asterix era di avere un ESEMPIO di come realizzare uno strumento di generazione offerte di questo tipo, ho pensato di mantenere il profilo del progetto MOLTO BASSO... niente sofisticazioni, niente voli pindarici... anche a costo di fare le cose in modo "non proprio consono" (è evidente a tutti il concetto di riuso modulare del software, così come la necessità di applicare almeno il pattern MVC)...
A questo punto potremmo mostrare lo schema di funzionamento e poi fare un fork.
Almeno manteniamo vari livelli di complessità e ognuno può contribuire sulla base della propria abilità.


... per dire, a me non dispiacerebbe nemmeno usare strumenti come Smarty... ma, poi, mi domando quanto sarebbe semplice per i meno smaliziati personalizzare le pagine?
Non so, non ho mai usato un framework php, ma su un progetto così piccolo non so se sia poi così fondamentale...



e, mi raccomando, domani è richiesta una buona giustificazione sul perché non hai creato l'utente "pierino_89". :)
Firmata dalla mamma? :lol:


intanto, io apporto alcune delle modifiche che hai suggerito.
In pausa pranzo ripasso a vedere se posso dare una mano. :eye

deathwish
30-07-10, 13: 05
Perché sono registrato ovunque così, tranne qui che ho usato il vecchio nickname in onore di p2pforum. Ma ora che p2pforum non c'è più, probabilmente chiederò di farmi cambiare il nick anche qui.

buono a sapersi. :) sei stato sufficientemente convincente. ;)


Ehm, le pagine web dovrebbero essere in iso-8859-15 o in utf-8, preferibilmente quest'ultimo. È vero che si può abusare delle html entities, però è più comodo.

hai perfettamente ragione,



A questo punto potremmo mostrare lo schema di funzionamento e poi fare un fork.
Almeno manteniamo vari livelli di complessità e ognuno può contribuire sulla base della propria abilità.

potrebbe essere un'idea, in effetti.

allora, nell'immediato potremmo comunque proseguire nella modalarizzazione... dopo pranzo aggiungerò la classe per l'accesso dal database...

... per quanto riguardo l'output HTML... boh, sono indeciso.



Non so, non ho mai usato un framework php, ma su un progetto così piccolo non so se sia poi così fondamentale...

non è un framework troppo complesso e, forse, proprio perché il progetto è tutto sommato di modesta entità potrebbe essere una buona "palestra"...



Firmata dalla mamma? :lol:

sarebbe meglio, sì. :)



In pausa pranzo ripasso a vedere se posso dare una mano. :eye

come vedrai, ho già apportato qualche (minima) modifica nel frattempo.

deathwish
31-07-10, 09: 06
mi aggiungo in coda, invece che andare in "edit"...

... @pierino_89, ho visto che hai creato un work-item riguardo alle short-tag. se mi dai conferma lo passo da "proposed" ad "attivo" e te lo assegno.

pierino_89
31-07-10, 12: 22
Ehm, ho fatto un casino. Io e i scm facciamo a pugni. L'avevo fatto, ma non sull'ultima versione e poi a fare il merge mi è esploso eclipse.
Facciamo che adesso rifaccio il pull, sistemo le short-tags e poi rifaccio il commit.

[EDIT]
ok, ho risistemato il tutto, attendo l'autorizzazione per effettuare il push.

deathwish
31-07-10, 13: 03
Ehm, ho fatto un casino. Io e i scm facciamo a pugni. L'avevo fatto, ma non sull'ultima versione e poi a fare il merge mi è esploso eclipse.

in questi casi, ad esempio, viene comodo il meccanismo del "branching". mettiamo che tu abbia effettuato il "clone" del repository due giorni fa, e hai iniziato ad apportare le tue modifiche. quando effettui il commit viene il progetto nel tuo repository prende una sua diramazione dalla storia principale (il ramo "default"). se, poi, crei un named-branch (che potresti chiamare "issue-4" visto che andava a sistemare quel work-item) questo è ancora più evidente.

dopodiché, in un secondo tempo si può effettuare il merge nel ramo di default direttamente con mercurial (magari, potrebbe farlo il coordinatore).

nel caso specifico, la modifica era di modesta entità, ma per interventi di rilevanza è il modo migliore di agire... anche perché non puoi avere la certezza che da quando hai fatto clone/pull non sia cambiato nulla nel repository... potrebbe averci lavorato un'altra persona, nel frattempo... i DVCS di basano pesantamente su questo assunto.


ok, ho risistemato il tutto, attendo l'autorizzazione per effettuare il push.

ottimo.

come avevo spiegato all'inizio, allega a questa discussione la "patch" dell'ultimo commit che hai fatto in mercurial, così verifico e faccio il push su codeplex...

pierino_89
31-07-10, 13: 59
Non posso allegare files .patch... Lo zippo o li ficchiamo da un'altra parte?

deathwish
31-07-10, 14: 02
zippa zippa... tanto è un file di testo alla fin fine, così risparmiamo pure :)

pierino_89
31-07-10, 14: 05
Ecco qua:511
Sto facendo un banale script di installazione, ti interessa anche quello?

deathwish
31-07-10, 14: 24
Ecco qua:511

benissimo. ho corretto un attimo il messaggio di commit (avevi indicato il work-item errato, fra l'altro), e ho effettuato il push.


Sto facendo un banale script di installazione, ti interessa anche quello?

male non fa di sicuro. :)

pierino_89
31-07-10, 15: 05
Voilà. Non ho ben capito come si usa l'aggeggio, ma con queste due dovresti avere tutto.

deathwish
31-07-10, 16: 23
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
31-07-10, 16: 27
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
31-07-10, 16: 47
anche se hai modificato solamente quel file li, comunque, viene a mancare parte della "storia"...

pierino_89
31-07-10, 17: 29
Only registered members can view code.

deathwish
01-08-10, 10: 31
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
01-08-10, 10: 44
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 :lol:



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 :hap



ah... occhio alle tabulazioni. :)
Doh! Scusa

deathwish
01-08-10, 11: 04
Te l'ho detto che con i vcs faccio a pugni :lol:

solitamente, cosa usi?


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

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
01-08-10, 23: 50
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 :tong2



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". :bgg2
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
02-08-10, 11: 40
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 :tong2

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". :bgg2

: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
02-08-10, 12: 31
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 :tong2 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. :ghgh



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

Direi che è uno standard ormai :bgg2

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

mi rendo conto che, effettivamente, a meno che il progetto non sia di grossa entità e non ci si trovi a dover andare "avanti e indietro" nelle revisioni, il problema si riduce ad una copia di backup e fine...


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

direi che, essenzialmente, vediamo il "problema" con due punti di vista molti diversi.

tu, giustamente, non vedi l'utilità pratica di questo lavoro... ma da parte mia mi sembra piuttosto evidente.

infatti, la classe "Database" non esiste -- a mio avviso -- per "semplificare l'accesso ai dati" (beh, indirettamente un po' lo fa, ma non è il suo scopo fondamentale) quanto per realizzare un'astrazione dalla funzioni effettivamente usate (e passare così da MySql a Postgres in poco tempo, ad esempio).

( volendo, quello che manca attualmente, è un'astrazione completa dei dati persistenti... ovvero, bisogna comunque scriversi le query SQL... sarebbe carino usare in PHP qualcosa tipo "Hibernate" di Java... magari esiste? )

riguardo, poi, alla sua "pesantezza"... se una classe diventa "enorme" è indice di pessima modularizzazione... per cui direi che, da questo punto di vista, possiamo cercare di non farci del male da soli? :)



Direi che è uno standard ormai :bgg2

effettivamente...

se sei d'accordo, potremo a questo punto aprire alcuni work-item nell'issue-tracker per "la lista della spesa" delle cose da fare. al momento mi viene in mente (pensando anche al futuro)

aggiunta dell'autenticazione,
creazione di un oggetto che racchiuda la "sessione" dell'utente (e l'autenticazione),
aggiunta del supporto per template delle pagine (comincio a valutare sempre più interessante l'uso di Smarty),
estensione dello script di installazione,
uso di un prefisso ("ezoffer_"?) per le tabelle usate,
visto il precedente, ci vorrebbe anche una modalità di "preconfezionamento" delle query che tenga conto anche del prefisso,
uso delle funzioni di escapement ove necessario.

che ne dici? altro da aggiungere? più idee tiriamo fuori prima riusciamo a focalizzarci nello sviluppo, a mio avviso... altrimenti, rischiamo di rimanere in attesa di Godot... :)

pierino_89
02-08-10, 15: 42
direi che, essenzialmente, vediamo il "problema" con due punti di vista molti diversi.

tu, giustamente, non vedi l'utilità pratica di questo lavoro... ma da parte mia mi sembra piuttosto evidente.

infatti, la classe "Database" non esiste -- a mio avviso -- per "semplificare l'accesso ai dati" (beh, indirettamente un po' lo fa, ma non è il suo scopo fondamentale) quanto per realizzare un'astrazione dalla funzioni effettivamente usate (e passare così da MySql a Postgres in poco tempo, ad esempio).
Vabbé, a questo punto però potremmo usare PDO invece di reinventare la ruota :tong2



( volendo, quello che manca attualmente, è un'astrazione completa dei dati persistenti... ovvero, bisogna comunque scriversi le query SQL... sarebbe carino usare in PHP qualcosa tipo "Hibernate" di Java... magari esiste? )

Non conosco Hibernate, mi puoi riassumere brevemente cosa fa? Altrimenti stasera mi documento.



riguardo, poi, alla sua "pesantezza"... se una classe diventa "enorme" è indice di pessima modularizzazione... per cui direi che, da questo punto di vista, possiamo cercare di non farci del male da soli? :)

Beh per carità, se intendi solo astrarre le funzioni va bene, io pensavo che intendessi anche aggiungere una serie di funzioni per gestire categorie, recuperare liste, ecc.



se sei d'accordo, potremo a questo punto aprire alcuni work-item nell'issue-tracker per "la lista della spesa" delle cose da fare. al momento mi viene in mente (pensando anche al futuro)

aggiunta dell'autenticazione,
creazione di un oggetto che racchiuda la "sessione" dell'utente (e l'autenticazione),
O una tabella nel db



aggiunta del supporto per template delle pagine (comincio a valutare sempre più interessante l'uso di Smarty),
estensione dello script di installazione,
uso di un prefisso ("ezoffer_"?) per le tabelle usate,
Dovremmo fare come in joomla, che si può editare in fase di installazione per consentire istanze multiple.



visto il precedente, ci vorrebbe anche una modalità di "preconfezionamento" delle query che tenga conto anche del prefisso,




uso delle funzioni di escapement ove necessario.
che ne dici? altro da aggiungere? più idee tiriamo fuori prima riusciamo a focalizzarci nello sviluppo, a mio avviso... altrimenti, rischiamo di rimanere in attesa di Godot... :)
Hai pienamente ragione. Ma di tutti quelli che hanno risposto all'altra discussione ci siamo solo noi due a sporcarci le mani? :tong2

deathwish
02-08-10, 16: 11
Vabbé, a questo punto però potremmo usare PDO invece di reinventare la ruota :tong2


non conosco PDO (del resto, ti ho già anticipato che non sono certo un guru di PHP)... se PDO permette di astrarsi dal DB usato e, in futuro, pensiamo di supportarne altri allora possiamo pensare di muoverci in questa direzione... ovviamente con la priorità che pertiene questo tipo di sviluppo.



Non conosco Hibernate, mi puoi riassumere brevemente cosa fa? Altrimenti stasera mi documento.


in soldoni, effettua un'astrazione ad oggetti della base di dati e lavori sul db mediante oggetti... nel senso che avrai l'oggetto "categoria" o "prodotto" e tramite un'istanza lavori in db...



Beh per carità, se intendi solo astrarre le funzioni va bene, io pensavo che intendessi anche aggiungere una serie di funzioni per gestire categorie, recuperare liste, ecc.


no, certamente... intendevo solo astrarre le funzioni di base... non tutte le operazioni in db... quella, eventualmente, potrebbe essere a carico di una secondo classe (o più classi)...



O una tabella nel db


anche, sì... una tabella temporanea nel contenuto...



Dovremmo fare come in joomla, che si può editare in fase di installazione per consentire istanze multiple.


sì, esatto... intendevo una cosa di questo tipo (cosa che fa anche wordpress o smf o... beh, la quasi totalità delle applicazioni PHP che usano un db)...



Hai pienamente ragione. Ma di tutti quelli che hanno risposto all'altra discussione ci siamo solo noi due a sporcarci le mani? :tong2


credo proprio di sì... ;)

pierino_89
02-08-10, 18: 43
in soldoni, effettua un'astrazione ad oggetti della base di dati e lavori sul db mediante oggetti... nel senso che avrai l'oggetto "categoria" o "prodotto" e tramite un'istanza lavori in db...
http://www.php.net/manual/en/intro.pdo.php
In linea di massima, mi sembra sia esattamente quel che chiedevi.



no, certamente... intendevo solo astrarre le funzioni di base... non tutte le operazioni in db... quella, eventualmente, potrebbe essere a carico di una secondo classe (o più classi)...Ok, ora ci capiamo :eye



anche, sì... una tabella temporanea nel contenuto...
Direi che tutti i settaggi utente sono nella tabella dei dati (username password mail etc etc), poi si fa una tabella con gli ID della sessione in modo che si faccia poi un bel join tra le due...



sì, esatto... intendevo una cosa di questo tipo (cosa che fa anche wordpress o smf o... beh, la quasi totalità delle applicazioni PHP che usano un db)...

In genere si usa proprio una classe, una cosa tipo:

Only registered members can view PHP Code.
in modo da poter poi accedere con config::opzione (dirai: a che serve? banalmente, può essere importante per evitare conflitti di variabili quando si inizia ad avere una config un po' spessa)

deathwish
02-08-10, 22: 32
In linea di massima, mi sembra sia esattamente quel che chiedevi.


umm... probabilmente non mi sono spiegato bene, oppure non ho capito a cosa si riferiva la tua risposta.

a quanto ho potuto capire, PDO altro non è che una re-implementazione di ADO/DAO (e più in generale di ODBC).

ovviamente, è ben lungi dall'essere benché minimamente simile a Hibernate.

potremmo prenderlo in considerazione per il futuro, comunque, se è sufficientemente supportato e standard (mi sembra richieda PHP 5.1 e successivi... vale la pena imporlo come requisito?).



Direi che tutti i settaggi utente sono nella tabella dei dati (username password mail etc etc), poi si fa una tabella con gli ID della sessione in modo che si faccia poi un bel join tra le due...

direi che la tabella anagrafica degli utenti... quello che non mi convince è di mantenere una tabella delle sessioni quando, in realtà, è sufficiente che ogni sessione HTTP mantenga semplicemente l'id dell'utente e la password (cifrata) per effettuare la ri-validazione ad ogni transazione HTTP.



in modo da poter poi accedere con config::opzione (dirai: a che serve? banalmente, può essere importante per evitare conflitti di variabili quando si inizia ad avere una config un po' spessa)

non ti preoccupare, non me lo domandavo. :) il concetto di namespace e di campo di visibilità esiste da un bel po' di anni prima dell'arrivo di PHP (o del suo modello ad oggetti)... ;)

ad ogni modo, hai fatto benissimo a sottolinearlo. mai dare per scontato nulla.

pierino_89
03-08-10, 00: 49
umm... probabilmente non mi sono spiegato bene, oppure non ho capito a cosa si riferiva la tua risposta.

a quanto ho potuto capire, PDO altro non è che una re-implementazione di ADO/DAO (e più in generale di ODBC).

ovviamente, è ben lungi dall'essere benché minimamente simile a Hibernate.
Ah ok, tu volevi un passo ancora successivo, PDO ti offre solamente un accesso a oggetti alle funzioni standard (usando comunque i drivers nativi o i drivers odbc). C'è anche la roba che dici tu ma a me non piace granché, si perde buona parte delle features specifiche di ogni database.
In php c'è stato il grande boom di "facciamo framework che parlino con tutti i database possibili immaginabili" qualche anno fa, ma poco dopo si è tornati alle implementazioni specifiche.



potremmo prenderlo in considerazione per il futuro, comunque, se è sufficientemente supportato e standard (mi sembra richieda PHP 5.1 e successivi... vale la pena imporlo come requisito?).
PHP4 è deprecato, ed è stato da almeno un anno a questa parte rimosso dai repository di ogni distribuzione perché è cessato il supporto. In generale, non ho mai visto versioni inferiori alla 5.2. Diciamo, farebbe parte del corredo standard.



direi che la tabella anagrafica degli utenti... quello che non mi convince è di mantenere una tabella delle sessioni quando, in realtà, è sufficiente che ogni sessione HTTP mantenga semplicemente l'id dell'utente e la password (cifrata) per effettuare la ri-validazione ad ogni transazione HTTP.

Anche. Su questo non mi esprimo perché non ho mai usato le sessioni, avendo l'autenticazione integrata nel dominio con LDAP ho sempre usato robe un po' strane.
Se sei preparato, ti cedo volentieri la palla :tong2



non ti preoccupare, non me lo domandavo. :) il concetto di namespace e di campo di visibilità esiste da un bel po' di anni prima dell'arrivo di PHP (o del suo modello ad oggetti)... ;)

ad ogni modo, hai fatto benissimo a sottolinearlo. mai dare per scontato nulla.
Hai ragione, ogni tanto mi dimentico chi è l'interlocutore :lol:
Comunque con l'ultima versione di php (o la penultima?) hanno aggiunto il comando namespace, quindi la domanda poteva essere lecita :tong2

deathwish
03-08-10, 14: 24
C'è anche la roba che dici tu ma a me non piace granché, si perde buona parte delle features specifiche di ogni database.


sì, credo di capire cosa intendi. in ogni caso, nella maggior parte dei casi, mi domando, sono veramente così importanti queste caratteristiche perculiari? nel "nostro" progetto direi che più che un banale accesso all'anagrafica...




PHP4 è deprecato, ed è stato da almeno un anno a questa parte rimosso dai repository di ogni distribuzione perché è cessato il supporto. In generale, non ho mai visto versioni inferiori alla 5.2. Diciamo, farebbe parte del corredo standard.


ottimo, allora potremmo direi che diamo per scontata la presenza di PHP 5.2 come requisito (sarà bene cominciare a riportare anche questi requisiti... dopo vedo di iniziare).



Se sei preparato, ti cedo volentieri la palla :tong2


ve bene, allora potrei a questo punto iniziare a pensare a questo aspetto.

questa sera, cerco di riportare come work-item alcune delle idee che ci siamo scambiati negli ultimi post... perché, altrimenti, qui si chiacchera e non si produce! ;)

Asterix
03-08-10, 20: 45
credo proprio di sì... ;)

Mi dispiace, vi leggo sempre ma per me state parlando in arabo :lol:

Come detto il codice lo leggo e riesco a variare qualche piccolo passo ma sono fermo per quanto riguarda tutto il resto; le mie nozioni di programmazione risalgono al 1993 pasqal e cobol

:bai

Se volete posso darvi le idee ma risulta difficile per me trasformarle in codice.

deathwish
04-08-10, 09: 20
Mi dispiace, vi leggo sempre ma per me state parlando in arabo :lol:

tranquillo. :)


Se volete posso darvi le idee ma risulta difficile per me trasformarle in codice.

a questo punto sei moralmente tenuto a fornire tutte le idee che ti vengono in mente... sono preziosissime, in questa fase, per poterne tradurre in requisiti e -- poi -- in codice.

Asterix
09-08-10, 10: 50
Ok grazie

Nel mio caso quando si selezionano gli articoli necessita un ulteriore flag per indicare se è una opzione o no, le opzioni vanno riportate su una area separata nel riepilogo offerta.

naturalmente necessitano anche delle tabelle inerenti alle condizioni di vendita e contrattuali, ma qui andiamo oltre.

Ora per capire un po' necessita vedere un eventuale modulo di inserimento degli articoli e della selezione.

:bai