La nuova release è stata divisa in due branch:  Codeigniter Core e Codeigniter Reactor

• Codeigniter Core è il branch più lento e “stabile” che viene adottato da tutti i grandi prodotti commerciali di EllisLab come ExpressionEngine and MojoMotor e mantiene una retro compatibilità con le precedenti versioni dei framework.
• Codeigniter Reactor invece è il branch guidato dalla comunità e supervisionato dai responsabili dello staff Reactor Engineers, quindi si evolve con più rapidità adottando tutte le nuove features e migliorie messe a disposizione da tutti gli sviluppatori che collaborano al progetto.

Ovviamente tutte le modifiche apportate da EllisLab al core verranno adottate anche sul branch di Reactor e comunque EllisLab contribuisce in modo attivo e presente allo sviluppo di Codeigniter Reactor.

REACTOR QUINDI RIMANE LA VERSIONE CONSIGLIATA PER I NUOVI SVILUPPI, ricordando che Reactor = CodeIgniter.

Ecco alcune delle tante migliorie apportate alla nuova versione dalla precedente 1.7.3:

• Il support a PHP 4 è morto, PHP 5.1 è il requisito minimo.
• Protezione CSRF integrata all’interno dei form helper.
• Driver.
• Application Packages.
• Scaffolding rimosso,  era deprecato da diversione versioni.
• Rimossa vecchia e deprecata Validation Class.
• Plugins sono stati rimossi in favore degli Helpers.
• Aggiunta la riscrittura del routing  “routing overrides”.
• Aggiunta$route[‘404_override’] per consentire la gestione delle pagine 404 direttamente dai controllers.
• Corretti più di 50 bugs.

Reactor apporta questi cambiamenti:

• Supporto totale alle query-string
• Identificazione automatica del base_url se non viene compilato da configurazione
• Nuovo driver per Cache con file system, supporto APC e memcache.
• Compatibilità all’esecuzione di cron jobs da riga di comando.
• Più di 20 migliorie e tweaks.

E’ possibile comunque visionare tutte le modifiche nel changelog qui

Per chi deve aggiornare l’applicazione dalla precedente versione dare un’occhiata qui

Fonte: www.codeigniter.com

Per quanto riguarda invece la versione 2.0, è stato dato definitivamente il Goodbye PHP 4! Il framework 2.0 richiede ora la versione minima di PHP 5.1.6 ed è stato fatto un attimo di ordine convenzionale sulle nomenclature e sulla pulizia del codice grazie alla versione 5 di PHP.

• Tutte le classi del core iniziano con “CI_”. Stati attenti quindi quando ereditate dalle classi native.
• Tutte le classi del core useranno il costruttore __construct come convenzione. Quindi ricordatevi quando migrate di aggiornare tutte le chiamate ai costruttori padre!
• CI_Base è stato rimosso, ora il il super object si chiama CI_Controller.
• Sono stati rimossi tutti i file helper su cui venivano implementate funzionalità di cui PHP 5.1.6 le supporta nativamente.

Ne approfitto per scusarmi della mia prolungata assenza su questo blog, ma da quando è stata aperta Syncronika Srl il tempo libero si è ristretto

E’ stata rilasciata la nuova versione del framework php CodeIgniter, giunta alla release 1.7.1. Questo rilascio contiene parecchie novità, migliorie e numerosi bug fixes. Include inoltre un importante aggiornamento di sicurezza per le applicazioni che usano la nuova libreria di validazione delle form. Per la lista completa dei cambiamenti consultate il solito Change Log.

Se volete aggiornare il vostro framework in produzione vi consiglio di leggervi la documentazione update instructions.

Riferimenti:
http://www.codeigniter.com

• Tra le novita’ piu’ interessanti della 1.7, troviamo una nuova classe per la validazione delle form, che ho lo scopo di semplificare e potenziare ulteriormente questa funzionalita’; sostituendo completamente la vecchia classe di validazione ora deprecata.
• Aggiornata anche la classe delle sessioni permettendo di salvare i dati personalizzati nel database, piuttosto che nel cookie di sessione (presupponendo che si utilizzi il database per memorizzare i dati di sessione).
• Ora e’ possibile creare sub directory anche nelle cartelle library di system ed applicaition.

