In PHP we Trust

Although I’d normally write this article in Romanian I expect a wider audience for it, so I will post it in English.

Snippet

If you don’t want to read the entire article here are some shortcuts:

• Donwload the Dance-Tunes Client Library
• See the code
• Download Zend Framework

Dance-Tunes.com

Dance Tunes Logo

Dance-Tunes is a music online store, located in the Netherlands, where one can buy their favorite … dance tunes, of course. Organised in eight main genres (Downtempo, Dance, Techno/Minimal, Hardcore, Breaks, Electro/House, Hardstyle/Jump and Trance) Dance-Tunes has an extensive database of tunes, artists and labels.

The Public API

On the 22^nd of February 2010, Dance-Tunes released their 1.0 version of the API. The main purpose of the API is to help create rich internet applications that are based on the information of tunes, artists, labels or charts. Developers are encouraged to use the public Dance-Tunes API to get creative and use the extensive library of labels, artists and tracks in their sites or applications.

Dance-Tunes has created a special page for developers where one can find all information about the public API. Each individual API call is explained and examples are given to show the correct structure of the calls and response. One can request an API key by logging in using the Dance-Tunes account details. The API key will be sent to the developer’s email address. One can download the API documentation in pdf format for printing and off-line viewing.

The PHP Client

The Dance-Tunes PHP API Client that I am releasing today, was written with intention of integrating into a Zend Framework application. As of this it follows the PHP File Formatting, Naming Conventions and Coding Style recommended by the Zend Framework Team.

It uses the Zend_Http and Zend_Exception packages from the Zend Framework classes. It can be used either with an entire Zend Framework application or as is. The dependencies can be load by themselves (just the 2 packages), or the Dancetunes class can be modified in order to be used in a simple PHP project. One can replace the use of Zend_Http package with the use of the cURL library and the Zend_Exception with the PHP base Exception.

Usage

Each of the documented function in the Dance-Tunes API has a corespondent wrapper method in the Dancetunes class that accepts the exact amount of parameters that the API requires, except the command and the session(params cmd and session) which are built in. For each session key, as the documentation specifies, a timestamp is updated on each request, and the session key is deleted if no request is performed for 6 hours. So, as a best practice, it is recommended to cache the session key locally for immediate access to the resources on other requests.

$dancetunes = new Dancetunes(DT_API_KEY);

if (!($sessionKey = $cache->load('sessionkey')))
{
    $dancetunes->setUserName(DT_USERNAME);
    $dancetunes->setPassword(DT_PASSWORD);

    $sessionKey = $dancetunes->authenticate();
    $cache->save($sessionKey, 'sessionkey');
}
$dancetunes->setSessionKey($sessionKey);

/* Get the first 10 releases */
$releases = $dancetunes->getNewReleases(11, 10, 1, 10);

/* Get a preview */
$audio = $dancetunes->getPreview( 123456 );
/* saving the audio content to disc */
file_put_contents('123456-tune-preview.mp3', $audio);

Responses

Dance-Tunes API will respond either with an XML string or with binary data (for artwork and preview). For the case of XML response I have created a Dancetunes_Vo class that takes a XML string and converts it into an array. Also for each response type I have created an individual class that extends the Dancetunes_Vo class and implements some particular methods for a specific result. For example the Dancetunes_NewReleases class will be the result of the Dancetunes::getNewReleases method and has a method for returning just the tunes info from the response, and another one to return the number of total possible tunes that can be returned on a specific request.

class Dancetunes_NewReleases extends Dancetunes_Vo {

    public function getTracks() {
        return $this->_array ['new_releases'] ['tune'];
    }

    public function getCount() {
        return $this->_array ['new_releases'] ['total_count'];
    }
}

These classes can be modified or extended in order to deal in a specific way with the XML response.

License

The package is released as an open source project under The New BSD License.

Copyright (c) 2010, George Enciu, ColorSoft System SRL, Romania

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of the ColorSoft System SRL nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Change Log

2010-04-06

• Version 0.1 BETA released

2010-05-15

• Added a version written in simple PHP
• Still in 0.1 Beta

Download

All the code and download files can be found at the Google Code Project

În timp ce programatorii PHP încep să descarce si să testeze cea mai mare modifcare adusă limbajului de programare din ultimii 7 ani, mulţi se întreabă nu despre ce le-a adus Moş Crăciun în sacul lui plin de jucării pentru a le folosi în dezvoltarea aplicaţiilor de mâine ci despre modificările aduse în limbajul de programare care vor afecta aplicaţiile de ieri.

Vestea cea buna este că dacă v-aţi ţinut aplicaţia în ton cu modificările aduse limbajului sunt puţine modificări care vă vor afecta. Vestea cea rea este că pe măsura ce vă îndepărataţi de versiunea curentă portarea aplicatiilor devine din ce în ce mai grea.

Ceea ce urmează nu este o listă de noi funcţionalităţi din PHP 5.3, puteţi găsi destule referinţe bune in spaţiul web pentru informare. Acest articol este o sinteză a manualului de migrare la PHP 5.3. Vom acoperi acele subiecte care afectează continuitatea ramurii 5.x

