Am avea tabele ia_news, ia_blog_post si ia_wiki care sunt "deasupra" lui ia_textblock, iar ia_textblock ar fi folosit doar pentru versionarea unor bucati de text. Securitatea private/protected/public (care este *foarte* utila si absolut ok) poate fi un simplu enum in ia_wiki. Acel enum trebuie editat folosind un simplu dropdown.

Efortul necesar pentru o astfel de transformare in infoarena2 mi se pare iarasi absolut enorm.

Efortul necesar pentru o astfel de transformare fundamentala in infoarena2 mi se pare iarasi absolut enorm.

h3. Layer de logica

Infoarena2 pretinde ca foloseste o arhitectura MVC, dar MVC este o notiunea foarte larga si vag definita. Nu este interesanta o discutie detaliata asupra ce inseamna MVC, asa ca voi discuta doar ce se foloseste efectiv in site-ul infoarena2.

Infoarena2 pretinde ca foloseste o arhitectura MVC, dar MVC este o notiunea prea larga si vag definita. Nu este interesanta o discutie detaliata asupra ce inseamna MVC, asa ca voi discuta doar ce se foloseste efectiv in site-ul infoarena2.

Url-urile sunt parsate in index.php si in functie de o logic complicata si nu foarte interesanta fiecare request http este pasat la un "controller". Un controller este in principiu o functie php din www/controllers. Acel controller face ceva cu requestul, de obicei niste query-uri in baza da date, si apoi constrieste un hash de "date pentru afisat" care il trimite la un view.

Url-urile sunt parsate in index.php si in functie de o logica complicata si nu foarte interesanta fiecare request http este pasat la un "controller". Un controller este o functie php din www/controllers. Acel controller face ceva cu requestul, de obicei niste query-uri in baza da date, si apoi constrieste un hash de "date pentru afisat" care il trimite la un view.

View-urile nu sunt functii, sunt fisiere .php din www/views. Lansarea unui view este o operatie sinucigasa, se executa fisierul de view folosind hash-ul de date si se trimite direct pe "teava". In acel view se poate folosi textile, care poate executa macro-uri care(de obicei) se duc pana in baza. Asta inseamna ca poti sa te duci in baza dupa executia controller-ului, dar nu mi se pare nimic rau in asta. Macro-urile sunt efectiv niste mini-controllere.

View-urile nu sunt functii, sunt fisiere .php din www/views. Executia unui view este o operatie sinucigasa, care se trimite direct pe teava. Nu se poate executa cod dupa un view. Fisierul de view executa folosind continutul hash-ului de data ca variabile globale. In acel view se poate folosi textile, care poate executa macro-uri care(de obicei) se duc iar pana in baza. Asta inseamna ca poti sa te duci in baza dupa executia controller-ului, dar nu mi se pare nimic rau in asta. Macro-urile sunt efectiv niste mini-controllere.

Problema este ca noi din controllere ne ducem direct in baza si logica fragila de genul securitate este imprastiata si combinata cu cod jegos de parsat/validat request-ul (in controller) sau construit query-uri sql (in functiile de db). Aceasta problema are o rezolvare destul de clara si larg acceptata in industrie (dar nu de pentru noi in vara 2006).

Problema este ca noi din controllere ne ducem direct in baza si logica fragila de genul securitate este imprastiata intre functiile de UI si de DB. Este riscant (error-prone) sa combini logica site-ului cu parsarea requestului sau construirea query-ului. Aceasta problema are o rezolvare destul de clara si larg acceptata in industrie, de care eu personal nu stiam in vara lui 2006.

Intre codul de controller (UI) si codul de baza de data (DB) se mai pune niste cod de "business logic" (BL). Tot ce inseamna parsarea request-ului se face in UI si tot ce inseamna contruirea de SQL se face in DB. BL contine de fapt tot codul cu adevarat interesant pentru functionarea corecta a site-ul. Codul de DB nu trebuie sa aiba grija decat sa construiasca query-uri (si sa evite sql injection) iar codul de UI se ocupa de a vedea ce butoane a apasat utilizatorul.

Unul dintre avantajele majore este ca se pot scrie usor teste pentru BL. Daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic in baza (doar experienta utilizatorului). A se vedea punctul urmator.

Unul dintre avantajele majore este ca se pot scrie usor teste pentru BL. Daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic in baza (doar experienta utilizatorului). Apeland functii doar de BL este mult mai usor sa verifici corectitudinea unui macro sau controller.

h3. Testele pe baza de curl

PHP este un limbaj foarte fragil, unde este foarte usor sa faci greseli grosolane. Asta este o problema generica a limbajelor dinamice de genul php, python, ruby, javascript fata de limbajele de genul C, C++, C# si java. Asta face ca in limbajele dinamice sa fie mult mai important sa testezi codul.

PHP este un limbaj foarte fragil, unde este foarte usor sa faci greseli grosolane. Asta este o problema generica a limbajelor dinamice de genul php, python, ruby, javascript fata de limbajele de genul C, C++, C# si java. In limbajele dinamice sa fie mult mai important sa testezi codul. Multe lucruri prinse de un compilator de C++ scapa pana in browser folosind PHP.

Teste curente sunt facute pe baza de 'curl':http://www.php.net/curl, curl fiind o librarie de access HTTP. Testele construiesc un request complet http pe care il trimit pe fir, asteapta ca apache sa raspunda, iar apoi verifica niste chestii din request. Contruirea requestului se face folosind 'array':http://www.php.net/manual/en/function.array.php, si verificarile se face cu functii de genul preg_match si strstr. Ambele faze sunt greu de facut, dar avantajul acestui sistem ca testeaza tot codul si este foarte "realist".

