Packt Publishing a scos o noua carte despre framework-ul PHP de tip RAD, CodeIgniter versiunea 1.7.  Cartea CodeIgniter 1.7 Professional Development scrisa de Adam Griffiths , are sloganul “become CodeIgniter experts with professional tools, techniques and extended libraries”.

Doar din slogan se vede un ton putin diferit fata de cartea CodeIgniter 1.7 de la Packt Publishing care dupa parerea mea avea mai mult scopul de a arata ce poate face framework-ul CodeIgniter.

Aceasta noua cartea are mai mult scopul de a arata cum poti dezvolta aplicatii profesionale, sau cel putin pana la proba contrarie, stay tuned to find out!

Un argument pentru slogan este si target-ul asa cum este definit in “Who this book is written for”, care contine fraza:

Basic knowledge of CodeIgniter will be helpful.

O fraza periculoasa dupa parerea mea, pentru ca poate speria un incepator, chiar daca in carte se pare ca sunt descrisi toti pasii de la instalarea serverului.

Daca de la prima carte ma asteptam la o prezentare generala, acum sunt curios sa vad daca exemplele sunt mai ample si mai concrete.

Din capitoul mostra se poate vedea ca in care este foarte mult cod. Cat timp este logic cred ca este bine, este de multe ori mai usor sa intelegi din cod, pe care oricum il vei scrie si tu si il poti lua drept exemplu, decat teorie.

Dar mai multe despre aceasta carte dupa ce voi avea ocazia sa o lecturez.

Va urma…

PHP pentru desktop, merita?

PHP este descris pe Wikipedia ca fiind:

PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language that was originally designed for web development to produce dynamic web pages.

Luand in considerare aceste lucruri, aplicatiile se impart in 3 categorii: web, command line si desktop.

Pentru mediul Web, PHP este cel mai popular limbaj open-source (si nu numai).

PHP CLI

PHP CLI (Command Line Interface) mi se pare foarte interesant, chiar daca este cam putin folosit. Multi prefera shell scripting, sau Perl fara nici un motiv real. Eu pot spune ca m-am jucat cu aceasta facilitate si mi-a placut rezultatul.

Framework-uri importante, cum ar fi Zend, Symfony sau Cake PHP se folosesc de PHP CLI pentru a genera proiecte, CRUD sau pentru alte facilitati care se pot folosi cu usurinta in linie de comanda.

In windows linia de comanda nu este tocmai populara, dar in linux este aproape imperativ. Pana la urma ce rost are sa faci un script in shell scripting daca poti sa folosesti un limbaj puternic si cu foarte multe facilitati cum ar fi PHP?

Dar CLI nu se limiteaza doar la linia de comanda, este de mai multe ori folosit pentru cronjob-uri, pipe-uri, socket-servere etc.

PHP-GTK

Cand vine vorba de php si desktop majoritatea se gandeste la PHP-GTK. Ce cred despre proiect? Nu e mort dupa cum scrie si pe site-ul oficial, dar nu este tocmai viu. Motivul? Gtk nu e tocmai simplu. Daca provi din mediul linux probabil nu e asa de dificil, daca insa ai lucrat mai mult pe web, nu e tocmai html… Cu toate acesta exista o comunitate in spate care inca sustine acest proiect.

Cu toate astea iti permite sa construiesti aplicatii desktop in PHP, compatibile cu o gama larga de sisteme de operare.

Dar este totusi o problema, aplicatiile rezultate nu sunt tocmai cod compilat, acestea trebuie sa ruleze folosind o masina virtuala de PHP.  De aici apare problema, cum distribui aplicatia? Daca ai o aplicatie mica, de cateva randuri, sa o distribui impreuna cu masina virtuala este cam complicat… De asemenea codul este vizibil, evident exista metode de a rezolva aceasta problema, dar asta nu este tocmai simplu.

Aceasta este probabil cea mai populara platforma PHP pentru desktop, daca se poate spune asta despre acesst mediu.

Documentatia, destul de stufoasa a fost preluata de la versiunea pt. C++. Nu este la fel de bine finisata cum e manualul oficial PHP de exemplu, dar cred ca este suficienta.

Winbinder