Functii de procesare a vectorilor

Inainte de PHP 5.3, multe din funcţiile folosite la procesarea vectorilor puteau primi ca parametrii un obiect sau un vector. Din PHP 5.3 multe din aceste funcţii vor putea primi doar vectori. Daca doriţi accesarea unei proprietati din obiecte cu una din următoarele funcţii, va trebui să le convertiţi la array în prealabil.

• natsort()
• natcasesort()
• usort()
• uasort()
• uksort()
• array_flip()
• array_unique()

Modificari în funcţiile magice

Înainte de 5.3 metodele magince puteau fi declarate cu orice modificator de vizibilitate.

• __get()
• __set()
• __isset()
• __unset()
• __call()

Din PHP 5.3 aceste metode trebuiesc declarate publice, si nu pot fi statice.

Considerate depăşite

PHP are o lista de funcţii care au fost marcate pentru a fi eliminate din limbaj. Majoritatea acestor funcţii nu au o folosire comună, dar ar fi utilă o verificare a lor. Funcţiile marcate pentru eliminare sunt:

• call_user_method()
• call_user_method_array()
• define_syslog_variables()
• ereg()
• ereg_replace()
• eregi()
• eregi_replace()
• set_magic_quotes_runtime()/magic_quotes_runtime()
• session_register()
• session_unregister()
• session_is_registered()
• set_socket_blocking()
• split()
• spliti()
• sql_regcase()

În plus, căteva din directivele php.ini au fost marcate pentru eliminare. Daca sunt activate ele vor emite un avertisment de nivel E_DEPRECATED:

• define_syslog_variables
• register_globals
• register_long_arrays
• safe_mode
• magic_quotes_gpc
• magic_quotes_runtime
• magic_quotes_sybase

Cum orice emite un mesaj E_DEPRECATED va fi eliminat la urmatoarea versiune majora a limbajului, acestea sunt niste indicii pentru programatori la ce sa se uite pentru trecerea la PHP 6.

Reconsiderare

În PHP 5.0, funcţia is_a() a fost marcată pentru eliminare in favoarea operatorului instanceof, şi totuşi nu a fost eliminată din limbaj. În PHP 5.3, această decizie a fost reconsiderată, iar apelul către funcţia is_a() nu mai emite un mesaj E_DEPRECATED.

Cuvinte rezervate

Au fost adăugate două noi cuvinte rezervate

• GOTO
• NAMESPACE

Având în vedere natura acestor cuvinte este puţin probabil ca ele să existe în codul provenit din versiunile vechi ale limbajului. Totuşi este o idee buna să va scanaţi codul pentru aceste cuvinte rezervate. Dacă există, ele vor genera erori de parsare. Nu pot fi folosite ca nume de funcţii, clase etc.

Concluzie

Ghidul migrarii către PHP 5.3 poate fi găsit în documentaţia de pe php.net. Nu sunt multe elemente din PHP 5.3 care să împiedice un cod bine scris in PHP 5.x sa funcţioneze în versiunea 5.3. Aceasta nouă versiune vine mai mult cu adaugiri la limbaj.

Multumiri

De cele mai multe ori se trece peste aprecierea si multumirea celor care au contribuit la dezvoltarea PHP-ului. Nu cred ca vom trece mai departe fără a face si noi acest lucru. Multumim întregii echipe care si-a dedicat timpul pentru crearea şi îmbunătăţirea PHP-uluiâ

Acest articol este o traducere a articolului Migrating to PHP 5.3.0 aparut in techPortal.

Cache-ul este o zonă temporară de stocare de informatii, care duplică niste date considerate originale, creat pentru acces direct si rapid asupra acestor date. Aceasta mapare a datelor faţă de locul lor de stocare iniţial, se face pentru  acele date care sunt greu de accesat în mod direct, care se afla în zone partajate, care ar avea un timp de prelucrare ridicat si care ar fi solicitate în mod frecvent, iar rezultatul ar fi de fiecare dată acelaşi.

Sisteme de cache se întalnesc implementate în microprocesoare(exemplul fiind cache-ul de nivel 2), în hard disk-uri(pentru a micşora timpul de citire al datelor), în sisteme de management al bazei de date(MySQL va ţine în cache rezultatul unei interogari, iar la primirea aceleiaşi interogări va returna rezultatul din cache, făra a interoga tabelele în sine), in browser-ele pe car ele folosim zi de zi(Firefox de exemplu îşi va face cache la imagini, ca la un refresh sa nu fie nevoit sa le preia de pe server din nou), chiar şi Google deţine propriul cache din care poate furniza conţinutul paginilor web.

Aşadar, scopul declarat al cache-ului este de a economisi timp.

Teoria Cache-ului

Există cateva concepte cheie în teoria cache-ului care trebuiesc respectate în implementarea unui astfel de sistem