Teste curente sunt facute pe baza de 'curl':http://www.php.net/curl, o librarie de access HTTP. Testele construiesc un request complet http pe care il trimit pe fir, asteapta ca apache sa raspunda, si apoi verifica niste chestii din request. Contruirea requestului se face folosind 'array':http://www.php.net/manual/en/function.array.php, si verificarile se face cu functii de genul preg_match si strstr. Ambele faze sunt greu de facut, dar avantajul acestui sistem ca testeaza tot codul si este foarte "realist".

Pentru a usura testarea am facut controllerele noastre de editare sa accepte un parametru de form absent drept "nu vreau sa editez acest parametru". Asta este foarte util in teste dar e un comportament artifical care a "nascut" niste bug-uri foarte urate. In retrospectiva a fost o idee proasta, care a introdus o cuplare oribila intre controllere si codul de test. Ambele sunt acum foarte greu de modificat.

Infoarena2 suporta mai multe forme de caching:

# Cache de textile parsat, inainte de executia macro-urilor. Majoritatea request-urilor nu executa codul de textile.
# Cache de imagini redimensionate. Cand se cere o imagine redimensionata ea este salvata pe disc si se evita operatiile de grafic pentru avatari etc.
# Cache de obiecte din baza de date, folosind memcached sau eaccelerator. Acest cache tine obiecte de genul useri, task-uri si runde.

* Cache de textile parsat, inainte de executia macro-urilor. Majoritatea request-urilor nu executa codul de textile.
* Cache de imagini redimensionate. Cand se cere o imagine redimensionata ea este salvata pe disc si se evita operatiile de grafic pentru avatari etc.
* Cache de obiecte din baza de date, folosind memcached sau eaccelerator. Acest cache tine obiecte de genul useri, task-uri si runde.

Acest ultim mod de caching are inclusiv suport de write-through (cand se salveaza un obiect se sterge cache-ul) care este foarte complex de implementat. Codul de cache este bagat prin foarte multe functii db_ si nu este deloc usor de inteles. Se combinat cod de DB, BL si caching in aceleasi functii.

Exemplu de demo-uri care ar merita facute:

* *SqlAlchemy*:'http://www.sqlalchemy.org': De facut o schema sql alchemy pentru tabelele de scoruri. Cat de usor se fac query-uri de statistici si cat de rapide sunt?
* *Selenium*:'http://www.openqa.org/selenium/': Cineva sa faca niste teste folosind Selenium peste infoarena2. Cum anume pot fi stocate in svn si rulate de oricine?
* *Form-uri*: Nu avem o solutie definitiva pentru facut si validat form-uri. Cineva sa ia o asemenea librarie si sa faca CRUD de task-uri, si sa demonstreze ca e sensibil mai usor decat manual.
* *Tabele*: Demo de tabel de scoruri prin AJAX. Cristi: this means you.
* *BL prin HTTP*: Se poate face un BL accesibil direct prin http, fara a scrie controllere pentru fiecare functie? Poate evaluatorul sa acceseze functii de BL de pe live, fara access TCP la baza de date?
* *Wiki in subversion*: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo de manipulare cu teste de viteza.

* 'SqlAlchemy':http://www.sqlalchemy.org: De facut o schema sql alchemy pentru tabelele de scoruri. Cat de usor se fac query-uri de statistici si cat de rapide sunt?
* 'Selenium':http://www.openqa.org/selenium/: Cineva sa faca niste teste folosind Selenium peste infoarena2. Cum anume pot fi stocate in svn si rulate de oricine?
* Form-uri: Nu avem o solutie definitiva pentru facut si validat form-uri. Cineva sa ia o asemenea librarie si sa faca CRUD de task-uri, si sa demonstreze ca e sensibil mai usor decat manual.
* Tabele: Demo de tabel de scoruri prin AJAX. Cristi: this means you.
* BL prin HTTP: Se poate face un BL accesibil direct prin http, fara a scrie controllere pentru fiecare functie? Poate evaluatorul sa acceseze functii de BL de pe live, fara access TCP la baza de date?
* Wiki in subversion: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo de manipulare cu teste de viteza.

* Cat de bine se poate integra SMF in cod python?
* Exista implementare textile in python. Trebuie modificata incat sa dea aceleasi rezultate cu textile din php. Se poate testa foarte usor, trebuie ca toata textila din infoarena2 sa se parseze identic.
h3. Arest la domiciliu

# Facem demo-uri si ne decidem ce tehnologii folosim.
# Facem un nou branch svn, cu structura de directoare etc.
# Facem schema bazei de date, cat sa acomodeze infoarena2.
# Chemam lumea la santier

* Facem demo-uri si ne decidem ce tehnologii folosim.
* Facem un nou branch svn, cu structura de directoare etc.
* Facem schema bazei de date, cat sa acomodeze infoarena2.
* Chemam lumea la santier

Facem un mare santier in Bucuresti la Leonard si Mircea acasa, unde putem chema utilizatori infoarena existenti deja sa ne ajute (eventual cu macro-uri, form-uri etc). Pentru asta avem nevoie de o structura de baza functionala si pentru asta nu ajuta numerele. Asta inseamna ca intai o sa ne adunam developerii infoarena2 pentru un fel de bootstrapping.