In urma cu nu prea mult timp, va spuneam despre o initiativa care m-a bucurat foarte tare la vremea respectiva. CodeIgniter TV era la acel moment doar o idee buna.

O echipa de programatori s-a gandit sa puna la dispozitie o serie de tutoriale video despre CodeIgniter pentru incepatori si nu numai. Iata ca acum, acea idee buna s-a transformat in realitate.

CodeIgniter TV a ajuns in Public Beta si are deja 3 tutoriale publicate. Le gasiti in sectiunea Videos a site-ului. Si ca sa vedeti ca au planuri marete, deja in sectiunea video, troneaza un filtru care va va ajuta sa gasiti ce va intereseaza in multitudinea de tutoriale care vor “aglomera” site-ul in curand.

Si ca sa vedeti ca baietii chiar vor sa ajute comunitatea, site-ul beneficiaza si de o sectiune Requests, in care puteti sa cereti un tutorial despre un subiect anume (atat timp cat are legatura cu CodeIgniter, bineinteles). Eu am trimis un request inca din faza de pre-beta, dar nu va spun inca despre ce e vorba.

Poate apare in curand si va anunt intr-un articol.

Am aflat azi de pe Twitter ca se pregateste un proiect foarte util, sub numele de CodeIgniter TV.

Desi numele este cat se poate de sugestiv, am sa explic in cateva cuvinte ce inseamna acest lucru. Echipa din spatele proiectului isi propune sa prezinte tutoriale video de 10 pana la 15 minute care se concentreaza pe realizarea unui singur task.

Desi nu este o initiativa Ellis Lab, ma bucur ca exista un astfel de proiect in desfasurare, mai ales ca Adobe (de exemplu) a inteles de foarte mult timp utilitatea unui astfel de site (vezi tv.adobe.com).

Am descoperit din proprie exeperienta, ca vazand astfel de tutoriale video (chiar si pe teme pe care le cunosti), poti afla lucruri “colaterale” pe care nu le stiai. Si intr-un framework atat de versatil si dinamic, asa cum este CodeIgniter, sunt convins ca vor exista mereu lucruri de vazut.

Se pare ca in acest moment nu exista continut, dar daca mergeti la codeigniter.tv puteti sa le lasati datele de contact si ei promit ca va vor anunta cand sunt gata.

Eu le-am lasat deja si astept cu nerabdare aparitia primelor episoade.

Nu va panicati. Situatia nu este atat de grava cum lasa sa se inteleaga titlul. Este adevarat, ca de azi incolo mi-am propus sa nu mai instalez CodeIgniter. Asta pentru ca am de gand sa fac upgrade de acum.

Sa va explic. Pana acum, de cate ori aparea o versiune noua de CodeIgniter, ma duceam repede si o descarcam. Din comoditate, faceam un backup la ce aveam pana acum si puneam noua versiune pentru a lucra pe ea. Cu alte cuvinte, niciodata nu faceam upgrade la o noua versiune. De fiecare data plecam de la zero.

Dupa ce la ultima lansare EllisLab ne-a pus la dispozitie un ghid de upgrade, mi-am dat seama ca abordarea mea este profund gresita din doua motive.

Unul este faptul ca pierd un pas important in experienta cu framework-ul. Partea de upgrade. O componenta importanta a unui framework bun este usurinta in utilizare, iar upgrade-ul de la o versiune ar trebui sa fie un criteriu important de masurare a acesteia.

Cel de-al doi-lea motiv si cel mai important, este simularea mediului de productie. In development e simplu. Stergi tot si o iei de la capat. Dar ce te faci cand ai o aplicatie care ruleaza deja in productie. Ai putea sa o lasi la versiunea pe care ai construit-o, dar mai sunt update-uri de securitate pe care nu e bine sa le eviti.

Astfel, experienta upgrade-ului in mediul de development ne poate scuti de multa bataie de cap la upgrade-ul pe server. Asa ca m-am hotarat. De azi incolo nu mai instalez CodeIgniter; il upgradez.

In urma cu ceva timp, scriam acest articol in care va anuntam ca EllisLab pregateste lansarea versiunii 2.0 a framework-ului CodeIgniter. Iata ca aceasta a sosit si vine cu cateva modificari. O parte din ele era natural sa se intample, iar altele sunt imbunatatiri aduse in intampinarea programatorilor.

Voi trece in lista cateva modificari ce au avut loc de la CodeIginter 1.7.3 la 2.0. Voi incepe cu cele pe care le-am numit evolutie naturala si care, dupa parerea mea, era normal sa se intample:

