Progetto a più mani...

[deathwish]

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

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

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]

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

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

[deathwish]

Vabbé, a questo punto però potremmo usare PDO invece di reinventare la ruota

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?

credo proprio di sì... ;)

[pierino_89]

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

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:

 class config{
const opzione='valore';
} 
  

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]

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]

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

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
Comunque con l'ultima versione di php (o la penultima?) hanno aggiunto il comando namespace, quindi la domanda poteva essere lecita

[deathwish]

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

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]

credo proprio di sì... ;)

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

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



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

[deathwish]

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

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]

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.