Come affrontare il progetto

[mannybiker]

Chiedo scusa in anticipo se le mie domande risulteranno un po' disparate, ma il mio obiettivo è quello di costruirmi la giusta opinione su come procedere in base alle vostre opinioni, per capire se sto tralasciando qualche cosa, se sono fuori strada o se invece sto andando nella giusta direzione.

Vi spiego il mio problema. Considerate che non sono completamente digiuno di programmazione, ma non pratico ai livelli di cui ho bisogno.
L'obiettivo è quello di realizzare un progetto completo che si concretizza alla fine in un sito web in grado di mostrare informazioni, statistiche e grafici sul funzionamento di alcune apparecchiature elettroniche che generano quotidianamente dei log in formato txt.
La prima fase è quella di fare il download di questi file da remoto, controllare che tutto sia stato scaricato correttamente, ed importare i log txt tramite un parsing meticoloso del file, che non è in formato da poter essere importato direttamente in un db.
Per mettere una buona base agli sviluppi futuri e per l'interfaccia web, ho deciso di provare ad utilizzare il framework Yii (sperando sia la giusta scelta non conoscendo già nessun framework).
Intanto la prima fase di import verrà fatta in un DB Mysql che ho già creato.

Ne seguiranno sicuramente altre, ma intanto le prime due questioni:

- Se utilizzo un'astrazione del DB (DAO con Yii framework), se domani avessi bisogno di spostare tutto su un db MSSQL avrei bisogno di rivedere tutte le funzioni di CRUD non essendo indentiche le sintassi SQL tra Mysql e MSSQL, oppure DAO serve giustamente ad evitare la scrittura di sintassi SQL e quindi se ne occupa lui di adattarsi in base al tipo di DB connesso?

- Per la fase di import e parsing dei log txt dovrei scrivere uno script PHP. Come procedo per rimanere nella logica dell'utilizzo di un framework? Creo un controller che si occupi di queste procedure e poi lo eseguo tramite linea di comando con uno scheduler?

Iniziamo così... sperando che abbiate voglia di aiutarmi a fare un po' di chiarezza.

Grazie!

[nickcv]

benvenuto :P

io ho iniziato a usare yii da alcuni mesi, e mi ci trovo decisamente bene, sto anche sviluppando un modulo per lo stesso al momento.

Yii utilizza PDO per la comunicazione del db, questo ti permette di non avere alcun problema con un eventuale cambio di database.

mi raccomando quando lanci le query evita di scrivere tu il sql vero e proprio, lascia fare a yii, in maniera tale che non ci siano sicuramente problemi di compatibilità se mai cambierai db.

per quel che riguarda il parser secondo me è più giusto metterlo all'interno di un component piuttosto che di un controller.

ovviamente il salvataggio dei dati estratti dal parser li dovresti poi far caricare al model sul db

[mannybiker]

nickcv, grazie mille per la tua partecipazione! Sono le persone come te che vorrei vantare nel mio bagaglio di amicizie!!! Ma invece non conosco mai un'anima viva con cui poter ogni tanto scambiare un'opinione tecnica!! Quindi il tuo aiuto è un conforto pratico, ma anche morale!

Bene per il db allora, farò attenzione a usare sempre le astrazioni del model.

Invece per il parser mi apri un mondo.. eheh.. nel senso che come ti ripeto sto studiando Yii da due giorni, tenendo conto che allo stesso tempo studio PHP e metto in pratica i concetti che erano solo teorici della OOP... quindi, tralasciando il fatto che mi sta per esplodere il cervello , ci sono molte cose che non ho ancora capito. Tra queste ignoravo il "component". Immagino ti starai mettendo le mani nei capelli.. prima di tutto perchè ti chiedi come si possa ignorare una cosa così importante, e dall'altra parte forse perchè potresti pentirti di avermi risposto!

Mi aiuteresti a capire come si sposa il concetto di component nella pratica, dovendo realizzare uno script batch da eseguire automaticamente ogni giorno?

[nickcv]

a questo punto potresti impostare il lavoro in questo modo:

in un controller (nuovo apposito per questo, oppure in uno già esistente) inserisci un action che per praticità d'esempio chiameremo parse (quindi secondo le convenzioni di yii chiamerai il metodo all'interno del controller actionParse() )

assicurati utilizzando le accessRules e quindi il sistema di accessControll già integrato in yii, che nessun utente possa accedere mai a questo pagina.

come fare?
il sistema di accesscontrol ti permette di permettere o negare l'accesso anche in base agli ip, pertanto abilita l'accesso a quella determinata action solo da locale e così hai risolto

all'interno del controller chiama il componente che si occuperà di gestire il parsing dei dati.
eseguito il parsing vai restituire dal parser un array dei dati da inserire, che passerai così al modello.