Vi ricordo che se volete fare un upgrade del framework che state utilizzando nelle vostre applicazioni consultate sempre la guida di update che vi fornisce utili consigli sul passaggio indolore da ogni versione.

Dopo il rilascio del 17 marzo da parte di Zend Technologies della nuova versione 1.5 del celebre Zend Framework, che ha apportato numerosi nuovi servizi e miglioramenti alla precendente release del framework 1.0.4;
la Zend per avvicinare aziende e programmatori al proprio Framework, stá promuovendo alcuni workshop completamente gratuiti:

• Mercoledì 16 Aprile c/o Atahotel Executive Milano Vle Don Luigi Sturzo , 45
• Venerdì 18 Aprile c/o Zend Technologies Roma, Piazza del Popolo 18
  

Il programma in agenda, a mio parere molto breve, dopo una introduzione sui framework PHP, illustrerá le caratteristiche principali del nuovo Zend Framework 1.5 e terminerá con esempi reali di applicazioni.

Per maggiori informazioni e per comunicare la partecipazione consultate la pagina del workshop.

Ogni programmatore che si rispetti, che vuole rimanere competitivo sul mercato, è sempre alla continua ricerca di qualche libreria/framework che gli permetta di semplificare il proprio lavoro, ovvero: ridurre i tempi di sviluppo, migliorare sempre le proprie applicazioni, ottenenere risultati ottimi avvalendosi di strumenti efficienti, senza dover ogni volta “reinventare la ruota” ecc.
Esistono per questo framework, insiemi di librerie e di classi dall’utilizzo più o meno standard, che ci permettono di programmare in modo più semplice, estendendo l’esistente, senza doverci preoccupare direttamente di alcune problematiche: ad esempio dell’interfacciamento al database o dell’implementazione della sicurezza o di altri dettagli implementativi che allungano notevolmente i tempi di sviluppo, aumentano la complessibilità, diminuendo la gestibilità complessiva, e facendoci perdere sostanzialmente denaro.

Purtroppo o per fortuna, esistono tantissimi framework, e sicuramente fare la “scelta giusta” (eliminando le tempistiche di provare e imparare strumenti inadeguati ai nostri scopi) non è sicuramente banale.

Leggendo questo articolo di Fred Wu, mi sono reso conto che ho ripercorso la stessa strada durante la scelta del mio strumento di programmazione, quindi voglio riportare più o meno le medesime considerazioni che mettono in comparazione il framework che attualmente stò utilizzando (Codeigniter) e il suo “rivale”, il fork kohana php che potrebbe sostanzialmente riampiazzarlo.

Inizialmente il primo framework che ho provato è stato CakePHP, al tempo la documentazione era praticamente inesistente e sicuramente utilizzare un framework senza documentazione è da autolesionisti, perchè comporta sicuramente molto più studio personale, quindi ho cercato subito un’alternativa più accessibile.
Ho fatto diverse ricerche, ero orientato su due framework, il famosissimo Zend e Codeigniter, ma alla fine ho optato per CodeIgniter. Soprattutto per la splendida documentazione online (in inglese). Infatti la documentazione di Codeigniter è veramente impressionante, nel senso buono: completa, molto chiara e ben corredata di esempi; per un programmatore che conosce i linguaggi ad oggetti e php, basta un piccola letta per iniziare subito a sviluppare e creare in tempi brevi applicazioni molto potenti.

CodeIgniter è un framework che ha avuto in questi tempi ottimi progressi e ha guadagnato la fiducia di molti sviluppatori web, anche se tempo fa aveva rallentato la sua corsa perchè gli sviluppatori erano quasi tutti concentrati sulla nuova versione di ExpressionEngine CMS. Infatti alcuni degli assidui utilizzatori sul forum di Codeigniter erano molto frustrati, perché segnalavano bug e richieste di nuove funzionalità, ma venivano quasi sempre ignorati, o rimanevano in attesa dei mesi. Questo chiaramente, fece si che gli sviluppatori interessati realmente all’avanzamento del progetto, decisero di far nascere il fork BlueFlame, più tardi rinominato in Kohana, e di iniziare uno sviluppo parallello prendendo alcune decisioni tecniche diverse.

