CodeIgniter este un framework open-source scris in PHP care se bazeaza pe principiul RAD.
Cartea CodeIgniter 1.7 de la PacktPublishing, scrisa de Jose Argudo Blanco si David Upton urmareste formarea unei imagini de ansamblu asupra framework-ului CodeIgniter, venind in completarea manualului.

Cartea nu este o referinta, iar acest lucru este evident in fiecare capitol cand se foloseste una dintre facilitatiile framework-ului, cititorul este mai apoi directionat catre pagina din user guide sau wiki care corespunde modulului respectiv. Ba chiar mai mult exista si sugestii catre module alternative care realizeaza aceeasi sarcina.

Autorii sustin ca pentru a citi aceasta carte sunt necesare doar cunostinte minime de PHP, o promisiune destul de greu de respectat dupa parerea mea, in general cartile care au ca target cititorii incepatori-medii sustin acest lucru. Spre surprinderea mea au avut dreptate, cititorul are nevoie doar de cunostinte de PHP4. Iar cand vine vorba de OOP nici macar nu sunt necesare cunostinte de PHP5 ci pur si simplu modelul obiectual din PHP4. In carte exista chiar si explicatie pentru copierea prin referinta! Evident copierea prin referinta nu mai este relevanta in PHP5, dar avand in vedere ca este un framework de PHP4 probabil ca trebuia mentionata. Se pare ca inca mai exista servere de PHP4 pe internet… pur si simplu trist…

Citind cartea au inceput sa-mi vina flashback-uri cu bucati de cod scrise direct in PHP si chinul de a face debugging pe ele, incercand sa inteleg munca altora… ce vremuri… groaznice desigur. Explicatia mi se pare foarte buna pentru a intelege concenptul de refolosire din spatele unui framework: “Possibly you like typing regex. Some people like lying on a bed of nails…”. Cred ca pentru un programator, in special incepator, sa citesti asa ceva te face sa realizezi ca nu trebuie sa reinventezi roata de fiecare data ci pur si simplu sa folosesti solutii gasite de altii.

Comparatia intre solutii, cred ca este cea mai amuzanta parte dintr-o carte de acest gen. Este greu sa compari de exemplu Zend Framework sau chiar CakePHP cu CodeIgniter. Pana la urma fiecare din framework-uri spun acelasi lucru, descarci si incepi sa lucrezi. Eu personal cand vreau sa folosesc un modul din Zend pur si simplu incarc autoloader-ul si trec la treaba. Din comparatie rezulta cum era de asteptat ca CodeIgniter este cea mai potrivita in general, motivatia sa spunem ca este relativ buna si destul de cinstita. Pana la urma este un framework mic si nu are facilitati complexe cum ar fi generare automata de CRUD. Imi amintesc de o carte de Java unde autorul prezenta faptul ca C++ este mai rapid decat Java ca pe un dezavantaj, evident este ridicol.

Am avut de cateva ori impresia ca exprimarea este gresita. Autorul se foloseste de “mici” greseli in termeni pentru a explica ce se intampla de fapt in spate. Cand lucrezi cu framework-uri MVC unele lucruri sunt simple si evidente, dar pentru un programator care nu este familiar cu notiunile sunt destul de greu de inteles.

Iar ca sa continui cu greselile, am gasit cateva in carte. Un moment destul de dificil cand inveti ceva nou. Din fericire sunt destul de evidente pentru ca se concretizeaza in erori, iar daca citesti cartea capitol dupa capitol vei sti ce ai de facut ca sa le repari.

Exemplele mi se par destul de consistente si bine explicata. Cand se introduce o notiune noua aceasta este explicata destul de in detaliu.

Aplicatiile rezultate nu sunt foarte complexe, de exemplu la final nu rezulta o aplicatie complexa cum ar fi cu CMS, mai degraba sunt explicate module si modul de folosire impreuna a acestora. Cititorul la final va trebui sa decida ce si cum va arata aplicatia lui. De exemplu in capitolul 13 se explica paginarea si ordonarea. Cand se face paginarea totul e ok, dar cand se face si ordonarea paginarea incepe sa dea rateuri. Mi-a luat cam 5-10 minute sa remediez problema, dar ar fi fost frumos ca aceasta problema sa fie rezolvata de catre autori.