1. identificatorul unic – care va fi folosit la identificarea elementului în cache
2. durata de viaţă – defineşte cât timp un element din cache va fi considerat valid
3. preluarea condiţionată – astfel încat părţile din cod care ar accesa informaţiile originale să fie evitate, dar să si permită reîmprospătarea
4. resetarea la cerere – pentru păstrarea consistenţei informaţiilor din cache cu cele din locaţia originală, este necesară posibilitatea ca la o modificare a datelor din această locaţie, cache-ul sa fie marcat ca invalid şi reconstruit

Astfel, un algoritm general de folosire a cache-urilor ar fi:

• dacă elementul din cache cerut de aplicaţie există atunci el va fi returnat intocmai
• dacă elementul din cache cerut nu există atunci datele acelui cache se vor aduce din locaţia originală, se va crea elementul corespunzător în cache, iar datele vor fi returnate aplicaţiei

Aplicare

Aşadar, vom presupune o apicaţie web, pentru care avem un număr mare de accesări atât din partea vizitatorilor dar şi din partea celor care administrează respectivul website. Pentru o şi mai buna exemplificare, vom considera cazul standard al unui magazin online, în care avem listări de categorii, listări de produse din fiecare categorie şi afisări detaliate de produse(preţ, descriere, detalii tehnice etc). În spatele site-ului, respectiv în aplicaţia de administrare a acestuia, avem un număr de operatori care lucrează necontenit la imbunătăţirea informaţiilor prezentate pe acel site. Mai mult decât atât, să mai luam în calcul existenţa unor aplicaţii care periodic sincronizează preţurile şi stocurile produselor cu cele existente la furnizorii direcţi. Pentru a îmbunătăţi imaginea de ansamblu să considerăm ca magazinul are câteva zeci de mii de produse. În cuvinte mult mai simple şi mai tehnice: o mulţime de interogări sql de tip insert, update dar mai ales select.

Dezavantajul unui astfel de scenariu este evident cel al supraîncărcării bazei de date cu interogări care de cele mai multe ori se vor repeta şi vor furniza acelaşi set de date. Cu toate că, de exemplu, MySQL deţine un cache propriu din care returnează un set de date al unei interogari la o repetare a acesteia, aplicaţia PHP care interogheză baza de date va trebui sa realizeze tot protocolul de comunicare, să furnizeze interogarea şi să primească datele, deci nişte timpi deşi mici, deloc de neglijat în contextul unui volum de trafic ridicat.

Continuând scenariul nostru de “groază” mai trebuie luat în considerare faptul ca la o interogare de tip insert sau update, cele cauzate de aplicaţia de administrare, pot apărea lock-uri pe câmpurile, înregistrările sau chiar tabelele din baza de date, deci până la terminarea execuţiei şi scrierea ori modificarea cu succes a datelor în bază, o instrucţiune select, nu va putea citi baza de date pentru preluarea informaţiilor şi va fi pusă în aşteptare până la terminarea tranzacţiei. Rezultă un timp mort şi mai mare. Cache-ul ar trebui sa intervină în astfel de momente, când putem spune ca majoritatea interogarilor vor furniza acelaşi set de date pentru perioade definite de timp,  iar rularea lor nu ne-ar aduce decât dezavantaje.

Interogând baza de date pentru a obţine informaţiile despre produsele din categoria “Monitoare LCD” vom obţine unset de date reprezentat printr-un vector cu produsele din acea categorie. Datele din acest vector pot fi introduse în cache. Conform algoritmului general descris mai sus putem scrie urmatorul cod PHP

if (!($data = loadFromCache('cache_for_category_id_' . $categoryId)))
{
    $data = loadDataFromDatabase($categoryId);
    saveToCache('cache_for_category_id_' . $categoryId, $data, 3600);
}

Plecăm astfel de la premisa ca informaţia căutată se afla în cache şi chiar încercăm să o preluăm. Dacă functia loadFromCache() va întoarce o valoare nulă atunci înseamnă ca datele nu se află în cache şi ele vor trebui aduse din baza de date, lucru ce se va face prin functia loadDataFromDatabase() iar apoi salvate în cache cu ajutorul funcţiei saveToCache(), cache valabil o ora. Chiar dacă presupunerea noastră iniţială referitoare la existenţa datelor în cache este adevărată sau nu, după executarea acestei porţiuni de cod vom avea în variabila $data informaţiile necesare.

Trebuie avut în vedere faptul că în tot acest timp datele considerate valide sunt cele din baza de date, cache-ul fiind doar o copie locala a acesteia. Deşi sistemul ne va reseta automat cache-ul după expirarea perioadei de viaţă, vor exista situaţii când cache-ul va deveni inconsistent, adică nu va mai reflecta realitatea din baza de date. Deci, la adăugarea unui produs nou în baza de date în categoria “Monitoare LCD”, cache-ul construit mai devreme nu mai este consistent(nu conţine si acest nou produs). Cum varianta în care aşteptăm trecerea celor 3600 de secunde pentru a se recrea cache-ul nu ne multumeşte(perioada putând fi mult mai mare), aplicaţia de administrare va trebui sa intervină asupra cache-ului şî să invalideze înregistrarea ce conţine datele din această categorie. În acest mod vom forţa recreerea cache-ului cu noile informaţii la următoarea accesare a categoriei respective.