Kohana è un framework php praticamente sconosciuto al grande pubblico. Infatti, la maggior parte degli utenti Kohana sono ex utilizzatori di Codeigniter o utenti che usano entrambi a seconda delle necessità. Secondo Wikipedia, le differenze tra Kohana e CodeIgniter sono:

1. La programmazione ad oggetti strettamente PHP5 offre molti vantaggi: protezione per l’incapsulamento dei dati, il caricamento automatico delle classi, l’overloading, le interfacce astratte, singleton, ecc.
2. Kohana ha aderito alla iniziativa GoPHP5, quindi utte le versioni dalla 2.2 sono quindi conformi con questo progetto.
3. Il design pattern è sempre MVC, quindi chiunque abbia utilizzato Codeigniter capisce rapidamente come utilizzare Kohana per la similitudine della struttura e del design pattern.
4. Kohana è una comunità di sviluppatori, non un’azienda guidata. Kohana è guidata dagli utenti del forum, dalle idee e dal codice condiviso dagli utilizzatori. Kohana è una comunità di sviluppatori dislocata in tutto il mondo, ciascuno con il proprio talento. Questo consente un ciclo di sviluppo del software rapido e flessibile, in grado di rispondere alle richieste dei bug nel giro di poche ore, invece di giorni o mesi.
5. Le variabili GET, POST, COOKIE, SESSION funzionano come previsto, Kohana ha deciso di non limitare il vostro accesso ai dati globali, offrendo comunque la stessa protezione di filtraggio e di XSS che fa CodeIgniter.
6. Per quanto riguarda le risorse, i moduli, e l’ereditarietà: i controller, i modelli, le librerie, le viste e gli helpers, possono essere caricati da qualsiasi posizione all’interno del vostro sistema, applicazione, o percorso e le opzioni di configurazione sono ereditate dinamicamente e possono essere tranquillamente sovrascritte.
7. Nessun conflitto di Namespaces. I suffissi delle classi, come _Controller, sono utilizzati per prevenire i conflitti di namespace. Questo permette quindi di implementare diversi controller e modelli e caricarli allo stesso tempo.
8. Vero Auto-loading dinamico delle classi. Questo include le librerie, i controller, modelli, e gli helpers.
9. Gli helpers sono classi statiche, non funzioni. Per esempio, invece di utilizzare form_open (), si usa modulo::open ().
10. Libreria driver e API coerenti. Librerie dove è possibile utilizzare diversi “driver”, gestire diverse API esterne in modo del tutto trasparente.
11. Potente gestione degli eventi. Kohana gestisce gli eventi facendo si che è possibile aggiungere gli eventi in modo dinamico, sostituirli, o addirittura rimuoverli completamente. Questo permette molti cambiamenti al processo di esecuzione di Kohana, senza dover fare alcuna modifica al core del sistema.

Come si può vedere da questa lista, pur mantenendo un certo grado di somiglianza con CodeIgniter, Kohana offre alcuni vantaggi (al tempo stesso, alcuni svantaggi, dipende dai punti di vista). Per fare ulteriore chiarezza diamo un’occhiata alla tabella sottostante, che non ho volutamente tradotto, perchè già molto chiara e schematica. Chiaramente per la valutazione verranno considerate solo le funzionalità disponibili nei pacchetti ufficiali, non quelle integrabili attraverso estensioni di terze parti.

Il verdetto

E’ molto difficile decidere quale dei due framework utilizzare, entrambi hanno caratterstiche molto simili e forse Kohana nel tempo potrebbe affermarsi per la sua flessibilità, ma sicuramente ha ancora bisogno di crescere e di completare i propri supporti e la propria documentazione. CodeIgniter è sicuramente ottimo, soprattutto se si ha la necessità di avere ancora la retro compatibilità sull’ormai morto PHP4, ricordando che sicuramente è il framework migliore dal punto di vista della documentazione e possiede un bacino di utenza più ampio da cui poter trarre spunti e confronti.