In ansamblu mi se pare o carte reusita, in special daca nu ai cunostiinte de CodeIgniter, este asa cum o prezinta si autorii, o carte pentru dezvoltatori care vor mai multa productivitate in munca lor sau pur si simplu sunt la inceput si vor sa vada ce unelte exista. Cartea totusi nu prezinta solutii mai complexe cum ar fi un CMS sau un shopping cart ci pur si simplu ce are acest framework de oferit.

Un programator avansat poate intelege din aceasta carte structura framework-ului CodeIgniter, eventual pentru a o compara cu alte framework-uri concutente, fara sa piarda vremea cu exemple complexe si irelevante.

Acum mai bine de un an de zile am scris un blog, in care ziceam ca Google nu stie unde stau.

Problema era ca Goole Maps avea o acoperire deosebit de proasta pentru Romania, iar Yahoo! Maps este o alternative mult mai buna pentru aceasta parte a europei. Inca mai cred ca Yahoo! Maps este o alternativa mult mai buna dar am fost surprins totusi de un lucru. In decursul tipului am tot intrat pe Google Maps pentru ca sa vad cum mai sta acoperirea pe Bucuresti, practic era o singura cale reprezentata pentru a ajunge de la autostrada A1 la A2 si nimic mai mult.

Acum aproximativ o luna, am intrat din nou pentru ca trebuia sa construiesc o aplicatie de turism in Romania si… surpriza, surprize, chiar daca pozele din satelit sunt de calitate mai proasta acum, am putut nu doar sa gasesc folosind cautarea strada pe care stau dar si blocul. Mai mult de atat, am putut calcula trasee alternative catre diverse locatii din Bucuresti.

Se pare ca Google a inceput sa aiba ceva mai mult interes pentru aceasta zona din centru Europei, acum permitand formarea unei concurente reale cu Yahoo!. Asta este un foarte mare avantaj pentru cei care au telefoane cu Android si folosesc Google Maps ca aplicatie de GPS. Acum cativa ani, sa folosesti Google Maps in Romania era complet inutil, puteai sa vezi intradevar imaginile din satelit, dar cam atat, nu puteai sa gasesti adrese utile, iar daca erau cumva marcate pe harta nu puteai sa calculezi un traseu catre acestea.

Pana la urma aplicatia am rezlizat-o folosind Google Maps, desi inca sunt de parere ca Yahoo! Maps este o foarte buna alternativa, atat de punctul de vedere al calitatii cat si ca API. Si ca tot vine vorba de API, ambele mi se par ok si nu cred ca acest criteriu este unul de diferentiere intre cei doi giganti.

O chestie putin socanta totusi legata de Google stie unde stau a fost intr-o seara cand curios sa vad daca GPS-ul de pe telefonul meu functioneaza am iesit pe balcon. Totul a fost ok, m-a gasit cu o aproximatie intre 50 si 100m pe harta Google folosind conexiunea mea de wireless pentru transferul de date. Intr-o alta seara un prieten a venit la mine si am incercat acelasi lucru, tot pe aceeasi conexiune de internet, acelasi program Google Maps, cu o apximatie constanta de 100m.

Teoretic nimic anormal, totul a devenit bizar cand a doua zi am aflat ca de fapt telefonul lui nu are GPS, deci ce vedeam noi era ultima conecare de la dispozitivul meu… deci Google chiar stie unde stau… la propriu…

Se pare ca Oracle a primit aprobarea de la EU pentru a cumpara Sun conform Yahoo! News.

Acum aproximativ un an jumatate ma gandeam sa sustin examenul pentru MySQL Certified Developer. Acum dupa ce am devenit Sun MySQL Certified Developer se pare va voi deveni Oracle MySQL Certified Developer. Si toate acestea fara nici un ban in plus! 🙂

Partea buna este ca vom ajunge sa lucram cu Oracle chiar si fara voia noastra (ok, nu e chiar Oracle, dar e un produs al lor).

Factory method design pattern introdus de GoF (Gang of Four) pe care l-am abordat si eu intr-un blog anterior, are la baza ideea unei metode care genereaza obiecte. In general implementarea este destul de “slaba” pentru ca “factory”-ul este destul de hardcodat (la fel ca mine in blogul anterior).