resetCache('cache_for_category_id_' . $categoryId);

În tot scenariul de mai sus am considerat crearea de cache-uri pe categorii şi nu unul global care să conţină toate categoriile existente pe site, din considerente de acces si de resetare. Este mai simplu sa alegem direct cache-ul categoriei pe care dorim să o afişăm decât sa încărcăm toate categoriile prin care să o căutăm pe cea dorită, precum este mai normal ca la introducerea produsului nou în categorie să resetăm doar cache-ul categoriei respective şi nu cel al tuturor produselor.

Unelte

PHP nu deţine nativ funcţii de lucru cu cache-ul, însă există extensii PECL care pot fi instalate şi cu care se pot lucra, printre care enumerăm Memcache şi APC.

Folosirea extensiei Memcache:

$cache = new Memcache();
$cache->addServer('localhost');

if(!($data = $cache->get('cache_id'))
{
    $data = getData();
    $cache->add('cache_id', $data);
}
$cache->delete('cache_id');

Folosirea extensiei APC:

if(!($data = apc_fetch('cache_id'))
{
    $data = getData();
    apc_add('cache_id', $data);
}
apc_delete('cache_id');

Diferenţa dintre cele 2 extensii este aceea că Memcache va stoca informaţiile în memoria RAM a serverului, pe când APC le va stoca in fişiere pe hard disc.

UPDATE:

A Practical Guide to Data Caching with Zend Server scrisă de Shahar Evron, Product Manager la Zend Technologies, Inc., este o lucrare apărută recent şi pe care o recomandăm celor interesati de acest subiect.

Până la un subiect mai serios, care se află deja în scriere, vin cu o problemă, ce se adresează celor care se considera începători. Mi s-a întamplat sa dau această “problemă” unora de nivelul celui menţionat mai devreme, iar răspunsurile să  mă surprindă de fiecare dată.

Aşadar, dându-se un array (vector) cu 2 milioane de elemente, indexate corespunzător de la 0 la 1.999.999 cu valori de tip string, să zicem sub 1 KB ca dimensiune. 

Scrieţi o funcţie care să determine dacă vectorul în cauză este sau nu mulţime. Evident, se cere un timp de execuţie al funcţiei minim

Un vector este considerat mulţime dacă are toate valorile distincte

Citeam zilele tecute pe The PHP Benchmark un articol  care compară diversele metode prin care se poate parcurge un vector asociativ. În mod normal, un foreach simplu care ne-ar funriza cheia şi valoarea aflată la cel index ar fi de ajuns la fel şi soluţia unui for cu indice de la zero la numarul maxim de elemente, în cazul în care cheile vectorului ar fi numere întregi. Cu toate acestea însă, în cazul unui volum mare de date utilizarea unui foreach, uşoară şi comodă, poate duce la un timp de execuţie foarte mare

reset($aHash);
foreach($aHash as $key => $val)
{
    $aHash[$key] .= "a";
}

Exemplul de mai sus, are timp de executie 409 µs pe un vector de 100 de elemente.

$key = array_keys($aHash);
$size = sizeOf($key);
for ($i=0; $i<$size; $i++)
{
    $aHash[$key[$i]] .= "a";
}

Deşi cel de-al 2-lea exemplu presupune mai multe opreaţii decât primul, timpul de execuţie în conditiile în care furnizăm acelaşi vector de 100 de elemente este de 38 µs ... de 10 ori mai putin.

Protocolul HTTP este poate unul dintre cele mai simple protocoale. Este un protocol care tăieşte în prezent, nu are amintiri şi nici vise care speră să i se îndeplinească în viitor. Tradus în limbaj tehnic acest lucru înseamnă că un server web (care se foloseşte de protocolul HTTP) nu va şti şi nici nu-i va păsa dacă o cerere va veni de la acelaşi utilizator precum precedenta sau de la un utilizator nou. Acesta tratează fiecare cerere ca şi cum ar fi unică şi ca şi cum nu ar avea nici o legătură cu posibile cereri precedente sau viitoare. Acest lucru ar fi un dezavantaj evident, dacă nu ar exista diverse căi de a suplini acest neajuns. O astfel de cale se numeşte sesiune, iar limbajul PHP dispune de o serie de funcţii pentru a uşura lucrul cu sesiuni.

Sesiunile sunt folosite aşadar pentru a crea continuitate între accesările utilizatorilor unui site, chiar dacă aceste au loc la intervale relativ ridicate de timp. Sesiunile sunt stocate pe server, iar la cel mai jos nivel de reprezentare ele sunt nişte fişiere ce sunt stocate într-o zonă sigură a serverului de unde PHP-ul poate avea acces pentru citire, modificare sau creare. Ele sunt menţinute în relaţie cu clientul printr-un identificator de sesiune care va fi stocat la client de regulă într-un cookie(poate fi transmis şi printr-un parametru din GET).

Sesiunile de deschid în două modalităţi: imiplicit şi explicit. Implicit se face prin directiva de configurare aflată în fişierul php.ini numită session.auto_start, care setată pe valoarea 1 va porni implicit sesiunea la începutul rulării oricărui script PHP. Explicit, aceasta se realizează la cererea programatorului folosind funcţia session_start() de regulă la începutul fiecărui script. Avantaje si dezavantaje există de ambele parţi, prin pornirea implicită se evită apelarea în fiecare script al aplicaţiei a funcţiei session_start() însă datorită faptului că o sesiunea se va crea înainte de încărcarea fişierelor auxiliare folosite într-o aplicaţie, cum ar fi cele de definire a claselor, facând astfel imposibilă stocarea unor obiecte în sesiuni. Pornită explicit, funcţia session_start() va trebui apelată întotdeauna înainte de a trimite orice informaţie către client, deoarece aceasta va încerca stabilirea cookie-ului de sesiune, care va fi transmis printr-un header la client.

Informaţiile stocate pe sesiunie se pot regăsi în variabila superglobala $_SESSION care va fi creată automat la pronirea sesiunii şi care va conţine toate informaţiile deja existente pe sesiune. Se pot scrie, citi şi sterge informaţii din această variabilă, care beneficiază de toate avantajele oferite de vectorii limbajului PHP.

session_start();
$_SESSION['isLogged'] = true;

session_start();
if ($_SESSION['isLogged'])
{
    echo "Utilizatorul este autentificat";
}

Presupunând că cele 2 coduri reprezintă fişiere diferite, apelate în ordine vor genera afişarea mesajului de autentificare iar variabila se va păstra pe sesiune până la ştergerea ei sau pănă la distrugerea sesiunii.

O sesiune este persistentă până când aceasta este ştearsă sau până când ea expiră. Timpul de expirare este dat de către timpul de expirarea al cookie-ului păstrat în browser-ul clientului. Directiva session.cookie_lifetime din php.ini este setată implicit pe valoarea zero, şi înseamnă că sesiunea va expira în momentul în care utilizatorul va închide browser-ul. În cazul în care se doreşte forţarea unei sesiuni persistente se poate folosi funcţia session_set_cookie_params(). Distrugerea manuală a datelor existente într-o sesiune se poate face prin functia session_destroy()

Vom începe scrierea unei serii de articole menite să promoveze diverse practici de programare sau utilizare corectă a limbajului PHP, MySQL, Javascript sau a framework-ului de la Zend. Ne vom adresa prin acestea în special începătorilor şi vom încerca să arătăm consecintele unei folosiri incorecte a diverselor facilităţi oferite de limbajele de mai sus.

cURL este un utilitar din linie de comandă folosit pentru transferul de fişiere ce pot fi accesate printr-un URL. Principalul scop şi utilizare a acestui program este automatizarea transferului de fişiere sau secvenţelor de operaţii, fiind o unealtă excelentă de a simula un client web şi acţiunile pe care le poate întreprinde un utilizator în browser-ul lui. cURL suportă transferul de date folosind mai multe protocoale cum ar fi: HTTP, HTTPS, FTP, FTPS, TFTP, Telnet, SCP precum şi altele.

Pentru ca această unealtă să poată fi folosita în diverse aplicaţii, a fost dezvoltată o librărie numită libcurl care poate fi inglobată în diverse aplicaţii şi care oferă aceeaşi funcţionlitate ca şi utilitarul în sine. Limbajul PHP deţine şi el o astfel de librărie, scrisă de către Daniel Stenberg, şi care oferă conectarea cu diverse servere folosind următoarele protocoale: http, https, ftp, gopher, telnet, dict, file şi ldap. Deasemenea libcurl suportă certificate de securitate, POST si PUT prin HTTP, încărcări de fişiere prin FTP sau din formularele HTTP, proxy-uri, cookie-uri sau autentificări folosind nume de utilizator şi parolă.

Un exemplu de folosire simplă este următorul:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://www.google.com');
curl_exec($ch);
curl_close($ch);

PHP are implementate o serie de funcţii pentru lucru cu această librărie. Un algoritm general de funcţionare este descris şi în exemplul de mai sus care nu face altceva decât să returneze acceseze pagina google.com. Astfel, la început am creat o nouă sesiune de cURL folosind funcţia curl_init, şi am stocat-o în variabila $ch. Acesteia i se pot adăuga diverse opţiuni care să personalizeze sesiunea respectivă. În final sesiunea se execută, adică cererea către google.com este făcută, iar la final se eliberează resursa creată.

Într-o sesiune de cURL se pot adăuga mai mulţi parametrii care vor determina comportamentul acesteia. Iată câteva dintre cele mai uzuale opţiuni, care vor fi setate folosind funcţia curl_setopt:

• CURLOPT_URL – reprezintă URL-ul pentru care se crează sesiunea şi cu care se va încerca trimiterea/primirea de date
• CURLOPT_USERAGENT – va seta semnătura pe care o va lăsa accesarea la server
• CURLOPT_HTTPHEADER – reprezintă un vector în care se pot defini header-ele de HTTP care se vor folosi la accesarea serverului
• CURLOPT_REFERER – reprezintă URL-ul de pe care vine cererea curentă, cel care a referit acest nou URL
• CURLOPT_ENCODING – reprezintă tipul de arhivare aplicat transferului curent, de regula gzip
• CURLOPT_RETURNTRANSFER – va face ca funcţia curl_exec să nu afişeze aceste rezultatul sesiunii ci sa-l returneze într-o variabilă.
• CURLOPT_HTTPGET – indică faptul că se modalitatea de transmitere a datelor este HTTP GET; aceasta este modalitatea implicită de transmitere a dateleor, astfel că setarea ei este necesară doar dacă într-o aceeaşi sesiune a fost făcută anterior o conexiune diferită
• CURLOPT_POST – va determina trimiterea unei cereri de tip HTTP POST, cea implicită fiind GET
• CURLOPT_POSTFIELDS – poate fi folosit în cazul unei cereri de tip POST şi aici se vor specifica variabilele pentru POST
• CURLOPT_TIMEOUT – reprezintă numărul de secunde pentru care se va reîncerca o conexiune în caz ca cea iniţială a eşuat
• CURLOPT_PORT – este portul pe care se va face cererea şi este implicit 80 pentru o conexiune folosind HTTP şi 21 folosind FTP
• CURLOPT_PROXY – este numele serverului de proxy prin care se va face conexiunea
• CURLOPT_PROXYUSERPWD – numele de utilizator şi parola pentru acces la serverul proxy, dacă sunte necesare
• CURLOPT_FOLLOWLOCATION – va transmite librăriei de cURL să urmeze un redirect în cazul în care serverul o va dicta
• CURLOPT_SSL_VERIFYPEER – verifică valabilitatea certificatului de securitate în cazul unei conexiui folosind SSL
• CURLOPT_SSL_VERIFYHOST – indică faptul că în cazul unei conexiuni securizate, certificatul SSL trebuie să fie emis pentru host-ul care a fost contactat de catre cURL
• CURLOPT_UPLOAD – va fi folosit în cazul unui upload
• CURLOPT_FRESH_CONNECT – indică faptul că se va folosi o conexiune nouă în loc de cea existentă în cache
• CURLOPT_HTTP_VERSION – indică versiunea protocolului HTTP care va fi folosită pentru comunicare
• CURLOPT_MAXREDIRS – numărul maxim de redirectări pe care conexiunea le va urma
• CURLOPT_COOKIE – reprezintă cookie-urile care vor exista în momentul cererii către server
• CURLOPT_COOKIEFILE – reprezintă un fişier în care sunt stocate unul sau mai multe cookie-uri care vor insoţi cererea către server
• CURLOPT_COOKIEJAR – reprezintă un fişier în care se vor stoca cookie-urile provenite de la server

Pe lângă aceşti parametrii care pot fi aplicaţi asupra cererii, există şi diverşi parametri care pot furniza informaţii referitoare la răspunsul venit din partea serverului în urma executării cererii de către cURL. Acestea pot fi acceste folosind funcţia curl_getinfo:

• CURLINFO_HTTP_CODE – va furniza codul de răspuns al cererii
• CURLINFO_TOTAL_TIME – timpul total afecatat sesiunii
• CURLINFO_EFFECTIVE_URL – reprezintă ultimul URL care a fost folosit in sesiunea cURL
• CURLINFO_REDIRECT_TIME – timpul total afectat redirectărilor dictate de server
• CURLINFO_SIZE_UPLOAD – numărul de bytes încărcaţi către server
• CURLINFO_SIZE_DOWNLOAD – numărul de bytes primitţi de la server
• CURLINFO_CONTENT_TYPE – tipul de conţinut primit de la server; este util pentru a distinge între un conţinut HTML şi unul care în mod normal ar fi oferit către download

O atenţie sporită trebuie avută la aceste opţiuni referitor la versiunea de PHP pe care o folosiţi, întru-cât ele au fost introduse de-a lungul timpului sau chiar recent şi nu pot exista în versiunea pe care o utilizaţi.

Trimitere de POST cu cURL

Vom încerca în cele ce urmeză să oferim câteva exemple de folosire a cURL, pentru a exemplifica puterea de lucru care o poate oferi acesta.

Să presupunem, aşadar, existenţa unui formular de autentificare pe un site care va cere utilizatorului adresa de email cu care acesta s-a înregistrat şi parola lui, după cum urmează:

    Email: 

    Password:     

Putem crea astfel un script care să simuleze o autentificare întocmai precum un utilizator s-ar fi autentificat direct pe site.

$ch = curl_init("http://www.example.ro/post.php");
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, "email=blog@inphpwetrust.com&pass=foobar");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION , true);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3");
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
curl_close($ch);