se proprio vuoi puoi costruire il parser in maniera modulare, in maniera tale da poter integrare i suoi metodi ed aggiungere altri sistemi di parsing ad esso, ma mi pare di capire che stai appena cominciando a vedere i design pattern, quindi non è il caso di mettere troppa carne al fuoco.

[mannybiker]

Grazie ancora nickcv, tutte le cose che mi hai detto mi hanno datto diverse parole chiave che sto utilizzando nelle mie ricerche per trovare le risposte che cerco. Naturalmente il grande problema è che certi concetti non mi sono ancora molto chiari, come il Component che continuo a fare fatica ad indentificare.
Non voglio abusare del tuo tempo e della tua disponibilità, quindi non sentirti in obbligo di spiegarmi le cose se ritieni che sia troppo distante dal livello auspicato. Il problema è che con un approccio di programmazione strutturata è molto evidente come organizzare il lavoro:
apro il file, faccio la scansione linea per linea e di volta in volta analizzo il contenuto creando un flusso "intelligente" di azioni da intraprendere a secondo di una serie di controlli fino alla fine del file.
Invece in un concetto OOP già non capisco qual'è il punto di partenza. Forse creare una classe "parser" che riceve come parametro il nome del file e che al suo interno racchiude tutte le funzioni necessarie alla traduzione del file verso un array formattato (se non è troppo grande il file di log, altrimenti forse è meglio scrivere direttamente in un db) e che poi lo scarica in qualche modo verso il db?
Ancora peggio se cerco di incastrare tutto questo con Yii... La classe "parser" cosa sarebbe un components che estende CComponent? (e qual'è il vantaggio di essere figlia di questa classe?). Inoltre se chiamo questo component tramite un controller devo passare da una pagina web... il che mi sembra strano dato che si tratterebbe di fare il parser di log di certe dimensioni, ma soprattutto non di uno, ma di un centinaio al giorno e che l'operazione oltre ad essere lunga deve anche essere schedulata quotidianamente. I tutorial di Yii sono belli, se vuoi fare una costa standard, ma se le esigienze sono diverse da una paginetta non trovo materiale di esempio. Per quello rompo le scatole sul forum...

[nickcv]

il problema è che stai ancora pensando in procedurale :P

dunque: dovendo essere chiamato da un controller sì deve essere chiamato da una pagina web.
questa pagina web però la sigilli permettendo l'accesso solo all'ip locale, quindi nessun utente del tuo sito potrà mai scatenare questa azione.

a livello di dimensioni non hai problemi, perchè la chiamerai in locale, quindi non ci saranno problemi di banda di alcun tipo da dover considerare (ovviamente ti conviene sulla macchina nel file di host dare un alias all'ip e poi settare un virtualhost che rimandi quella chiamata verso la directory root del tuo progetto yii)

perchè un component?
per component intendo più che altro il concetto...
la tua classe non è palesemente un controller, nè un modello... quindi è un componente dell'applicazione.
Parlando di yii in senso stretto potrebbe essere sia un component vero e proprio che una banale estensione.
estendere CComponent?
si, puoi farlo, ma non sei costretto.
che vantaggi comporta?
se è un component è in grado di reagire ad eventi, quindi potresti impostare che se una detereminata chiamata all'interno del sito fa il raise di un evento il component reagisce.

perchè non fare scrivere il parser direttamente sul db? perchè far fare il lavoro al modello?

per una divisione dei compiti.
lo scopo di un parser nel senso stretto è solo ed unicamente uno: parsare un file!

se tu mettessi anche la logica di query nel parser e poi volessi spostare il suddetto parser per usarlo per qualcosa di diverso saresti costretto a modificare il parser per modificare le query. Pertanto la tua applicazione perderebbe di modularità.

Inoltre lasciando al model il compito del salvataggio puoi far gestire a lui ulteriori interazioni.
ad esempio mettiamo che sul db hai dei campi aggiuntivi che indicano tipologie dei dati basati su uno dei dati estratto dal parser.
Usando il model puoi controllare nel beforeSave un determinato campo in arrivo e generare il valore per un altro campo che hai bisogno di riempire nel database, senza dover far generare al parser un campo aggiuntivo basato su una logica che va bene solo ed unicamente per la situazione in cui ti trovi.

faccio un esempio più pratico per spiegarmi meglio:

il file che intendi parsare contiene un elenco di libri, l'autore, ed il numero di pagine

nel tuo db hai deciso che vuoi anche archiviare anche la lunghezza del libro, secondo il parametro che se il libro ha più di 300 pagine è considerato medio, meno di 150 breve, e più di 2000 lungo.

Al parser fai estrarre i normali dati dal file e poi invii al modello, il modello si preoccuperà di fare il controllo sul numero di pagine e generare il valore del campo aggiuntivo.
Questa logica non ha senso di stare nel parser, visto che se poi lo userai altrove non è detto che tu sia interessato ad avere un elaborazione del genere.
Lo scopo del parser è come già detto quello solo di estrarre i dati inseriti nel file, non di elaborarli.

Inoltre facendo gestire l'inserimento sul db al model non hai bisogno di preoccuparti della sintassi delle query (passaggio da db a db) nè di preoccuparti se il campo è nuovo ( ti serve un insert) oppure no (bisogna effettuare un update)

il vantaggio di inserire il tutto nel flusso di lavoro di un controller ti permette inoltre scatenare altri eventi dell'applicazione dopo l'avvenuto parsing.

Mettiamo che stai parsando un elenco di utenti che devi importare nel db.
Questi utenti sono l'elenco dei dipendenti attuali dell'azienda.
All'interno del file, tra i valori da parsare c'è anche lo stipendio mensile.

dopo aver estratto i dati passi il tutto al modello, che contiene anche il campo "ultimo aggiornamento" di tipo date.
il valore di questo campo equivale ovviamente al momento dell'aggiornamento e viene elaborato on the fly dal modello.

Dopo aver effettuato il salvataggio il modello poi si occupa di cancellare/bannare gli utenti non aggiornati, per il fatto che tu sai che quelli non presenti nella lista sono stati licenziati e non lavorano più per l'azienda.
inoltre se lo stipendio è cambiato aggiorni un valore boolean all'interno della tabella che sta ad indicare che lo stipendio è cambiato.

dopo che il modello ha finito il suo lavoro, restituisci al controller l'elenco degli id degli utenti il cui stipendio è cambiato e richiami un altro component che si occupa dell'invio delle mail agli utenti del tuo sistema.

Certo, tutto questo si poteva fare in procedurale, ma dividirlo a pezzi così come stiamo facendo permette di avere oggetti modulari che potrai riutiizzare.
Il parser parserà sempre quel tipo di file, e potrai riusarlo in altre applicazioni oppure per scopi diversi all'interno della stessa.
Farai modifiche al db o aggiungerai campi? nè il parser nè il controller avranno bisogno di saperlo, ti basterà fare le modifiche di caso al modello e tutto funzionerà come sempre.

Il component / estensione che si occupa dell'invio della mail potrai riutilizzarlo in tutti i progetti per i più svariati usi, per il fatto che non sarà legato al resto del flusso di lavoro.

In questo modo il tuo codice è: riusabile e facile da mantenere e testare

[mannybiker]

Mamma mia, ti sto facendo sudare... grazie davvero per il tuo tempo. Le persone come me sono sempre una gatta da pelare! A volte vorrei diventare invisibile per potermi mettere dietro le spalle di uno come te per poter imparare, imparare, imparare...
Sei molto chiaro e hai proprio ragione, hai capito come ho lavorato per anni, in procedurale! Comunque ora la divisione dei compiti mi è abbastanza chiara e il component finalmente comincia ad avere un senso pratico... è un oggetto che non è ne un controller ne un modello ne una vista...

Mi permetto di discutere ancora di un concetto non trattato... mi hai rassicurato sull'utilizzo di un controller per eseguire l'azione di parse, la cosa che mi spaventava erano gli eventuali timeout che potevano essere generati da apache se l'operazione durasse troppo tempo, ma forse è solo una mia preoccupazione inesistente. Non ho mai usato php in questo modo e quindi mi faccio forse troppe pippe mentali!

A questo punto per eseguire come dici tu (e qui mi studierò bene il discorso dei controlli sull'accesso di Yii) il controller come mi comporto... php in CLI che chiama l'URL del controller tramite uno scheduler di sistema? Il concetto di console commands di Yii potrebbe tornarmi utile?

[nickcv]

per il timeout di apache ne potresti soffrire in ogni caso, anche se non lo lanci tramite yii, se il parser è in php, visto che php viene comunque interpretato da apache.

comunque io un annetto fa avevo fatto degli scrappers che prelevavano tutto il contenuto di un paio di siti regionali per poi archiviarlo su db.
Lo script per fare il giro completo impiegava un ora e mezza (per via anche dei tempi di risposta dei siti) e non ho avuto mai problemi.

per quel che riguarda i console commands potrebbero sì esserti utili, ma confesso di non averli praticamente mai usati, se non per generare in automatico testo localizzato, quindi non so aiutarti.

in bocca al lupo o.o/

[mannybiker]

nickcv sei stato davvero gentile, non abuserò oltre della tua disponibilità! Mi metto al lavoro... speriamo bene!

[Santino83_02]

parsa i file con perl, va alla grande sui testi


EDIT: a leggere la documentazione, questo Yii ha delle belle idee (soprattutto nell'uso del db), solo che sono un pò troppo rozze, risulta poco omogeneo come framework. Cmq magari mi sbaglio, parlo solo per lettura documentazione alla fine.