PHP 5.3 ofera totusi posibilitatea unei implementari foarte interesante folosind “Late static bindings“.

Clasele pe baza carora se vor genera obiectele:

 1// clasa abstracta de baza care urmeaza sa fie mostenita
 2abstract class Drink {
 3
 4    // ingrediente
 5    protected $ingredients;
 6
 7    // metoda publica care genereaza bautura
 8    abstract public function MakeDrink();
 9}
10
11// o clasa derivata pentru ceai
12class Tea_Drink extends Drink {
13
14    // ingrediente pentru ceai
15    protected $ingredients = array('tea', 'sugar', 'mink', 'water');
16
17    // generare ceai
18    public function MakeDrink() {
19
20        // fa ceai
21    }
22}
23
24// clasa derivata pentru Bloody Mary
25class BloodyMary_Drink extends Drink {
26
27    // ingrediente Bloody Mary
28    protected $ingredients = array('votka', 'salt', 'tomato juice');
29
30    // generare Bloody Mary
31    public function MakeDrink() {
32
33        // fa BloodyMary
34
35    }
36}

Idea este de a avea o clasa abstracta care va fi extinsa intr-un mod cat mai simplu pentru a genera noi clase factory.

PHP 5

In PHP 5 clasa ar arata cam asa:

 1// clasa Factory abstracta
 2abstract class absFactory {
 3
 4    // numele clasei de baza
 5    static protected $base_class = '';
 6
 7    // metoda factory
 8    public static function getInstance($type) {
 9
10        // numele clasei rezultat
11        $class_name = $type . '_' . self::$base_class;
12
13        // se testeaza daca clasa exista
14        // aici se poate adauga si un autoloader eventual
15        if(!class_exists($class_name)) {
16            throw new Exception( 'Class ' . $class_name . ' not loaded!');
17        }
18
19        // se verifica daca clasa mosteneste clasa de baza
20        if(!is_subclass_of($class_name, self::$base_class)) {
21            throw new Exception(
22                'Class ' . $class_name . ' is not a child of ' . self::$base_class
23            );
24        }
25
26        // noul obiect
27        return new $class_name;
28
29    }
30
31}

Pentru ca metoda getInstance este statica si proprietatea este statica.

Daca incercam:

 1class DrinkFactory extends absFactory {
 2
 3    static protected $base_class = 'Drink';
 4}
 5
 6try {
 7
 8    $obj = DrinkFactory::getInstance('Tea');
 9
10} catch (Exception $e) {
11
12    echo $e->getMessage();
13}

Output-ul va fi:

1Class Tea_ not loaded!

Din pricina “self”, nu putem apela pur si simplu metoda getInstance() din clasa copil pentru ca valoarea lui $base_class va fi “” in loc de “Drink”, trebuie suprascrisa metoda getInstance(). Lucru prea “complicat”.

O versiune functionala in PHP 5 ar fi:

 1class DrinkFactory extends absFactory {
 2
 3    public static function getInstance($type) {
 4
 5        self::$base_class = 'Drink';
 6
 7        // metoda factory a clasei factory de baza
 8        parent::getInstance($type);
 9
10    }
11
12}
13
14try {
15
16    $obj = DrinkFactory::getInstance('Tea');
17
18} catch (Exception $e) {
19
20    echo $e->getMessage();
21}

Dar nu mi se pare tocmai “elegant”.

PHP 5.3

Aici avem “Late static bindings”, care in principiu este introducerea cuvantului “static”.

Clasa de baza factory arata cam asa:

 1// clasa Factory abstracta
 2abstract class absFactory {
 3
 4    // numele clasei de baza
 5    static protected $base_class = '';
 6
 7    // metoda factory
 8    public static function getInstance($type) {
 9
10        // numele clasei rezultat
11        $class_name = $type . '_' . static::$base_class;
12
13        // se testeaza daca clasa exista
14        // aici se poate adauga si un autoloader eventual
15        if(!class_exists($class_name)) {
16            throw new Exception( 'Class ' . $class_name . ' not loaded!');
17        }
18
19        // se verifica daca clasa mosteneste clasa de baza
20        if(!is_subclass_of($class_name, static::$base_class)) {
21            throw new Exception(
22                'Class ' . $class_name . ' is not a child of ' . static::$base_class
23            );
24        }
25
26        // noul obiect
27        return new $class_name;
28
29    }
30
31}