Am început prin a crea o nouă sesiune care se va conecta la adresa http://www.example.ro/post.php şi pentru care am stabilit că va fi de tip HTTP POST, prin optiunea CURLOPT_POST, am mai setat o pseudo semnătură a “browser-ului” care se va conecta la server prin opţiunea CURLOPT_USERAGENT ca fiind Mozilla Firefox versiunea 3.0.3, varianta pentru Microsoft Windows XP, am indicat ca orice redirecţionare indicată de către server să fie urmărită şi de cURL prin optiunea CURLOPT_FOLLOWLOCATION, CURLOPT_HEADER indică faptul că nici un header primit ca răspuns nu va fi stocat, iar CURLOPT_RETURNTRANSFER va detemina ca doar corpul mesajului să fie preluat, iar în final după execuţia sesiunii de cURL va fi afişat în browser. Opţiunea CURLOPT_POSTFIELDS este cea mai importantă din aceast exemplu şi este cea care va determina autentificarea efectivă, deci într-un final returnarea unui conţinut care ar putea fi văzut doar de o persoană care s-ar autentifica pe un site. Valorile pentru elementele HTML de tip input email şi pass au fost setate aici, ele fiind credenţialele pe care aplicaţia de pe server va efectua autentificarea. Evident acesta este un exemplu simplu şi uşor de “hack-uit”, în ziua de azi multe din site-uri verifică veridicitatea utilizatorului folosindu-se de mai multe elemente sau afişează o imagine cu nişte caractere de recunoscut care pot fi mai greu sau chiar imposibil de nimerit folosind un script PHP.