Riferimenti:
http://thislab.com

Un esempio concreto:
In questo esempio vi introduco una semplice implementazione di un piccolo software utilizzando come base di sviluppo il framework CodeIgniter, costruiremo una semplice “job board”. I Jobs per questo esempio, saranno inseriti manualmente tramite phpmyadmin o direttamente da una shell mysql nella tabella del database chiamata “jobs” creata opportunamente con questa query SQL:

Nella semplice applicazione ci saranno sostanzialmente due semplici pagine:

• La lista di tutti i jobs;
• Visuale del job in dettaglio;

Configurazione di CodeIgniter

Ovviamente si presuppone che abbiate installato sulla vostra postazione un server PHP e MySQL. Innanzitutto scaricate, CodeIgniter, estraete il contenuto dentro la vostra cartella di root del vostro web server tutti i files contenuti nel pacchetto; Per il test io ho rinominato la cartella in /CodeIgniter, questo perché poi nella configurazione non dovete editare la configurazione del base_url. Aprite il file system/application/config.php nella cartella CodeIgniter estratta. E’ molto semplice capire cosa c’é in questo file perché é ben commentato. Se avete estratto la cartella nella root e l’avete chiamata come sopra non dovete toccare nulla.

Inoltre bisogna configurare l’accesso per permettere al framework di parlare con il database Mysql, quindi aprite system/application/database.php e scorrete finché non trovate le configurazioni del database da settare con le vostre locali.

Io per effettuare il test ho creato un database chiamato test sul mio DBMS mysql locale inserendo la tabella jobs.
Possiamo notare come CodeIgniter con questa tipologia di configurazione ci permetta, nel caso lo volessimo, di passare velocemente la configurazione tra differenti server con differenti database. Per maggiori dettagli e implementazioni sulle configurazione fate riferimento al manuale online.

Realizzazione dell’applicazione

Per realizzare la nostra job board implementeremo un controller, un modello e due viste. Il controller gestirá sia la lista principale dei jobs, sia il dettagli del signolo job, con un modello di metodo e per ogni vista. In questo modo, chiaramente verranno distinte le diverse parti della nostra applicazione.

Vi faccio notare come CodeIgniter abbia una convenzione con i nomi dei file: tutti i nomi dei files sono composti da caratteri minuscoli, tutte i nomi delle classi iniziano con una lettera maiuscola e sono poste in file con lo stesso nome piu il nome dell’estensione .php.

Il controller

Il Controller é una classe con alcuni metodi che gestiscono le varie richieste direzionandole opportunamente ove necessario. La classe estende la classe base di CodeIgniter “Controller” fornendo quindi l’accesso a tutte le funzionalitá del framework. Nel controller noi andremo a caricare tutte le risorse di cui avremo bisogno, in particolare un modello e le due viste. Niente verrá caricato di default, questo perché CodeIgniter é stato progettato per essere un framework molto leggero ed essenziale. L’oggetto $this->load consente al sistema di caricare le risorse di cui abbiamo bisogno, qui sotto il codice del controller: system/application/controllers/jobs.php

Come potete vedere, il controller é molto semplice, si incarica di prendere i dati dal modello e di inviarli alla vista. Ogni metodo inizia con la chiamata alla routine $this->load->database(), la quale si connetterá al database e preparerá le librerie per interfacciarsi utilizzando i settaggi precedentemente definiti. Questo é l’approcio di CodeIgniter al modello $this->load->model('classname') caricherá il file system/application/models/classname.php inizializzando l’instanza della classe Classname (non cé bisogno di includere altri files). Essa restituirá un riferimento al nuovo oggettto $this->classname. E’ possibile sovrascrivere questo comportamento passando un secondo argomento, che potrá essere usato come proprietá del nome dell’oggetto. Ad esempio, si puo chiamare $this->load->model('someclass', 'data'); e accedere cosí al modello della classe $this->data invece di $this->someclass.

Il modello