O schimbare atat de mica permite totusi o clasa factory mult mai “atragatoare”:

 1class DrinkFactory extends absFactory {
 2
 3     static protected $base_class = 'Drink';
 4
 5}
 6
 7try {
 8
 9    $obj = DrinkFactory::getInstance('Tea');
10
11} catch (Exception $e) {
12
13    echo $e->getMessage();
14}

Practic in aceasta varianta nu se inlocuieste decat proprietatea statica relevanta in acest context.

Un design patten creational care reprezinta o solutie pentru a genera obiecte fara sa se specifice clasa acestuia. In mod particular orice metoda care genereaza obiecte reprezinta o implementare de Factory Method pattern.

Motivatie:

O motivatie este ca, sarcina de a creea obiectul este delegata catre metoda factory.

Diagrama:

Implementare:
Clasele care genereaza obiecte prin factory, clasa comuna care va fi extinsa si clasa cu metoda fatory:

  1// clasa comuna care va fi extinsa
  2abstract class OutputBase {
  3     // output headerele necesare
  4     abstract public function header();
  5
  6     // corpul rezultat
  7     abstract public function body($data);
  8
  9}
 10
 11// clasa pentru output xml
 12class XMLOutput extends OutputBase {
 13
 14     // output header xml
 15     public function header() {
 16          header('content-type: text/xml');
 17     }
 18
 19     // document xml
 20     public function body($data) {
 21          $res = '';
 22
 23          $res .= '';
 24
 25          foreach ($data as $root => $item) {
 26
 27               $res .= '';
 28
 29               foreach ($item as $key => $val) {
 30                    $res .= '<'.$key.'>'.$val.'';
 31               }
 32
 33               $res .= '';
 34          }
 35
 36          $res .= '';
 37
 38          return $res;
 39
 40     }
 41
 42}
 43
 44// clasa pentru output csv
 45class CSVOutput extends OutputBase {
 46
 47     // output header csv
 48     public function header() {
 49          header("Content-type: text/plain");
 50     }
 51
 52     // corp csv
 53     public function body($data) {
 54          $res = '';
 55
 56          $keys = array_keys($data[0]);
 57
 58          foreach ($keys as $key) {
 59               $res .= '"'.$key.'";';
 60          }
 61          $res .= "\r\n";
 62
 63          foreach ($data as $item) {
 64               foreach ($item as $val) {
 65                    $res .= '"'.$val.'";';
 66               }
 67
 68               $res .= "\r\n";
 69          }
 70
 71          return $res;
 72     }
 73}
 74
 75// clasa cu metoda factory
 76// este abstracta pentru a nu fi instantiata
 77abstract class OutputFactory {
 78
 79     // constanta pentru timpul xml
 80     const XML = 1;
 81
 82     // constanta pentru tipul csv
 83     const CSV = 2;
 84
 85     // metoda statica factory
 86     public static function getInstance($type) {
 87          // in functie de constanta primita ca parametru
 88          // va intoarce unul din obiecte
 89          switch ($type) {
 90               case self::XML :
 91                    return new XMLOutput();
 92               break;
 93
 94               case self::CSV :
 95                    return new CSVOutput();
 96               break;
 97          }
 98
 99          // daca valoarea primita ca parametru nu este una din constante
100          // se arunca o exceptie
101          throw new Exception('Invalid class type!');
102     }
103
104}

Exemplu:

 1// se de date
 2$data = array(
 3               array(
 4                    'a' => 1,
 5                    'b' => 2,
 6                    'c' => 3
 7                    ),
 8               array(
 9                    'a' => 4,
10                    'b' => 5,
11                    'c' => 6
12                    )
13          );
14
15//Bloc try-catch pentru a prinde eventualele exceptii
16try {
17     // generare obiect
18     $obj = OutputFactory::getInstance(OutputFactory::XML);
19
20     // output headere
21     $obj->header();
22
23     // afisare body
24     echo $obj->body($data);
25
26} catch (Exception $e) {
27
28     $e->getMessage();
29
30}