Upload prin FTP folosind cURL

Deşi sunt şi alte metode de a încărca un fişier pe un server folosind protocolul FTP, sau simplu pentru a citi conţinutul unui director FTP, chiar şi limbajul PHP deţine niste funcţii de lucru cu FTP, cURL poate fi de ajutor atunci când acestea nu sunt dispobilie sau când se doreşte o mai mare flexibilitate în lucrul cu acest protocol. Următorul exemplu va folosi un handler de fişier creat cu funcţia fopen care va fi pasat parametrului CURLOPT_INFILE.

$fp = fopen('image.jpg', 'r');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'ftp://ftp.domain.com/');
curl_setopt($ch, CURLOPT_USERPWD, "ftpuser:ftppass");
curl_setopt($ch, CURLOPT_UPLOAD, true);
curl_setopt($ch, CURLOPT_INFILE, $fp);
curl_setopt($ch, CURLOPT_INFILESIZE, filesize($localfile));
curl_exec ($ch);
curl_close ($ch);
fclose($fp);

Un punct de reper pentru a descoperi un programator bun, indiferent de limbajul de programare pe care îl utilizează, este abilitatea acestuia de a aplica tehnici cunoscute de design al aplicaţiei. Design patterns(sau proiectarea modelelor) sunt un un set de soluţii ce pot fi aplicate la diverse probleme ce se întâlnesc frecvent în cadrul programării orientate pe obiect.

