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

Ora come sappiamo, grazie al pattern MVC e ai framework opensource php si ha modo di organizzare il codice al meglio, separando completamente la logica applicativa dalla parte di modello di accesso ai dati del database e dalla parte di presentazione dei dati sulle viste.

Fino qua tutto bene e vedo solo dei vantaggi che non voglio ripetere, ma parliamo ora del ruolo dei template language.. smarty tpl per citarne uno.. che sono ormai spesso presenti nei CMS di ultima generazione e vengono spesso propinati per rendere la vita piu’ facile a chi progetta interfaccie web… Sinceramente fatico a capire che grossi vantaggi possono offrire questi pseudo linguaggi, che sono nati appunto per rendere la vita piu’ semplice a chi deve mettere le mani sulle viste, tentando di ridurre il gap tra gli sviluppatori, i web designer e i grafici.. questo nell’ottica di team di sviluppo medio grandi dove sono solitamente sono i web designer a mettere le mani sulla parte frontend dei layout.

Questi motori di template, in ambiente PHP così come in altri ambienti, sono delle classi che consentono ai grafici di interagire con il codice sviluppato dai programmatori senza per questo dover acquisire competenze specifiche sul linguaggio di programmazione utilizzato… questo e’ vero se si dimentica che il grafico invece di capire come estrapolare il codice da un array in php tramite un foreach, dovra’ imparare ad usare un linguaggio diverso con costrutti simili (foreach, loop) e non molto piu’ semplici, per poi fare la stessa cosa con un array di dati in smarty.

Quindi nell’ottica di utilizzo di un framework MVC che ha gia’ dentro il concetto di vista e gia’ separa adeguatamente la parte di presentazione dalle query al database e dalla logica applicativa, risulta inutile secondo me appoggiarsi a queste classi, che appesantiscono a livello prestazionale il codice per introdurre un nuovo linguaggio, che ha le medesime difficolta’ dal punto programmativo quando si maneggiano strutture dati semplici come array (ovvero quello che ci dovremmo trovare nelle viste).

Quindi quali sono i vantaggi nello scrivere codice delle viste in tpl? Cambia la sintassi, non sono piu’ semplici e bisogna imparare un nuovo linguaggio, si introducono nuove classi quindi piu’ righe di codice da eseguire rallentando le prestazioni del software e come ripeto se si lavora su framework MVC si ha gia’ una separazione logica delle viste, percui non ha senso neanche per la sepazione della business logic…

Li buttiamo a mare questi tpl?

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

Riferimenti:

http://devzone.zend.com/article/4045-Zend-Framework-1.7.0-is-now-available

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