• A fost eliminat suportul pentru PHP 4. Cerintele minime sunt PHP 5.1
• Functia de Scaffolding a fost eliminata (oricum n-am folosit-o niciodata)
• Clasa Validation Class (inlocuita mai demult de Form Validation Class) a fost eliminata
• Nu mai exista Plugin-uri (se folosesc Helper-ii in schimb)

Sa trecem acum la noutatile pe care CodeIgniter 2.0 ni le pune la dispozitie:

• Form Helper-ul vine cu protectie nativa CRSF (Cross Site Request Forgery)
• S-a adaugat $route["404_override"] pentru ca erorile 404 sa poata fi gestionate de Controller
• Autodetectarea base_url-ului daca e lasat gol (printre preferatele mele)

Merita mentionat faptul ca, in afara de ultima, toate modificarile se gasesc si in CodeIgniter Core dar echipa EllisLab insista  ca Reactor a trebui sa fie prima alegere (diferenta dintre cele doua o gasiti aici). De altfel au si spus, ca de acum, Reactor = CodeIgniter, iar Core va fi folosit doar de cei care insista sa faca asta din motive de ei stiute.

Comunicatul oficial il gasiti aici. Eu am deja o versiune beta de CodeIgniter 2.0 pe care ma joc de ceva timp. Abia astept sa il iau pe cel nou si sa-mi bag nasul in documentatie sa vad ce mai e nou.

Acum ceva vreme, scriam despre validarea formularelor cu ajutorul lui CodeIgniter. Puteti citi despre asta, aici si aici. Cei dintre voi care au avut curiozitatea incerce codul scris acolo, au observat probabil un mic bug. Atunci cand se face repopularea formularului, campul Website este omis. Chiar daca acesta este completat, dupa validare el va fi gol.

Acest lucru se intampla deoarece, desi am folosit functia set_value() ca la celelate campuri, acesta nu este mentionat in regulile de validare din Controller. Astfel, nefiind validat, campul nu era incarcat automat in seria de date care erau trimise inapoi catre formular daca validarea nu reusea.

$inputWebsite = array(
	'name' => 'website',
	'id' => 'website',
	'value' => set_value('website'),
	'maxlength' => '100'
);

<p><?php echo form_input($inputWebsite); echo form_label('Website', 'website') ?></p>

Initial nu am vrut sa validez un camp doar pentru ca acesta sa ajunga inapoi in formular, asa ca am cautat tot felul de metode de a forta clasa FormValidation() sa repopuleze campul respectiv. Am cautat un parametru special, sau o functie built-in, dar fara succes. Dupa aceea m-am gandit ca as putea sa-l incarc eu intr-un $data['webiste'] si sa folosesc in View variabila $website, dar parea mai degraba peticit.

Prin urmare, m-am intors la prima idee. Sa validez campul chiar daca nu am un requirement specific pentru el. Am ales sa folosesc o functie inofensiva si deloc restrictiva, si anume trim(). Astfel, in Controller-ul meu a mai aparut urmatoarea linie de cod:

$this->form_validation->set_rules('website', 'Website', 'trim');

Astfel, continutul inputului Website ajunge in setul de date trimis inapoi catre formular si este repopulat la fel ca toate celelalte.

Initial m-am intrebat cum de le-a scapat celor de la CodeIgniter sa trateze acest caz? Daca totusi cineva nu vrea sa valideze un camp, de ce ar trebuie sa fie obligat sa o faca?

Dupa ce m-am gandit mai bine, mi-am dat seama ca situatia asta nu-i atat de rea. Indiferent daca un camp are sau nu vreun requirement special, trebuie sa facem macar trim pe el. Nu m-as fi gandit la acest lucru daca nu ma loveam de aceasta situatie. In felul acesta mi-am dat seama ca e important sa faci, daca nu validare, cel putin un pic de “curatenie” pe fiecare camp, iar trim se ocupa foarte bine de acest lucru.

Cei de la EllisLab au anuntat un mic update pentru CodeIgniter 1.x. Si anume CodeIgniter 1.7.3. Din comunicatul lor, se pare ca este un update minor continand un patch la clasa de Upload si un fix de securitate care a aparut in 2.0 si era prea bun sa nu fie adus si aici. Cam atat, din ce spun baietii. Daca vreti, gasiti articolul aici.

Eu am trecut deja la CodeIgniter 2.0, asa ca nu am sa mai fac update. Bineinteles, asta in mediul de development. In productie nu am de gand sa portez prea curand…