În teorie, aceste modele nu au legătură cu codul scris de un programator. Sunt niște soluţii de eficientizare a problemelor des întâlnite, nişte indicaţii pe care programatorul trebuie să le transpună în limbajul de programare pe care îl foloseşte. Ne vom referi în continuare la aceste modele legat de limbajul PHP, modele care deşi pot fi implementate folosind şi programarea procedurală, ele sunt evidenţiate mai bine cu ajutorul programării orientate pe obiect.

Singleton

Modelul Singleton este probabil cel mai simplu model. El este făcut pentru a permite accesul la o singură resursă care nu va fi niciodată duplicată, dar care trebuie făcută disponibilă în orice moment al execuţiei aplicaţiei. Implementarea unui Singleton trebuie să satisfacă cele două condiţii de acces global şi instanţiere singulară a resursei respective. Are nevoie de un mecanism de acces la class Singleton fără a instanţia un obiect şi un mecanism de a păstra informaţia asupra resursei ce urmează a fi folosită. Astfel acest model poate fi cel mai uşor implementat prin crearea unei clase ce va conţine o metodă care va crea o nouă instanţă a clasei, dacă aceasta nu exista deja, iar dacă există o va returna pe aceasta. Pentru a fi siguri că acea clasă nu va fi instanţiată în alt fel, constructorul este declarat protejat. Exemplul cel mai simplu este acela în care se pune problema existenţei unei singure conexiuni la baza de date:

class database
{
    private static $_singleton;
    private $_connection;

    protected function __construct()
    {
        $this->_connection = mysql_connect(SERVER, USER, PASSWORD);
    }

    public static function getInstance()
    {
        if (is_null(self::$_singleton))
        {
            self::$_singleton = new database();
        }

        return self::$_singleton;
    }
}

$cnx = database::getInstance();

Aşadar constructorul a fost declarat protejat pentru a controla accesul la el şi de a da posibilitatea apelării lui doar din interiorul clasei. Acest lucru este făcut cu ajutorul metodei statice getInstance, care verifică la fiecare apel al ei dacă există definit membrul static $_singleton, caz în care îl va returna, sau va încerca să creeze unul nou. Odată creat, metoda getInstance() nu va mai încerca să creeze unul nou ci-l va retuna pe cel creat tot timpul.

Factory