Come per il controller il Modello estenderá la classe predefinita “Model”. Una volta che il database sará inizializzato tramite la chiamata a $this->load->database(), avremo accesso completo alla classe dei database di CodeIgniter . Come sappiamo dal controller, nel nostro modello avremo due metodi, uno per recuperare tutti i jobs del database, da noi chiamato get_jobs(), e l’altro per recuperare i dettagli di un job, chiamato get_job($job_id). Non ci sono particolari convenzioni dei nomi per il modello, comunque é tipico usare il nome del controller con in aggiunta _model alla fine. Il manuale di CodeIgniter ha un eccellente guida veloce alle librerie del database, che potete leggere prima di procedere oltre.
Ecco a voi il codice del modello: system/application/models/jobs_model.php

Prendiamoci un attimo per esaminare questo codice che per certi versi é la parte piú complessa di questo tutorial. CodeIgniter ha una classe Active Record che consente agli sviluppatori di accedere ai database in Active Record-style. Si puó scrivere la query SQL e passarla a $this->db->query(), ma ci sono molte casistiche in cui conviene utilizzare la classe Active Record, ricordando che CodeIgniter gestirá automaticamente l’eventuale prefisso delle tabelle che avrete settato nel file di configurazione del database. Un esempio di query di selezione tipo SELECT * FROM table WHERE id='0', utilizzando la classe Active Record:

Da notare il metodo get()che alla chiamata interroga la libreria costruendo la query e se non gli vengono date ulteriori informazioni, assume che sia di default una SELECT * FROM ‘table’, eseguendo la query ritornando un oggetto result che é possibile maneggiare con molta facilitá ad esempio applicandogli il metodo result_array() oppure row_array() che é simile solo che restituisce una singola riga.

La vista

Questo é l’ultimo passo, che serve per presentarci l’applicazione. Noi abbiamo preso tutti i dati di cui avevamo bisogno dal database attraverso il modello e li dobbiamo passare attraverso il controllore ad una vista. La nostra vista si chiamerá jobs_view. L’abbiamo deciso quando abbiamo scritto questa riga di codice nel controller:

Questa sostanzialmente dice a CodeIgniter di caricare la vista in system/application/views/jobs_view.php, e di recuperare l’array associativo $data e creare una variabile con la vista $data['jobs'] che ci dará accesso alla variabile $jobs. Per verificarlo basta creare un file nel path delle viste chiamandolo jobs_view.php ed insererire la stampa del vettore < ?=print_r($jobs)?>. Il risultato dovrebbe essere qualcosa di questo stampo:

Ora forse, si potrebbe affermare che sarebbero bastati dei semplici mysql_query() e mysql_fetch_array() per fare tutto questo, ma sicuramente se si vorrá poi esterndere l’ applicazione in modo semplice e veloce mantenendone il controllo, e questo é sicuramente uno dei framework adatti per semplificarci notevolmente la vita.

Di seguito il file vista inserendo i dati nel codice html: system/application/views/jobs_view.php

La vista per un dettaglio di un job: system/application/views/job_view.php

Ora abbiamo terminato di creare la nostra prima applicazione con il framework MVC CodeIgniter.

Ci basta caricare http://localhost/CodeIgniter/index.php/jobs/list_jobs per vedere il risultato finito!!

Per eventuali dubbi o segnalazioni commentate pure!

Traduzione parziale dell’articolo:
Rapid Development with CodeIgniter del 17-02-2008 » http://www.developertutorials.com
a cura di Valerio Giacomelli (neryo)

Da qualche giorno è disponibile una nuova release di Zend Framework, si tratta di una versione di mantenimento giunta alla versione 1.0.4, in cui sono stati risolti numerevoli bugfix segnalati da ben 111 ticket. Con questo rilascio si chiude quindi l’ultima frontiera del ramo 1.0 prima del rilascio della nuova versione Zend Framework 1.5.0.

Chiaramente é raccomandabile il download l’aggiornamento del framework a questa versione per tutti utilizzatori di Zend Framework 1.0.x, perché non comporta incompatibilità con installazioni precedenti dello stesso ramo.