Come gestire i file: le basi (Parte 1)
“Bene, non mi resta altro da fare che caricare questa nuova copertina e la galleria fotografica sarà pronta!… Ma… come è possibile che il file esiste già? Lo elimino và… Impossibile leggerlo? Ma è lì dai, come fa a non leggerlo?!”
Non ti è mai capitata una situazione del genere?
Sei pronto a creare la tua galleria fotografica, il tuo pacchetto di file… ed ecco che spuntano fuori errori su errori, il file esiste già, non riesci né ad eliminarlo né tantomeno a leggerlo.
A tal proposito, ho creato una guida di quattro articoli per aiutarti a risolvere questi problemi.
Struttura della guida
Come gestire i file: le basi (parte 1)
Questo primo articolo è incentrato sulla creazione di una classe per gestire i file. Ti mostro come effettuare controlli di sicurezza preliminari e alcuni metodi per ottenere informazioni basilari.
Come gestire i file: le basi (parte 2)
Ecco come cercare, leggere ed eliminare i file, effettuando controlli a monte ed eliminando ogni futuro e possibile problema.
Come gestire i file: il download
Vediamo come effettuare il download dei file in sicurezza per te e per i tuoi utenti.
Come gestire i file: l’upload
Ed infine ecco come effettuare l’upload dei file sul server, con l’ausilio della classe class.upload.
Pochi metodi e molta efficacia
Io sono un amante della programmazione ad oggetti ed ho pensato di scrivermi una classe per poter fare tutto ciò per il quale prima scrivevo righe e righe di codice ogni volta. Ovviamente la classe da sola ha poca utilità, bisognerà integrarla in un sistema già esistente. Ma basta chiacchiere, tuffiamoci nel PHP ed iniziamo a scrivere la base per far funzionare la nostra classe.
/** * Classe per velocizzare i controlli e la gestione dei file. */ class YCFile { //Controlla l’esistenza del file ed eventualmente restituisce informazioni con pathinfo(). public static function exists($file, $getInfo = false) { } //Controlla che il file sia leggibile o meno public static function isReadable($file) { } //Restituisce l’estensione del file public static function ext($file) { } //Restituisce il nome del file senza estensione public static function name($file) { } //Restituisce il nome del file comprensivo di estensione public static function realName($file) { } //Elimina caratteri non consentiti dal nome del file public static function sanitizeName($file) { } //Cerca un file e, in caso positivo, restituisce il suo percorso public static function find($file, $base) { } //Genera un array contenente i file trovati nella cartella indicata public static function listFile($dir, $ext = false) { } //Elimina un file public static function delete($file) { } //Legge il contenuto di un file public static function read($file, $totalChunk = 0, $chunkSize = 8192, $offset = 0) { } }
Bene, abbiamo ora uno scheletro della classe.
Come vedi i metodi sono pochi e dai loro nomi è molto semplice intuirne lo scopo.
Passiamo all’analisi e la stesura di ogni metodo.
Come prima cosa per poter lavorare con un file, dobbiamo essere sicuri che esista, altrimenti su cosa lavoriamo?
/* … */ class YCFile { //Controlla l’esistenza del file ed eventualmente restituisce informazioni con pathinfo(). public static function exists($file, $getInfo = false) { //Controlliamo che il file esista e che sia veramente un file if(is_file($file)) { //Se vogliamo, ci facciamo restituire informazioni come l’estensione, il nome ecc... if($getInfo) { return pathinfo($file); } return true; } return false; } //Controlla che il file sia leggibile o meno public static function isReadable($file) { return (self::exists($file) AND is_readable($file)); } /* … */ }
Nel metodo YCFile::exists() ho aggiunto la funzione pathinfo() per comodità. Potresti voler utilizzare un solo metodo per avere tutto subito sottomano. Io solitamente uso questo metodo solo per controllare che il file esista poiché pathinfo() restituisce un array di informazioni e non ho mai voglia di riordinare questo array in altre variabili con un nome adatto (si, sono un maniaco della precisione).
Con il metodo YCFile::isReadable() puoi controllare anche che il file sia leggibile.
Vedremo la sua utilità nel metodo YCFile::read().
Iniziamo a lavorare al file
Ora che sei sicuro che il tuo file esista e sia realmente leggibile, puoi iniziare a lavorarci.
Sicuramente avrai bisogno di sapere il suo nome e la sua estensione.
Quindi scriviamo i metodi YCFile::name(), YCFile::ext(), YCFile::realName() e YCFile::sanitizeName().
/* … */ class YCFile { /* … */ //Restituisce l’estensione del file public static function ext($file) { return substr($file, strrpos($file, '.') + 1); } //Restituisce il nome del file senza estensione public static function name($file) { //Se non sono in ambiente Unix, sostituisco il separatore con il carattere slash ( / ) if(DIRECTORY_SEPARATOR != '/') { $file = str_replace(DIRECTORY_SEPARATOR, '/', $file); } $lastSlash = strrpos($file, '/'); //Il parametro $file è una path, quindi estraggo solo il nome del file. if($lastSlash) { $file = substr($file, $lastSlash + 1); } return substr($file, 0, strrpos($file, '.')); } //Restituisce il nome del file comprensivo di estensione public static function realName($file) { return self::name($file) . '.' . self::ext($file); } //Elimina caratteri non consentiti dal nome del file public static function sanitizeName($file) { $fileName = preg_replace('/[^\w\.\-]/', '_', self::realName($file)); return dirname($file) . DIRECTORY_SEPARATOR . $fileName; } /* … */ }
Come vedi anche il funzionamento di questi quattro metodi è estremamente semplice.
YCFile::ext() non fa altro che cercare l’ultimo punto nel parametro passato ed estrarre la porzione di stringa da quella posizione fino alla fine.
YCFile::name() cerca l’ultimo slash estraendo quindi solo il nome del file. Per uniformare il metodo su tutti i sistemi, ho preferito sostituire qualunque divisore con lo slash.
YCFile::realName() è una scorciatoria per invocare entrambi i metodi contemporaneamente.
YCFile::sanitizeName() invece pulisce il nome del file sostituendo tutto ciò che non sia un numero, una lettera, un punto o un trattino con un underscore. Come sicuramente sai potrebbero causare dei problemi gli spazi nel nome del file, ma io preferisco eliminare anche altri caratteri speciali. Con questo metodo risolveremo ogni problema ancor prima che si possa presentare.
Ecco tutto il codice scritto fin ora:
/** * Classe per velocizzare i controlli e la gestione dei file. */ class YCFile { //Controlla l’esistenza del file ed eventualmente restituisce informazioni con pathinfo(). public static function exists($file, $getInfo = false) { //Controlliamo che il file esista e che sia veramente un file if(is_file($file)) { //Se vogliamo, ci facciamo restituire informazioni come l’estensione, il nome ecc... if($getInfo) { return pathinfo($file); } return true; } return false; } //Controlla che il file sia leggibile o meno public static function isReadable($file) { return (self::exists($file) AND is_readable($file)); } //Restituisce l’estensione del file public static function ext($file) { return substr($file, strrpos($file, '.') + 1); } //Restituisce il nome del file senza estensione public static function name($file) { //Se non sono in ambiente Unix, sostituisco il separatore con il carattere slash ( / ) if(DIRECTORY_SEPARATOR != '/') { $file = str_replace(DIRECTORY_SEPARATOR, '/', $file); } $lastSlash = strrpos($file, '/'); //Il parametro $file è una path, quindi estraggo solo il nome del file. if($lastSlash) { $file = substr($file, $lastSlash + 1); } return substr($file, 0, strrpos($file, '.')); } //Restituisce il nome del file comprensivo di estensione public static function realName($file) { return self::name($file) . '.' . self::ext($file); } //Elimina caratteri non consentiti dal nome del file public static function sanitizeName($file) { $fileName = preg_replace('/[^\w\.\-]/', '_', self::realName($file)); return dirname($file) . DIRECTORY_SEPARATOR . $fileName; } //Cerca un file e, in caso positivo, restituisce il suo percorso public static function find($file, $base) { } //Genera un array contenente i file trovati nella cartella indicata public static function listFile($dir, $ext = false) { } //Elimina un file public static function delete($file) { } //Legge il contenuto di un file public static function read($file, $totalChunk = 0, $chunkSize = 8192, $offset = 0) { } }
Conclusioni
Come vedi questi primi metodi sono semplici, ma fanno il loro sporco lavoro.
Nella prossima parte dell’articolo ti mostrerò come trovare un file, come leggerlo evitando di scrivere ogni volta almeno 20 righe di codice e come cancellarlo senza far spuntare i fatidici Warning e Fatal Error.
Questo è il mio metodo preferito per lavorare con i file. E tu invece come procedi? Usi una classe, ne hai scritta anche tu una o usi le funzioni di PHP senza tanti fronzoli di OOP?
Secondo te ho usato un giusto metodo per pulire il nome del file o pensi che sia eccessivo?
57 commenti
Trackback e pingback
-
Come gestire i file: le basi (parte 2) | Your Inspiration Web
[...] precedente articolo abbiamo potuto vedere come gestire le informazioni necessarie a lavorare con un [...] -
Come gestire i file: il download | Your Inspiration Web
[...] articoli precedenti (Come gestire i file: le basi parte 1 e parte 2) abbiamo visto come creare la classe… -
Come gestire i file: l’upload | Your Inspiration Web
[...] Come gestire i file: le basi (parte 1) Questo primo articolo è incentrato sulla creazione di una classe per…
Ciao Nicola, innanzitutto ti do il mio personale benvenuto, dopodiché ti faccio i complimenti per l’articolo, gli ho dato uno sguardo veloce perché sono in ufficio, me lo leggerò con calma oggi pomeriggio a casa, quindi aspettati ulteriori miei commenti :)
Grazie per benvenuto e i complimenti!
Sarò felice di rispondere ai tuoi commenti! :D
Bell’articolo Nicola!!
Ho cominciato da poco a programmare ad oggetti, e debbo dire che l’applicazione del tuo esempio aiuta molto a capirne l’utilizzo e le potenzialità.
Aspetterò con ansia i prossimi articoli.
Grazie Zaso!
Quando imparerai bene a programmare ad oggetti vedrai che non potrai farne più a meno!
Io ormai qualunque cosa faccio la faccio ad oggetti, è comodissimo, anche a livello di riusabilità del codice.
Ciao Nicola,
articolo interessante, anche se, personalmente, non sono molto d’accordo nell’utilizzare solo metodi statici. In questo caso lo trovo uno “spreco” (più dal punto di vista progettuale che prestazionale) di risorse, non è propriamente una classe (se non per definizione), non è pensare OOP, ma è una semplice collezione di funzioni.
O ci mettevi un Singleton ( YCFile :: getInstance() ) e con l’oggetto ritornato lavoravi sul file corrente (soluzione più elegante e scalabile, in caso si lavori poi con altri pattern come un Factory), o (sempre secondo me) meglio ancora, rappresentavi a livello logico il singolo file “mappandolo” con una classe, per poi andare a creare un’altra classe (contenente un array di oggetti file) con cui eseguire le varie operazioni su ogni singolo oggetto (ok qui esagero io, ma è una distorsione professionale arrivando da java ^^ ).
Per il resto ti faccio i complimenti per la tematica scelta, sicuramente molto ostica da affrontare con un linguaggio “povero” come php.
Quoto:
“rappresentavi a livello logico il singolo file “mappandolo” con una classe, per poi andare a creare un’altra classe (contenente un array di oggetti file) con cui eseguire le varie operazioni su ogni singolo oggetto”
concordo in pieno.
Ti ringrazio per le tue precisazioni Nico e ti dirò subito perchè ho optato per una classe statica evitando Singleton e tutto il resto.
Se non avessi creato tutta la classe con metodi statici, avrei dovuto cambiare istanza ogni volta che cambiavo file, o comunque avrei dovuto inserire un metodo per cambiare il file sul quale lavorare. Così invece lo posso evitare.
Sarebbe diventato più “pesante” utilizzarla, secondo me. Così è tutto più immediato. Certo, nulla toglie che si possa utilizzare con un singleton, alla fin fine si tratta solo di eliminare gli static e inserire un nuovo metodo. Però ripeto, secondo me così è molto più immediato l’utilizzo.
Ciao,
invece che il singleton (che alcuni evitano come la peste) potresti pensare di creare una classe che faccia da interfaccia ai metodi di una collezione di classi File: magari una classe FileCollection che sia un Composite di File.
in pratica:
classe abstract AbstractFile
classe concreta FileCollection (che è un composite di AbstractFile)
classe concreta File
Implementando un composite, agiresti fondamentalmente sulla Collection che è a sua volta un File (con tutta la Api relativa) e avresti solo alcuni metodi getter per ottenere il file della collezione con cui vorresti lavorare.
Niente singleton, ma comunque avresti una facilità d’uso molto buona e una strutturazione del codice più efficace.
Ovviamente, questa è solo un’idea… ^^
Ci penserò su Francesco, tanto già ho in mente di migliorare questa classe per poterle permettere di creare un file da zero. Quindi aggiungerei metodi per la scrittura e altre cosette utili ;)
Certo, poi sono scelte dettate dalle abitudini: la tua è una soluzione più pratica, ma meno orientata all’ OO, io personalmente non mi troverei comodo, ma ripeto, sono scelte.
La mia non era comunque una critica, anzi, ma solo uno spunto di riflessione!
Sono curioso di leggere il seguito dell’articolo, soprattutto la parte relativa all’upload.
Ciao e buon lavoro ;)
No tranquillo, sarebbe stata pur sempre una critica costruttiva! Ci sono milioni di modi per fare la stessa cosa in programmazione, il mio è un metodo, il tuo un altro. Ci sono vantaggi e svantaggi in ogni metodo lla fin fine…
Presto arriveranno anche gli altri 3 articoli! A presto e buon lavoro anche a te!
Ciao Nicola, bell’articolo complimenti, anchio quando utilizzavo il php, avevo cominciato a crearmi delle classi per gestire le operazioni che eseguivo più frequentemente :P
Adesso sto passando un periodo di prova con Ruby on Rails, quindi il tuo articolo rimarrà nei segnalibri per utilizzi futuri!
Grazie Luca! Io non so come farei senza PHP, però a volte sento l’esigenza di fare cose che con PHP non posso (o è troppo lungo/complicato) fare.
Iniziai a studiare un pò di C++ ma poi ho abbandonato… Vuole le cose fatte in modo troppo rigido per i miei gusti. Purtroppo però questo è uno svantaggio di aver iniziato a programmare con il PHP. E’ molto flessibile e ti lascia la libertà di fare come vuoi tu, cosa che i linguaggi di basso livello difficilmente ti permettono di fare. Però poi la differenza, soprattutto nell’ordine e logica del codice si vede…
Ma perchè nella funzione name non hai usato la funzione basename($path) (nativa di php) che ti restituiva direttamente il nome del file?
Un pò per abitudine, un pò perchè se provi questo codice:
<?php
echo basename("/foo/bar/").'’;
echo YCFile::name(“/foo/bar/”).”;
?>
vedrai i risultati diversi. La prima riga ti stampa “bar” che è evidentemente una cartella, la seconda non ti stampa niente perchè capisce che “bar è una cartella.
Quindi penso che basename() non sia molto utile al mio caso.
Volendo comunque si può modificare il metodo in modo che usi basename() senza nessun problema, bastano pochi controlli.
Ma se usi is_file non hai problemi
Esatto, infatti come ho detto, sarebbe semplice riscrivere il metodo per farlo funzionare correttamente con basename().
Una volta fatto, è solo questione di gusti e abitudini. Non penso che si venga influenzati anche dalla velocità di esecuzione poichè la differenza (ammesso che ci sia, non ho fatto un test) sarebbe nell’ordine di millisecondi, impercettibili per un umano :)
Ciao Nicola,
ho iniziato ad avvicinarmi da poco ad uno dei migliori framework php (se non il migliore)
Non so se lo conosci, si chiama yii framework. Ha anche la documentazione in italiano.
E l’ho scelto proprio perché ho necessità di gestire applicazioni complesse con poco sforzo, tenendo tutto pulito. Lavora solo con oggetti.
Quasi quasi riadatto il tuo codice per yii.
Ciao e grazie ;)
Ciao Giancarlo, si lo conosco di nome.
Personalmente non uso nessun framework perchè sono dell’opinione che solo scrivendosi da soli il codice si impara veramente e dato che non si smette mai di imparare, continuo ancora oggi a scrivermelo da solo. Ovviamente quando posso riutilizzo o, se sono cose veramente enormi da fare, utilizzo classi già pronte.
Magari però un giorno cambierò idea e sarò un guru dei framework :)
Se vuoi la mio opinione comunque, io non ho mai utilizzato/studiato Yii però ho studiato il codice di altri.
C’è Symfony 2 che è un vero casino, utilizza anche i namespace ed ovviamente tutto ad oggetti.
Un altro carino è CodeIgniter, però se non ricordo male, non lavora molto ad oggetti.
A detta di molti invece il migliore è ZendFramework, ma dicono anche che è uno dei più complessi, specie per chi non se la cava con l’inglese dato che la documentazione in italiano scarseggia molto.
Si li conosco e come dici tu ognuno ha i propri casini. Ma yii è quello che li ha risolti tutti. :-)
Ti segnalo una risorsa in cui li hanno messi tutti a confronto e da cui si intuisce la netta superiorità di yii:
http://php.html.it/articoli/leggi/3838/yii-il-framework-php-che-punta-sulle-performance/
Grazie Giancarlo, sto seguendo quell’articolo dalla prima uscita proprio per studiarmi tutti i framework per bene :)
Proprio per questo ti dico che li conosco solo teoricamente, li ho scaricati tutti quelli analizzati nell’articolo, ma non ho scritto ancora nessuna riga di codice con nessuno di essi.
Purtroppo tra lavoro e altro, il tempo libero scarseggia un pò.
Anche io, agli inizi, ero dell’idea che fosse meglio scriversi da soli le proprie risorse per lo sviluppo (tant’è che mi ero buttato nello sviluppo da zero di un framework in php5 completamente object oriented e MVC, con supporto nativo per jquery, ajax, json, namespace etc. etc. e non ti dico le nottate a studiarci dietro ) con il quale ho sviluppato piccole e medie applicazioni..esperienza stupenda ed istruttiva..tutto bene, finchè il cliente non chiedeva nuove funzionalità che a loro volta richiedevano, per essere realizzate, lo sviluppo di nuove classi del fw e di conseguenza ci mettevo sempre il triplo del tempo preventivato all’inizio per completare il lavoro. Va bene finchè lo fai con lo scopo di imparare, poi ho scoperto ZendFW ( e luce fu :D ). Vuoi mettere la comodità di avere un set di strumenti già testati e funzionanti, “garantiti” e in continua evoluzione? Ti permette di concentrarti solo sullo sviluppo, senza doverti preoccupare di “farlo funzionare”..per non parlare della comodità del lavoro in team..stupendo!
Certo, sotto il tuo punto di vista, c’è solo da guadagnarci ad utilizzare un framework noto.
Però non sono d’accordo sul fatto che ogni volta bisognerebbe implementare nuove classi e ci vuole tempo.
Per esperienza personale, ti posso dire che basta scrivere bene la base.
Ad esempio, hai una classe che si interfaccia con un database (non PDO, ma una tua), e poi ne utilizzi un’altra per semplificare le chiamate alla classe genitore o anche la stessa classe senza nessuna estensione.
Arriva il cliente e ti chiede un portfolio o un blog personalizzato. Nel caso tu non avessi previsto questa possibilità e la tua classe non ti permetta di farlo allo stato attuale, se è stata scritta bene la base ci vorranno 5 minuti ad estenderla o scriverne una nuova che utilizzi quella base. O almeno così è capitato a me. Ho scritto una sola classe generica per interfacciarmi a MySQL. Ora qualunque operazione richieda operazioni sul database, mi basta estendere questa classe con nuove classi figlie, aggiungo un paio di metodi specifici ed il gioco è fatto
Con questo non voglio dire che io sono migliore di chi ha sviluppato quei framework, ci vogliono anni di duro lavoro per arrivare a quei livelli. Dico soltanto che, secondo me, un pò alla volta ci si ritrova ad aver creato un fw personale senza nemmeno volerlo, ci si ritrova ad avere tante classi utilissime, basta solo dargli una bella spolverata e fare in modo che convivano tutte insieme.
Si ok, ma perché reinventare ogni volta l’acqua calda?
Io lo faccio per soddisfazione personale. Mi piace sapere sempre tutto come funziona in ogni minimo dettaglio e poterci mettere le mani tranquillamente.
Su questa cosa sono stato criticato moltissime volte da chiunque, anche dai miei datori di lavoro (alla fine si sono ricreduti quando comunque consegnavo sempre tutto in tempo).
Non so se per me sia un vantaggio o uno svantaggio, ma è più forte di me. La soddisfazione nello scrivere e veder funzionare ed essere utilizzato anche da altri il mio codice è troppo forte.
Vero, Nicola, son davvero grandi soddisfazioni! :) Creare una creatura da zero che sia interamente plasmata da te :)
Questo commento è bellissimo! Mi ricordi Arya di Eragon parlando così :) e sei anche la prima che non è contro di me su questo argomento :) grazie!
Beh potrebbe essere reinventare per così dire l’acqua calda ma ciò non toglie che sia una cosa sbagliata. Anche io qualche anno fa prima che cominciassi ad avere impegni di lavoro fissi, nel tempo permesso stavo iniziando a creare per esempio un CMS leggero per quei siti piccoli che non avrebbero necessitato di cose complesse, ma poi man mano volevo espanderlo e renderlo flessibile al massimo per arrivare oltre i siti leggeri. Alla fine non è che stessi inventando un nuovo CMS all’avanguardia diverso dagli altri, ho solo imparato meglio PHP e nuove metodologie di programmazione che mi son servite. L’uso di roba già pronta spesso quando genera errori sconosciuti sono solo perdite di tempo a cercare la soluzione eventuale nei forum.E se non c’è devi andare a guardare tra il codice che non hai scritto tu e cercare di capire la fonte che non è che sia una passeggiata se non conosci bene l’architettura di una cosa che non hai scritto. Lo dico da utente che ad oggi comunque usa CMS conosciuti opensource come basi e ci sviluppa sopra estendendo con plugin e moduli, ma non mi dispiacerebbe se magari in futuro avessi la possibilità di usare qualcosa che creerei io e che conosco meglio di un qualcosa scritto da altri. E’ questione solo di preferenze e soddisfazione nient’altro non c’è niente di sbagliato nel creare di nuovo le stesse cose o di usarne già pronte come base!
Ecco appunto :)
Alla fine poi se ci sono errori è un problema grosso perchè tutto il tempo che impieghi per trovarlo e risolverlo in un codice a te sconosciuto, lo potresti spendere per fartelo da te.
E’ la stessa identica cosa, il tempo impiegato sarebbe più o meno lo stesso (se non di più perchè devi anche studiarti il codice). Però dalla sua c’è la soddisfazione :)
Per quanto riguarda i CMS sono d’accordo anche io. Per quanto mi riguarda, sto ababstanza alla larga da cose come WordPress o Joomla (per carità, ottimi prodotti) , salvo richieste particolari del cliente o budget ridotti. Preferisco anche io utilizzare sistemi fatti da me :) Ma per realizzare tali sistemi, soprattutto se si tratta di applicazioni di un certo peso (quindi non semplici siti magari solo con area riservata o piccoli e-commerce), a volte torna molto utile avere dei framework
(con fw != cms, anche se ormai si stanno avvicinando) già testati e sviluppati, anche se il vero vantaggio imho è quello di mantenere un modus operandi comune quando lavori con altri sviluppatori o webdesigner a distanza (tu sviluppi Model e Controller, il webdesigner lavora sulle View, etc.).
Detto questo, anche io (come ho scritto sopra), quando posso, uso ancora il mio piccolo framework casalingo (ho imparato quasi di più sviluppando questo fw che in tre anni di università), in effetti è una bella soddisfazione vedere il programma finito e realizzato con qualcosa che hai inventato tu da zero..devo dartene atto Nicola!
eheheh alla fine abbiamo detto la stessa cosa :)
Comunque si, se si tratta di lavorare con altri che magari non ti conoscono o a distanza, è meglio utilizzare un fw già conosciuto per questioni logistiche.
Se invece si lavora da soli, o in un team di amici o comunque persone che si conoscono abbastanza bene ed è facile istruire se dovessero esserci problemi, io opterei per qualcosa di mio o di loro che sia… (io per esempio spesso mi trovo a sviluppare progetti con i miei amici, in questo caso li COSTRINGO ad utilizzare il mio fw xD)
Ho notato che i più giovani tendono giustamente a voler imparare bene il php.
E non c’è modo migliore che fare tutto da se.
Ma poi diventano sempre più esperti e con la bravura aumenta la mole di lavoro. Ecco allora che si accorgono che le 24 ore non bastano più. E se vogliono portare a casa un buon stipendio, devono inevitabilmente riuscire a ridurre i tempi di consegna.
Così si avvicinano ai Framework, dove scoprono che la comunità è sempre più brava del singolo. E i prodotti realizzati tramite fw sono più stabili, sicuri e si costruiscono in meno tempo.
Per chi già usa un fw:
Li ho testati un pò tutti, da zend a symfony ed effettivamente ognuno pecca in qualcosa, finché finalmente non ho scoperto yii che oltre ad essere completo, ha una curva di apprendimento impressionante. Dopo 2 settimane si riescono a realizzare già dei bei lavori.
Ma attenzione crea veramente dipendenza come dice questo articolo:
http://www.yiiframework.com/forum/index.php?/topic/27067-framework-20-con-documentazione-in-italiano/
Pensavo fosse uno scherzo, ma invece è vero. Dopo averlo provato è seriamente difficile tornare indietro. Provare per credere.
Mi state seriamente facendo venir voglia di provarlo!
Per quanto riguarda giovani e PHP penso che imparino quello anche perchè è uno dei più semplici da imparare nell’immediato… Si può subito produrre qualcosa a differenza di altri (Java o c++) per il quale è necessario più studio.
Uomo avvisato, mezzo salvato…
Io te l’ho detto:
se decidi di provarlo seriamente e ti dai quindi 2 settimane di tempo per digerirlo, dopo avrai serie difficoltà a lavorare su cose che ti sembreranno più vecchie di qualche anno luce.
Se hai voglia, prendi ad esempio il tuo collega Stefano, che aveva scritto un ottimo tutorial sulla registrazione di un nuovo utente in php:
http://www.mtxweb.ch/php_learn/?p=665
e prova a confrontare il codice con quello necessario su yii per fare meglio:
http://www.yiiframework.com/forum/index.php?/topic/27224-come-creare-la-prima-mini-applicazione-con-yii/
Appena ho un pò di tempo libero magari lo proverò!
Grazie per la segnalazione :)
P.S. Il collega si chiama Maurizio, non Stefano.
Mia curiosità..Come mai ritieni che con Java non si possa subito ad iniziare a produrre qualcosa? E’ un linguaggio abbastanza semplice, potente ed intuitivo..lo trovo molto più pratico di php per lo sviluppo di applicazioni..
Perchè, da quanto ho potuto capire di Java, è tutto orientato agli oggetti (o sbaglio?) e per chi non ne sa nulla non è semplice entrare nell’ottica.
Si, dici bene, Java è tutto oo. Ma secondo me il fatto di essere orientato agli oggetti non è una limitazione o una difficoltà aggiuntiva, anzi, pensare ad oggetti è più semplice che pensare procedurale..se conosci bene java (o simile), quando passi a php (il meno possibile) ti eviti le varie bad practices tipiche da newbie (la troppa permissività di php è un’arma a doppio taglio)..chi comincia con php e di php ne voglia fare un lavoro, difficilmente riuscirà a passare ad altri linguaggi proprio perchè troppo “rigidi” (cioè giusti) senza poche difficoltà. Almeno, io la penso così..non trovi?
No non condivido ma in parte.
Penso che sia più difficile pensare ad oggetti perchè ti impone di lavorare in un certo modo. In modo procedurale invece butti lì il codice ed è fatta senza pensare troppo a come strutturare una certa classe o un metodo al suo interno. Certo, di errori da niubbi ce ne sono tantissimi, ma sono quelli che ti aiutano ad imparare il linguaggio. Poi dopo aver imparato a sviluppare in OO, risulterà tutto il contrario xD ma all’inizio per me è stato un trauma passare da procedurale ad oggetti.
Ma condivido che la flessibilità di php è un’arma a doppio taglio. Io stesso infatti sono molto restio a imparare altri linguaggi proprio perchè sono troppo rigidi (giusti in effetti, come dici tu) e per me è più difficile impararlo dato che comunque “penso in php”.
Ti ringrazio per le risposte anche se non condivido del tutto. Ritengo che se uno voglia farlo seriamente di lavoro, debba sbattersi sin dall’inizio scegliendo la via corretta (non parlo di te, dico in generale per chi si avvicina a questo mondo), diventa quindi un investimento per il futuro. Non è una critica, ho capito cosa intendi, abbiamo solo due visioni differenti sul modo di raggiungere la stessa meta. Ti saluto e buona continuazione nel tuo studio ;)
Bisogna anche essere intelligenti e anche un pò fortunati nel capire subito quale sia la strada migliore.
Ci sono guide e tutorial, forum e libri che possono essere letti per andare subito sulla via migliore (sempre che si possa davvero definire così…).
Però alla fine il risultato è quello che conta.
Grazie a te! E’ stato un piacere :)
Ciao, secondo me escludendo i fini didattici è inutile reinventare la ruota creando framework personalizzati. Se per progetti piccoli, può tornare comodo il framework fatto in casa, quando s’inizia a lavorare su progetti medio/grossi e/o in cui sono coinvolte più persone, un framework conosciuto è d’obbligo. Pensa per un attimo agli altri programmatori del team che non hanno mai visto il tuo framework e che devono necessariamente studiarselo. Ogni volta che subentra un nuovo programmatore, questo dovrà necessariamente imparare ad utilizzare il tuo framework e quindi non sarà operativo sin dal primo giorno al 100%. Se invece si utilizza un framework conosciuto puoi inserire nel team un programmatore che già conosce lo strumento. Inoltre è probabile che la rilevazione/correzione dei bug avvenga più velocemente (se la community di supporto è attiva) e che vengano sempre adottate le best practices di programmazione così come pattern GOF, ecc in quanto il framework viene utilizzato nei più diversi scenari (scenari che difficilmente riusciresti a replicare da solo in casa).
un altro aspetto da non sottovalutare è la sicurezza dell’applicazione. Sei sicuro di aver previsto tutte le casistiche possibili? Un framework utilizzato a livello mondiale è probabilmente più “testato” di uno fatto in casa… Potrei continuare parlando della compatibilità nei vari environment, dettati dalle configurazioni del server (e fidati che ne vedrai delle più disparate con il tempo)
Concludo precisando che queste considerazioni sono derivate dal lavoro quotidiano in team, quando lavoravo da solo sarei stato molto più in accordo con te. Ad ogni modo è questione di punti di vista e soprattutto di esigenze, non voglio sicuramente proclamarmi profeta della programmazione. Come si dice..my two cents..
Si infatti qualche commetto più su dicevamo che in un team è sicuramente meglio un framework conosciuto.
Ma finchè si è da soli oppure con 1 o 2 amici perchè no… può andare bene anche il proprio fw ;)
[OT] In effetti qualche tutorial su CodeIgniter, forse il fw più semplice da utilizzare all’inizio, con una curva di apprendimento veramente bassa, intuitivo e più “vicino” alla figura del webdesigner che non programma, di media, per portarsi a casa la pagnotta, non guasterebbe! Con questo non intendo che sia il fw più completo in circolazione , ma solo una buona e semplice base di partenza. E poi, la comodità dell’MVC ( in generale, non solo su CI )…….una volta provato non si torna più indietro :) [/OT]
Ciao,
volevo fare notare una cosa relativa alla funzione name.
Questo metodo prende un file, ricava la parte dall’ultimo slash in poi e da questa estrae il nome del file con un substring che si ferma al primo punto.
Questo per me può essere fonte di errori, perchè ci possono essere file con più di un punto nel nome e l’estensione è sempre la sequenza di caratteri che si trova dopo l’ultimo punto presente.
Es:
nomefile.ciao.pdf
è un pdf
e il nome del file è nomefile.ciao.
Quello che posso consigliare è ricavare l’estensione del file partendo dalla fine e iterando fino a trovare il primo punto (che poi sarebbe l’ultimo). Elimini questo dato dal nomecompleto e hai fatto. Ovviamente php ha pathinfo() che può essere usata per lo scopo. Ciao
Ciao Francesco, mi sa che ti stai confondendo.
Il metodo utilizza strrpos() che trova l’ultima occorrenza, non la prima. Quindi funziona esattamente come dici tu :)
Aaaaa! Che scemo che sono! Non mi ero accorto che fosse strRpos, ma avevo letto strpos.
Mannaggia al PHP e ai nomi delle suoe funzioni built-in XDXD. Ok, come non detto allora ^^
Non dirlo a me!
Chissà quante ore ho perso a cercare l’errore in una pagina e poi scopro che manca una lettera ad una funzione… -.-
Buona giornata!!!
Ciao, complimenti per l’articolo, sono d’accordo sul discorso aperto della programmazione con classi statiche però volevo chiedere una cosa su un’altra funzione statica:
per determinare l’estensione del file hai utilizzato una substr per prelevarne i caratteri sucessivi al .
Domanda:
che differenza ci sarebbe stata utilizzando la funzione “pathinfo” che restituisce un array associativo di informazioni sul file inclusa l’estensione ?
Grazie mille e complimenti ancora
Ciao Davide e grazie per i complimenti!
Non c’è nessuna differenza. L’unica cosa, è appunto che pathinfo() ti restituisce un array associativo, quindi volendo poi devi assegnare l’estensione ad una variabile apposita, mentre il mio metodo ti restituisce solamente quel valore, senza nessun altro.
:) ok grazie
Ottima !
Grazie Pasquale!