Modelul Factory se foloseşte în scenariile în care există o clasă generică (fabrica) care are posibilitatea de a crea o instanţă a una sau mai multe clase specializate în rezolvarea unei aceleaşi probleme dar în diferite moduri. Un astfel de exemplu îl reprezintă stocarea datelor de configurare într-o aplicaţie. Datele de configurare, precum credenţialele pentru conectarea la baza de date, sau căile de acces la diverse directoare, pot fi stocate în mai multe feluri: în fişiere XML, in fişiere INI sau chiar în baza de date. Astfel putem crea un mecanism care să returneze un obiect ce va şti să lucreze cu un anume mod de stocare a acestor date de configurare.

class configuration
{
    const STORE_IN_INI = 1;
    const STORE_IN_DB = 2;
    const STORE_IN_XML = 3;

    public static function factory($type = self::STORE_IN_INI)
    {
        switch ($type)
        {
            case self::STORE_IN_INI:
                return new configuration_ini();
            case self::STORE_IN_DB:
                return new configuration_db();
            case self::STORE_IN_XML:
                return new configuration_xml();
            default:
                throw new Exception('Tip de stocare necunoscut');
        }
    }
}

Este evident faptul că toate cele 3 clase specializate de tratare a fișierelor de configurare (ini, xml, db) trebuiesc definite şi implementate, un avantaj fiind definirea lor conform unei clase abstracte. Apelarea “fabricii” se face după cum urmează:

$storage = configuration::factory(configuration::STORE_IN_XML);

Registry

Modelul Registry este un model Singleton mai evoluat, în sensul că permite stocarea mai multor resurse, ca într-un registru. Un exemplu ar fi acela în care, deşi avem conexiunea stabilită către baza de date printr-un Singleton, şi prin această conexiune se fac toate interogările, există posibilitatea ca din aplicaţie să fie nevoie de conexiunea în paralel către o alta bază de date pentru a efectua şi acolo diverse operaţiuni. Cu un simplu Singleton nu s-ar fi putut realiza aşa ceva însă cu un Registry acest lucru este posibil. Un astfel de Registry va trebui să implementeze metode de adăugare, verificare a existenţei şi de returnare a informaţiilor cerute.

class registry
{
    private static $_register;

    public static function add(&$element, $name)
    {
        $name = strtolower($name);
        self::$_register[$name] = $element;
    }

    public static function exists($name)
    {
        $name = strtolower($name);
        if (array_key_exists($name, self::$_register))
        {
            return true;
        }
        return false;
    }

    public static function &get($name)
    {
        $name = strtolower($name);
        if (self::exists($name))
        {
            return self::$_register[$name];
        }
        else
        {
            throw new Exception('Elementeul cerut nu exista in registru.');
        }
    }

}

O folosirea a cestul model este următorul cu precizarea ca în acest exemplu clasa database nu este un Singleton:

$db = new database();
registry::add($db, 'dbCnx');
/*
verificarea conexiunii
*/
if (registry::exists('dbCnx'))
{
    $db = registry::get('dbCnx');
}

Model-View-Controller

Spre deosebire de celelate modele discutate anterior, Model-View-Controller(denumit şi MVC) este un model destul de complex. Scopul lui este de a oferi o metodă de separare dintre logica aplicaţiei (model), modului de afişare (view) şi structura decizională (controller), aplicaţiile MVC fiind astfel usor de modificat atunci când se doreşte modificarea doar a modului de afişare sau a modului în care este tratată o cerere.

Logica unei astfel de aplicaţii este următoare: o cerere este făcută către aplicaţie şi este apelat controller-ul care va decide cum va trata cererea. Controller-ul va chema o clasă din Model, care efectiv va efectua interogări către baza de date, prelucrările necesare ale datelor sau orice alte operaţiuni necesare. Rezultatul, de regulă un set de date, va fi întors către Controller care va transmite aceste date părţii vizuale a aplicaţiei(View) unde deja există o structură de afişare a datelor ce tocmai au fost primite. Avantajul enorm al acestui model este separarea clară între cele 3 compomente şi uşurinţa cu care se pot extinde aplicaţiile dezvoltate pe acest model.

PHP RefCard

Am aflat zilele trecute citind feed-ul de la Zend Developer Zone cum că DZone a lansat mult aşteptatul PHP RefCard. Pentru cei care nu ştiu, acest RefCard reprezintă o broşură frumos formatată şi ordonată cu informaţii utile referitoare la un anume limbaj de programare.

PHP RefCard este realizat de către Jason Glimore, autorul a câtorva cărţi de referinţă cum ar fi Beginning PHP and MySQL: From Novice to Professional, Beginning PHP and Oracle: From Novice to Professional (Expert’s Voice) sau Beginning PHP and PostgreSQL 8: From Novice to Professional.

Recomand acest RefCard tuturor începătorilor ca un mic ghid asupra problemelor comune ce pot apărea referitor la configurare, programarea orientată obiect, stringuri, vectori, expresii regulate sau integrarea cu MySQL, precum şi diverse informaţii utile.