Fata de PHP-GTK are un dezavantaj, nu merge decat pe sisteme de operare MS Windows. Avantajul este ca are un API mult mai simplu. Daca ar fi sa aleg o platforma PHP pentru desktop, probabil Winbinder ar castga. Din pacate este in aceeasi stare, nu e mort dar nici viu. Si acesta se bucura de sprijinul unei comunitati, dar fara rezultate iesite din comun.

Problema cu codul compilat se regaseste si aici, ba mai mult problema legata de distributia platformei este si ea prezenta. Cred cu fermitate ca daca vrei sa dezvolti o aplicatie folosind aceasta platforma, sa o faci sa mearga pe calculatorul tau este cea mai mica problema, sa o faci sa mearga pe calculatorul altcuiva este adevarata problema…

Documentatia este destul de mica, datorita simplitatii API-ului. Dar simplitatea este buna in programare, iar asta inseamna ca poti cu usurinta sa construiesti aplicatii destul de interesante.

Compilatoare

Nu sunt multe, iar majoritatea au probleme pentru ca folosesc versiuni vechi de PHP sau chiar de GTK. Am petrecut multe ore pe Google incercand sa gasesc niste solutii reale dar in zadar.

Principalele compilatoare sunt:

• Bambalam – functioneaza pentru CLI si Winbinder fara probleme. Dar are un dezavantaj important: nu este compatibil decat cu PHP 4.4.4, iar asta cred ca spune tot. Oricum mi se pare cea mai interesanta solutie, din pacate prea veche (ultima versiune a aparut in 2006).
• PriadoBlender – functioneaza bine cu PHP-GTK si CLI, dar este cam instabil. Ultima versiune (beta) a aparut in anul 2007, de atunci nu s-a mai auzit nimic nou. Daca probabil ar mai fi actualizat aceasta versiune ar ajuta mult proiectul PHP-GTK.

Concluzie

Cand vine vorba de Web, totul merge excelent!

PHP in linie de comanda devine tot mai popular si apar tot mai multe unelte!

In mediul desktop este o senzatie de “living dead”… Aceste proiecte nu au murit dar nici nu sunt tocmai in viata. Evident mai sunt si alte solutii PHP pentru desktop pe care nu le-am amintit, dar si ele sunt tot cam in aceeasi situatie. Probabil ar trebui o abordare diferita, mai atractiva pentru dezvoltatorii din mediul web pasionati de acest limbaj.

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}

CodeIgniter este un framework open-source scris in PHP care se bazeaza pe principiul RAD. Popularitatea acestui framework este in continua crestere, probabil in special de cand lumea a descoperit ca e mult mai usor sa folosesti un framework open-source decat sa dezolti unul intern, dar asta este alta discutie. 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.

Pana la urma orice framework care se respecta are o referinta detaliata a acestuia, cu eventuale exemple, mai mult sau mai putin cuprinzatoare. Atunci cand vine vorba de invatarea unui framework (si nu numai), o referinta de cele mai multe ori nu este un punct bun de plecare, pentru ca nu poti cauta in aceasta solutii de ansamblu cand primesti explicatii atomice. De asta ajungem sa cumparam carti, pentru a avea o prezentare generala cu probleme si solutii. Si asa am ajuns la cartea CodeIgniter 1.7.

Initial cand am vazut ca titlul cuprinde numarul versiunii framework-ului pe care il analizeaza am fost putin pesimist, pentru ca atunci cand cumperi o carte nu o vrei neaparat legata de o versiune, nu? Nuprea… eu am avut problema asta cu Zend Framework de exemplu, majoritatea cartilor prezinta versiuni “mai vechi” (ex: 1.5-1.6) iar eu vroiam sa vad o abordare cu noile facilitati din versiunea 1.8 sau mai mare. Pana la urma atunci cand inveti vrei de obicei o versiune mai noua a framework-ului, iar cand vor aparea facilitati noi probabil va fi mai simplu sa le citesti doar in referinta.

artea se pare ca porneste de la nivelul de incepator si ataca progresiv atat elementele de baza cat si cele mai frecvente probleme cu care utilizatorul se poare intalni in dezoltarea de aplicatii folosind framework-ului CodeIgniter. Capitolul mostra, pare destul de bine structurat si usor de inteles, iar din cuprins pare sa atace toate subiectele importante, asa ca in speranta ca si restul cartii va fi la fel si ca va mai urma si o parte a doua la acest “review” astept cu nerabdare cartea.

Va urma…