Calculatoare și tehnologia informației [619416]

UNIVERSITATEA TEHNICĂ „Gheorghe Asachi” din IAȘI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DOMENIUL: Calculatoare și tehnologia informației
SPECIALIZAREA:Tehnologia informației
Gestionarea conținutului
unui site folosind limbajul de
programare Python
LUCRARE DE DIPLOMĂ
Coordonator șt iințific
ș.l dr.ing. Cristian Aflori
Student: [anonimizat], 2016

DECLARAȚIE DE ASUMARE A AUTENTICITĂȚII
LUCRĂRII DE LICENȚĂ
Subsemnatul(a) CRETU PAUL ALEXANDRU ,
legitimat(ă) cu CI seria NT nr. 782586, CNP [anonimizat]
autorul lucrării GESTIONAREA CONȚINUTULUI UNUI SITE WEB FOLOSIND
LIMBAJUL DE PROGRAMARE PYTHON
elaborată în vederea susținerii examenului de finalizare a studiilor de licență
organizat de către Facultatea de Automatică și Calculatoare din cadrul Universității
Tehnice „Gheorghe Asachi” din Iași, sesiunea VARĂ a anului universitar
2015-2016, luând în considerare conținutul Art. 34 din Codul de etică universitară al
Universității Tehnice „Gheorghe Asachi” din Iași (Manualul Procedurilor, UTI.POM.02 –
Funcționarea Comisiei de etică universitară), declar pe proprie răspundere, că această
lucrare este rezultatul propriei activități intelectuale, nu conține porțiuni plagiate, iar
sursele bibliografice au fost folosite cu respectarea legislației române (legea 8/1996) și a
convențiilor internaționale privind drepturile de autor.
Data Semnătura
30.06.2016

Cuprins
Capitolul 1. Introducere …………………………………………………………………………………………………… 1
1.1. Tema propusă ………………………………………………………………………………………………………. 1
1.2. Motivarea temei alese și utilitate …………………………………………………………………………….. 1
Capitolul 2. Fundamente teoretice …………………………………………………………………………………….. 2
2.1. Soluții alternative …………………………………………………………………………………………………. 2
2.2. Concepte……………………………………………………………………………………………………………… 3
2.2.1. Servicii REST ……………………………………………………………………………………………….. 3
2.2.1.1. Ce este un serviciu web ? …………………………………………………………………………. 3
2.2.1.2. Ce este REST? ……………………………………………………………………………………….. 3
2.2.1.3. În REST totul este o resursă …………………………………………………………………….. 4
2.2.1.4. URI (Uniform Resource Identifier) …………………………………………………………… 4
2.2.1.5. Interfața uniformă …………………………………………………………………………………… 4
2.2.1.6. Reprezentări …………………………………………………………………………………………… 4
2.2.2. Autentificarea utilizatorilor …………………………………………………………………………….. 5
2.2.3. Cookie…………………………………………………………………………………………………………. 6
2.2.4. Sistem de administrare a conținutului (CMS) ……………………………………………………. 6
2.2.5. MongoDb……………………………………………………………………………………………………… 8
2.2.6. Flask……………………………………………………………………………………………………………. 9
2.2.7. Jinja…………………………………………………………………………………………………………….. 9
2.2.8. Blueprints…………………………………………………………………………………………………….. 9
2.2.9. JSON…………………………………………………………………………………………………………. 10
2.2.10. De ce este serializarea benefică? ………………………………………………………………….. 10
2.2.11. Limitări…………………………………………………………………………………………………….. 10
Capitolul 3. Proiectarea Aplicației …………………………………………………………………………………… 11
3.1. Arhitectura aplicației …………………………………………………………………………………………… 12
3.2. Nivelurile aplicației …………………………………………………………………………………………….. 13
3.2.1. Nivelul de prezentare ……………………………………………………………………………………. 13
3.2.2. Nivelul de business logic ………………………………………………………………………………. 14
3.2.3. Nivelul de bază de date ………………………………………………………………………………… 14
3.3. Schema bloc a aplicației ………………………………………………………………………………………. 14
3.4. Modulele aplicației ……………………………………………………………………………………………… 15
3.4.1. Modulul de autentificare ………………………………………………………………………………. 15
3.4.2. Modulul de controlere ………………………………………………………………………………….. 16
3.4.3. Modulul de servicii ………………………………………………………………………………………. 17
3.4.4. Modulul de funcționalitate …………………………………………………………………………… 17
3.5. Tehnologia aleasă pentru implementare …………………………………………………………………. 18
Capitolul 4. Implementarea aplicației ………………………………………………………………………………. 19
4.1. Nivelul de bază de date ……………………………………………………………………………………….. 19
4.2. Nivelul de interfață cu baza de date ………………………………………………………………………. 19
4.3. Nivelul de logică ………………………………………………………………………………………………… 19
4.3.1. Modulul de autentificare ………………………………………………………………………………. 20
4.3.2. Modulul controler ………………………………………………………………………………………… 21
4.3.3. Modulul servicii ………………………………………………………………………………………….. 22
4.3.4. Modulul ce conține clasele ……………………………………………………………………………. 22

4.4. Nivelul prezentare ………………………………………………………………………………………………. 23
4.5. Probleme întâmpinate și soluții alternative în dezvoltarea aplicației ………………………….. 30
Capitolul 5. Testare și rezultate ……………………………………………………………………………………….. 31
5.1. Testele unitare ……………………………………………………………………………………………………. 31
5.2. Testele automate …………………………………………………………………………………………………. 32
5.3. Testarea funcțională și a interfeței …………………………………………………………………………. 33
Capitolul 6. Concluzii și directive de dezvoltare ……………………………………………………………….. 34
Bibliografie………………………………………………………………………………………………………………….. 35
Anexe………………………………………………………………………………………………………………………….. 36

Gestionarea conținutului unui site folosind limbajul de
programare Python
Crețu Paul Alexandru
Rezumat
Proiectul își propune dezvoltarea unei aplicații de tip web bazată pe utilizarea serviciilor
RESTful și a limbajului de programare Python în vederea realizării unui site, în care utilizatorul
își poate gestiona conținutul în modul dorit. Există două tipuri de utilizatori:
•Vizitatorii – cei care pot vizualiza conținutul site-ului, dar nu au drept de
modificare asupra acestuia.
•Administratorii – au rolul unui vizitator, dar în plus aceștia pot modifica
conținutul aplicației și felul în care să apară elementele în pagină.
Funcționalitățile care vor putea fi accesate din cadrul unui administrator vor fi:
Crearea, editarea și ștergerea unei pagini – în aceste secțiuni utilizatorul va putea seta
titlul paginii existente, adresa paginii la care aceasta să poată fi accesată, conținutul paginii dar și
unele elemente ce țin de promovarea paginii în vederea SEO (search engine optimization),
tehnologie care se ocupă cu partea de optimizare a unui site în vederea promovării lui.
Gestionarea și adăugarea utilizatorilor – aceste funcționalități permit administratorului
să adauge noi utilizatori și administratori în cadrul aplicației, dar totodată se poate modifica și
starea unui utilizator (acceptat sau blocat).
Editarea meniului aplicației – în această secțiune administratorul are acces la meniul
aplicației și poate adăuga sau șterge pagini din cadrul acestuia.
Adăugare de fișiere media – administratorul poate să adauge noi fișiere de tip imagine, în
vederea folosirii acestora cu scopul de a crește dinamismul conținutului paginii.
Editare sau adăugare de template-uri (șabloane) – o funcționalitate extrem de importantă
pentru utilizatorii care nu au cunoștințe necesare în vederea programării. Aceștia pot șă-și
definească fiecare șablon și să gestioneze apariția conținutului unei pagini în locul dorit.
Implementarea abordată pentru dezvoltarea interfeței presupune utilizarea limbajului
HTML, CSS și Javascript dar și a librăriei Bootstrap, care oferă aplicației un design cu
posibilitatea adaptării în funcție de dispozitivul de pe care este accesată.
Din punct de vedere al stocării datelor am ales să folosesc o bază de date nerelațională, ce
face parte din categoria bazelor de date NoSql orientată document. Mediul de dezvoltare folosit a
fost NetBeans, iar modelul arhitectural ce stă la baza implementării aplicației este unul organizat
pe mai multe nivele. Acest lucru oferă o mai bună separare între interfața cu utilizatorul, nivelul
de logică și nivelul de stocare al informațiilor, astfel rezultând o aplicație unde aspectul vizual
poate fi modificat cu ușurință.

Capitolul 1. Introducere
Capitolul 1. Introducere
Evoluția tehnologiei cu pași repezi ce a avut loc în ultimii ani a dus la o cerință foarte
mare din punct de vedere software. Toți suntem dornici să dispunem de cât mai mult timp liber,
dar în același timp să fim și în pas cu cerințele prezentului.
În ziua de astăzi informația circulă într-un mod foarte rapid, iar acest lucru a produs
schimbări majore în aproximativ toate domeniile de activitate. Acest lucru ne asigură că
informația este o resursă foarte importantă, care trebuie să fie stocată și furnizată tuturor
oamenilor interesați într-un mod cât mai rapid și autentic. Domeniul principal responsabil de
acest lucru este cel al tehnologiei informației.
1.1. Tema propusă
Tema propusă este găsirea unei soluții software în scopul gestionării conținutului unui
site web. Se dorește implementarea unei aplicații ce folosește servicii RESTful capabilă să
realizeze acest lucru cu ușurință, dedicată în special utilizatorilor care nu au cunoștințe în
domeniul programării.
Arhitecturile bazate pe serviciile Web reprezintă tehnologie de ultimă generație,
tehnologie ce oferă baza de dezvoltare pentru aplicațiile de mari dimensiuni de tip web.
1.2. Motivarea temei alese și utilitate
Inițial am fost foarte nehotărât în alegerea temei deoarece oscilam între realizarea unei
aplicații de tip mobil și realizarea unei aplicații de tip web. În cele din urmă am optat pentru
aplicația de tip web.
Deoarece trăim în secolul al XX și tehnologia evoluează cu pași repezi, am ales această
temă pentru a facilita utilizatorii care vor să-și implementeze propriul lor site web, oferindu-le
acestora posibilitatea de a-i gestiona conținutul în maniera dorită și de a avea control asupra
aplicației.
Prin intermediul unor librării auxiliare am reușit să realizez și o parte din aplicația de tip
mobil, mai exact interfața. Design-ul aplicației proiectată de mine este unul responsive, ceea ce
înseamnă că se poate adapta în funcție de mărimea ecranului dispozitivului de pe care aceasta
este accesată. Interfața aplicației este una clară, chiar și cea în variant a de mobil. O altă
caracteristică importantă asupra interfeței este că nu plictisește utilizatorul, aceasta fiind concisă.
1

Crețu Paul Alexandru
Capitolul 2. Fundamente teoretice
În acest capitol vor fi descrise tehnologiile folosite în realizarea aplicației, dar și unele
elemente ce aparțin framework-ului Flask prin intermediul cărora s-au realizat anumite verificări
și funcționalități, în lipsa cărora aplicația nu putea fi realizată.
2.1. Soluții alternative
Una dintre primele și cele mai importante decizii pe care un utilizator trebuie să o facă
atunci când dorește crearea unui un site web este alegerea unei platforme potrivite pentru
aplicația dorită. Câteva opțiuni includ: HTML, PHP, asp.net sau un Content Management System
(CMS), cum ar fi WordPress, Joomla sau Drupal.
Construirea unui site web pe un sistem de gestionare al conținutului poate fi de multe ori
mai rentabilă și vă permite să faceți actualizări pe site-ul dumneavoastră rapid și ușor – fără a fi
nevoie de a apela la un programator web.
Tema aleasă de mine este dezvoltată deja de către alte mari companii ce produc produse
software. Una din principalele platforme asupra căreia aș dori să ma opresc și să fac un mic
studiu de caz este WordPress, CMS open-source bazat pe limbajul de programare PHP și pe o
bază de date de tip MySql.
Fiind o aplicație dezvoltată de o echipă de profesioniști, bineînțeles că această platformă
a avut parte de un mare succes și oferă utilizatorilor o serie de avantaje:
•Ușor de operat – puteți efectua modificări pe site-ul dumneavoastră fără a fi
nevoie să cunoașteți codificarea HTML. Adăugarea de pagini, articole de blog,
produse, imagini și editarea conținutului curent este ușor de realizat în WordPress.
Dacă utilizatorul nu este familiarizat cu această platformă, ar fi indicat ca acesta
să urmeze câteva tutoriale spre îndrumarea utilizării. Acest lucru va salva o parte
mare financiară, beneficiarul nu este nevoit să plătească un dezvoltator de fiecare
dată când se dorește modificarea conținutului.
•Ieftin de implementat – WordPress oferă o mare varietate de teme care pot fi
folosite pentru a construi site-ul web. Atunci când se alege o temă, se reduce în
mod semnificativ cantitatea de timp necesară pentru a construi un site web.
•WordPress este o platformă populară . Chiar și Matt Cutts, care vorbește în
numele Google menționează WordPress într-o lumină bună. De-a lungul anilor, au
fost multe platforme web dezvoltate care au încetat să funcționeze, platforme care
au lăsat clienții cu o aplicație ce are o capacitate limitată de a face modificări.
Wordpress-ul însă, cunoaște o foarte mare popularitate și o mare cerere la nivelul
pieții.
Ca orice realizare, această platformă prezintă și unele dezavantaje, fapt pentru care o
mare parte dintre utilizatori se declară nemulțumiți:
•WordPress actualizează software-ul lor în mod frecvent . Actualizări ale software-
ului sunt necesare pentru a menține platforma WordPress la curent cu browserele
cotidiene și a altor dispozitive mobile, dar și pentru a preveni atacurile malware și
viruși. Cu toate acestea, uneori, anumite plugin-uri nu sunt la fel de rapide pentru
a se adapta la actualizările WordPress, iar acest lucru face ca o tema funcțională
înainte să prezinte unele bug-uri fatale. Dezvoltatorii vin cu opțiunea salvării unei
versiuni anterioare la un interval periodic de timp.
•Conținutul nu arată întotdeauna corect. Atunci când se fac actualizări asupra
aplicației dumneavoastră, nu totul decurge cu succes din punct de vedere al
2

Capitolul 2. Fundamente teoretice
regulilor ce definesc design-ul. Acest lucru îi poate lăsa frustrați pe utilizatorii
care nu cunosc HTML și CSS și doresc remedierea cât mai repede a acestei
probleme.
•Personalizarea unei teme poate fi costisitoare . În cazul în care site-ul unui
utilizator a fost construit pe o anumită temă și se dorește efectuarea unei
schimbări majore, aceasta poate fi consumatoare de timp și necesită prezența unui
programator pentru a face modificări în structura temei. Fiecare temă este
programată în mod diferit și, prin urmare, programatorul trebuie mai întâi să se
familiarizeze cu modul în care tema a fost implementată înainte de efectuarea
modificărilor. [1]
2.2. Concepte
2.2.1. Servicii REST
2.2.1.1. Ce este un serviciu web ?
Legătura dintre aplicații este dată de protocoale și standarde, globalizând activitatea
găzduită de Internet. Serviciile de informare au devenit valabile utilizatorilor prin intermediul
serviciilor web, servicii ce lucrează independent de hardware, găsindu-se în general doar pe
Internet. Printre cele mai cunoscute servicii web ar putea fi amintit serviciul web de informare
(aflarea condițiilor metereologice dintr-o zonă specifică) sau serviciul web de prelucrare a
informației (de la operații aritmetice simple până la autentificarea pe un anumit site).
Un serviciu web reprezintă orice serviciu disponibil pe Internet, care folosește un sistem
de mesaje standardizat XML și care nu este legat de nici un sistem de operare sau de un
calculator.
2.2.1.2. Ce este REST?
REST (Representational State Transfer) este o structură arhitecturală menită să inspire
serviciul web. Datorită dificultății utilizării unor servicii ca RPC (Remote Procedure Call –
Apelul Procedurilor la Distanță) și cele care în general folosesc SOAP (Service Oriented
Architecture Protocol) s-a ajuns la concluzia că simplitatea WEB ar putea simplifica și ameliora
serviciile web de tip REST. Practic, REST nu este un standard, dar aplică arhitectura web-ului
asupra serviciilor web, folosindu-se de standarde:
•HTTP ( Hypertext Transfer Protocol)
•URI ( Uniform Resource Identifier)
•XML/HTML/GIF/JPEG
Practic REST presupunea construirea unui serviciu web folosind HTTP, XML și URI așa
cum a fost construit și web-ul.
Pentru a putea înțelege mai bine modul în care se realizează un serviciu de tip REST mai
întâi va fi prezentată o abordare simplă, pe înțelesul tuturor iar apoi o descriere tehnică a
acestuia.
Pentru cei inițiați în software, două concepte ce pot aduce un plus de claritate serviciului
REST se disting: design și arhitectură. Arhitectura REST este dată de interacțiunile de tip web
între clienți și servere. Comportamentul intern al software-ului clientului și serverului se poate
numi design
REST nu reprezintă design, vizează arhitectura, impunând o suită de reguli, însă datorită
faptului că nu este atât de clar conturat, REST păstrează doar statutul de stil arhitectural. În acest
fel este construit și web-ul, ca într-o arhitectură fără constrângeri, adică nu impune o direcție de
3

Crețu Paul Alexandru
transmitere, un mesaj anume sau o semnificație aparte între două părți comunicante
Tipic arhitecturii REST este faptul că:
•datele asupra cărora clientul ii spune serverului să opereze se afla în URI
•operația pe care serverul o face asupra datelor este descrisă direct de metoda
HTTP
2.2.1.3. În REST totul este o resursă
Într-o arhitectură de tip REST orice poate fi stocat în calculator și reprezentat ca un flux
de octeți este o resursă. Posibile resurse pot fi :
•Versiunea unui soft
•O poză de la mare
•Numărul de vizitatori de pe un site
•Bug-urile dintr-o bază de date
2.2.1.4. URI (Uniform Resource Identifier)
URI cunoaște numele și adresa fiecărei resurse căreia i se adresează. Acest identificator
alfanumeric univoc și unic pe Internet este asociat cu URL (Uniform Resource Locator), care
atribuie o locație. De fapt este forma incipientă a lui URI. Dacă o resursă nu are locație, atunci ea
nu există pe web. Cu toate acestea, o resursă poate deține mai multe URI, în funcție de domeniile
în care este introdusă: de exemplu, un articol se poate găsi în mai multe categorii, dacă este
clasificat în funcție de acest gen. Un URI va fi întotdeauna descriptiv. Ca să înțelegem mai bine,
vom privi următoarele exemple :
• http://www.example.com/software/releases/1.0.3.tar.gz
• http://www.example.com/software/releases/latest.tar.gz
• http://www.example.com/weblog/2006/10/24/0
2.2.1.5. Interfața uniformă
Interfața uniformă presupune o uniformizare sau o simplificare a operațiilor ce pot fi
făcute asupra unor resurse. Așadar, dacă intenționăm să reprezentăm o resursă utilizăm HTTP
GET, dacă creăm o nouă resursă HTTP PUT sau dacă folosim un URI existent HTTP POST.
Pentru modificarea resursei apelăm la HTTP PUT iar pentru ștergerea ei HTTP DELETE.
Simplitatea arhitecturii REST poate fi rezumată la aceste operații. Lipsa constrângerilor
vizează mai degrabă adăugarea de informații noi, folosindu-se de procedee standard. Practic,
arhitectura colectează și lucrează cu tot mai multe informații, în loc de a-și dezvolta apeluri
speciale sau alte funcții.
Un exemplu: în loc de o cerere de tipul "aprindeBec" la un obiect-server, putem folosi
PUT "ture" la obiectul http://exemplu.com/Bec/aprinde furnizat de către server. Obiectul
http://exemplu.com/Bec/aprinde poate răspunde, de asemenea, la o cerere de tip GET care va
returna adevărat sau fals. POST este o cerere de tipul "adăugați informații" care nu are sens
pentru bec, de fapt nu are sens nici să ștergi un bec. Deci, aceste solicitări ar eșua cu un răspuns
care indică acest fapt.
2.2.1.6. Reprezentări
Reprezentarea este cea care leagă datele între ele, dând un sens conținuturilor. Serviciile
web de tip REST lucrează cu reprezentări, reflectând astfel viziunea creatorului asupra
organismului sistemic al datelor. Diagrama de mai jos descrie modul în care se realizează un
serviciu web de tip REST :
4

Capitolul 2. Fundamente teoretice

Figura 2.1 ar putea fi înțeleasă astfel: clientul introduce o resursă web, care este
transformată într-o alta(Boeing747.pdf), realizând un schimb de stări între client și arhitectura
REST.
Serviciul web duce la globalizarea informației, eliminând necesitatea de a reitera o
anumită aplicație. Serviciile web au o arhitectura modulara, devenind astfel scalabile.
În concluzie, serviciile web au devenit o necesitate în ziua de astăzi deoarece simplifică
cu mult Internetul prin asigurarea unei arhitecturi distribuite. Cu toate acestea, cele două
arhitecturi (RPC și SOAP) sunt necesare: dacă una aduce o complexitate mesajului, cealaltă
aduce o anumită valorificarea arhitecturii Internetului.
De exemplu, în ciuda numărului mare de protocoale utilizat de arhitectura SOAP,
contactul clientului cu serviciul web este ușurat, ceea ce face să fie preferat și de Google această
arhitectură.
Prin urmare, chiar dacă arhitectura REST în sine este ușoară, serviciile ei necesită o
înțelegere tehnică de către clienți pentru a putea fi accesate. Toate serviciile de la Yahoo folosesc
REST, inclusiv Flickr.
Indiferent de arhitectură, o bună documentare facilitează contactul cu aceasta și redă
clientului o ușurință în utilizare. [2]
2.2.2. Autentificarea utilizatorilor
Autentificarea este un proces în care creden țialele utilizatorilor autorizați sunt furnizate și
comparate cu cele dintr-un fișier sau dintr-o bază de date de informații cu ajutorul unui sistem de
operare local sau a unui server de autentificare. În cazul în care datele furnizate se potrivesc,
procesul este finalizat, iar utilizatorul ui îi este acordată autorizația de acces. Permisiunile
furnizate definesc atât mediul pe care utilizatorul îl poate accesa, cât și modul în care el poate
interacționa cu acesta. Alte drepturi de acces ar mai putea fi orele de acces și cantitatea de spațiu
de stocare alocată utilizatorului respectiv .
Procesul de acordare a drepturilor unui administrator și procesul de verificare a
permisiunilor contului de utilizator pentru accesul la resursele dorite, ambele poartă denumirea
de autorizație. Privilegiile și preferințele acordate pentru contul autorizat depind de permisiunile
utilizatorului, care sunt fie stocate local sau pe serverul de autentificare. Setările definite pentru
toate aceste variabile de mediu sunt stabilite de către un administrator.
Autentificarea utilizator ilor se realizează de cele mai mule ori prin intermediul unui
calculator. În general, un utilizator se poate autentifica prin introducerea unui identificator și a
unei parole pentru a putea începe să utilizeze un anumit sistem.[3]
5
Figura 2.1: REST – imagine preluata de pe
http://stst.elia.pub.ro/RIC/Teme_RIC_2008_9/AnaOlteanu/proiectFinal.doc

Crețu Paul Alexandru
2.2.3. Cookie
Cookies sunt fișiere mici de date, utilizate ca identificatori unici. Fiecare cookie este unic
pentru browser-ul web. Un cookie conține informații anonime și este trimis de la serverul site-
ului accesat pe computer sau pe telefonul mobil. Acesta va fi stocat pe dispozitiv și serverul va fi
capabil de a prelua sau citi conținutul său. Cookie-urile citite pot fi trimise înapoi la serverele
site-ului web cu date actualizate în timpul navigării aplicației web. Cookie-urile pot fi stabilite de
către site-ul pe care îl vizitați ( " first party cookies") sau pot fi stabilite de către organizații care
nu sunt proprietarul site-ului pe care îl vizualizați ( "t hird party cookies"). De exemplu, acestea
pot fi stabilite de alte site-uri care rulează conținut pe pagina pe care o vizualizați sau de către o
altă companie de analiză. Site-ul web pe care îl vizitați poate conține, de asemenea, un conținut
încorporat de pe alte site-ul și aceste site-uri își pot stabili, de asemenea, propriile cookie-uri. Un
site web ar putea utiliza o rețea de publicitate pentru a oferi publicitate direcționată. Aceste
cookie-uri pot de asemenea oferi posibilitatea de a urmări navigarea dumneavoastră pe diferite
site-uri. Există două tipuri de cookie-uri, descrise mai jos.
Cookie-uri de sesiune – cookie-urile de sesiune sunt stocate numai temporar în timpul
unei sesiuni de navigare și sunt șterse din dispozitiv atunci când browser-ul este închis.
Cookie-uri persistente – acest tip de cookie este salvat pe computerul utilizatorului pentru
o perioadă determinată (de obicei, un an sau mai mult) și nu se șterge când browser-ul este
închis. Cookie-urile persistente sunt folosite de la o sesiune de navigare la alta, de exemplu
pentru a stoca preferințele dumneavoastră, astfel încât acestea să fie memorate pentru următoarea
vizită.[4]
2.2.4. Sistem de administrare a conținutului (CMS)
CMS sau Content Management System este un sistem ce administrează, organizează și
reglează diferite operații de conținut, în special cele aparținând site-urilor web. Facilitatea acestui
sistem de administrare este aceea că reduce(uneori drastic) intervenția programatorilor.
Dimensiunea administrativă a paginilor web este foarte vastă. Există numeroase
programe precum DMS sau un sistem de administrare a documentelor(Document Management
System) sau ECS, sisteme de comerț electronic (E-commerce Systems) care preiau această
responsabilitate, devenind foarte dificil de făcut distincție între ele, dat fiind faptul că toate au
acest rol de a administra conținuturile care se suprapun cel mai adesea.
Ca orice sistem, CMS realizează o serie de operații, unite prin logica înlănțuirii dar și
interdependența acestora. Așadar, un CMS se ocupă cu crearea de documente, transferul
acestora, analiza lor (identificarea utilizatorilor care aduc cel mai mare aport managementului
conținutului și avertizarea lor în cazul unor schimbări ce îi interesează), stabilirea unor roluri sau
responsabilități categoriilor de conținut, organizarea versiunilor acelorași conținuturi într-o
bibliotecă/bază de date pentru a putea fi consultată cu ușurință.
Un CMS un sistem ce poate avea si funcții adiționale în administrarea site-urilor. Este
folositor pentru că permite accesul și celor neinițiați în operații tehnice, ajutându-i să opereze cu
succes crearea, organizarea, administrarea conținuturilor web. Precum am menționat și anterior,
CMS-ul dispune de o bază de date ce colectează și gestionează conținuturile, dar dispune în
egală măsură și de o interfață care este valabilă utilizatorilor prin acele modele (șabloane) de
imagine, totul realizându-se de obicei prin intermediul site-urilor web.
Alte funcții ale acestor sisteme ar fi :
•posibilitatea creării unor template-uri (șabloane) asimilabile noilor conținuturi,
ajutând astfel la schimbarea interfeței;
6

Capitolul 2. Fundamente teoretice
•editarea ușoară a noilor conținuturi (datorită designului care face evidentă paleta
de opțiuni disponibile utilizatorului);
•posibilitatea îmbunătățirii unor funcții a sistemului de administrare web, cât și
actualizarea sistemului în conformitate cu standardele web;
•gestionarea fluxului de lucru sau altfel spus, respectul a unor pași inseparabili ce
îi revine CMS-ului, de la creare până la operații de gestionare;
•analog fluxului de lucru, gestionarea documentelor trece prin același proces de
creare, organizare, sintetizare, arhivare sau ștergere.
CMS-ul veghează la fiecare pas din procesul de operare cu conținuturi de pe un site. De
la crearea și încărcarea unui conținut de către utilizatori, evaluarea acestuia de către editor,
publicarea de către editor șef pe site-ul funcțional, CMS-ul este un bun instrument în dozarea
efortului de către utilizatori.
De obicei, sistemul de administrare rulează de pe serverul site-ului, accesul făcându-se
prin browser-ul web (FTP pentru încărcarea conținutului). Baza de date este în legătură cu
serverul, loc unde se păstrează edițiile anterioare, versiuni nepublicate dar și cele publicate (cele
din urmă sunt valabile și vizitatorilor site-ului).
Termeni corelați cu CMS ar putea fi:
•Bloc – Un bloc este un link către o secțiune din site-ul web, ce poate fi vizibilă fie
din meniul de navigație, fie doar în pagina principală.
•Modul – Un modul de conținut este o secțiune a site-ului, de exemplu o colecție de
articole de știri, o secțiune FAQ, etc.
•Temă – O temă definește aparența fiecărei pagini din site, controlând proprietăți
cum ar fi culori și fonturi.
Tipuri de CMS:
•CMS-uri bazate pe module – Aceste module se ocupă de tot procesul creării,
editării, publicării și administrării conținuturilor.
•TODDS CMS (Totally Organic Data Driven System) – o unealtă nouă care ajuta
departamentele IT să-și facă slujba mai eficient, în special când aparțin unei
organizații de tip marketing.
•CMS bazat pe web – folosește baze de date cum ar fi PostgreSQL, MySQL sau
MS SQL și limbaje de scripting cum ar fi Coldfusion, PHP, JSP sau ASP pentru a
introduce datele în interfață, compilându-le în pagini HTML sau alte documente și
transformate folosind CSS. Aceste sisteme pot include un număr de alte funcții,
cum ar fi forumurile, blogurile sau newsletterele e-mail.
Dintre varietatea de CMS-uri , prin valoarea și eficiența lor se disting:
•WordPress – Web 2.0 și cea mai cunoscută platformă de blogging, facilitează
semnificativ activitatea utilizatorilor mai mult sau mai puțin experimentați tehnic,
doar prin intermediul unor teme si plug-in-uri ușor de manevrat.
•Drupal – are o capacitate mai complexă de acțiune, ceea ce-l califică ca fiind
eficient în mai multe sensuri: poate facilita scrierea unei cărți virtuale
(Collaborative Book), în care autorii sunt mult mai numeroși, de exemplu, însă
este utilizat în egală măsură și la gestionarea design-ului propriului site web.
•Joomla – sau “award winning” în concepția americană, este o bijuterie de
instrument administrativ al site-urilor web, întrucât este cu mult mai capacitat în a
gestiona site-urile decât un simplu web 2.0, precum portaluri ale unor corporații,
site-uri ale unor afaceri, site-uri personale, reviste online, având beneficiul de a
organiza mai bine utilizatorii, în funcție de atribuțiile fiecăruia, de a centraliza
toate tipurile de informații media. Plusul cel mare îl constituie “Banner manager”,
7

Crețu Paul Alexandru
care face posibilă afișarea reclamelor pe site-ul propriu. [5]
2.2.5. MongoDb
Utilizatorii din zilele cotidiene au cerințe noi pe care nu le mai satisfac bazele de date
SQL, una din principalele dorințe fiind ca aceștia nu doar să folosească bazele de date în vederea
interogării lor ci să și poată produce conținut. Astfel s-a produs o restructurare din punct de
vedere al mediului de stocare și folosire a datelor în domeniul Web. Din acest punct de vedere,
bazele de date relaționale nu mai reprezintă un răspuns viabil, mai ales atunci când se pune
problema construirea unei aplicații mari.
Printre primele aplicații care au abordat acest concept este Facebook. Această aplicație
Web este recunoscută în toată lumea și presupune un număr foarte mare de utilizatori, de ordinul
milioanelor. Alegerea acestui tip de baze de date a fost benefic, această aplicație având un timp
foarte scurt de răspuns, iar majoritatea acțiunilor implică lucrul cu baza de date.
În Figura 2.2 este ilustrată o comparație între baza de date MySQL și MongoDB:
Caracteristicile MongoDB sunt:
•Stocarea datelor sub formă de documente – Baza de date MongoDB stochează
obiecte (documente). Aceste documente reduc nevoia de join
•Prezintă support pentru indexare – Indexarea pe fiecare din atribute se face
în modul tradițional (RDBMS) asupra cheilor de regăsire ale documentelor;
•Auto-Sharding – shardingul sau partiționarea datelor pe orizontală se face
automat. Citirile și scrierile sunt distribuite pe partiții. Lipsa joinurilor face
ca interogările distribuite să fie rapide;
•Limbajul de interogare – Limbajul de interogare este îmbunătățit și păstrează
principii Sql și C++;
8
Figura 2.2: Mysql-MongDB comparație – imagine preluată de pe
http://rria.ici.ro/ria2012_4/art04.pdf

Capitolul 2. Fundamente teoretice
•Modificări rapide – MongoDB suportă operații de actualizare atomice cât și
pe cele tradiționale. [6]
2.2.6. Flask
Flask este un framework scris în Python și bazat pe setul de instrumente Werkzeug și a
motorului șablon Jinja2.
Din luna mai 2016, cea mai recentă versiune stabilă a Flask este 0.11. Exemple de
aplicații care folosesc cadrul Flask sunt Pinterest, LinkedIn, precum și pagina web a comunității
Flask.
Flask este un micro framework, deoarece nu forțează un dezvoltator să utilizeze un
anumit instrument sau o bibliotecă. Nu are nici un strat de bază de date abstracte, de validare a
form-urilor sau oricare alte componente care au în cadrul lor funcții predefinite. Cu toate acestea,
Flask suportă extensii care pot adăuga unele caracteristici aplicației ca și cum acestea au fost
implementate direct în Flask. Extensiile pot fi de validare a form-urilor, de încărcare a anumitor
tipuri de fișiere pe server, de autentificare, de generare automată a link-urilor, de criptare a
parolei, de realizare a conexiunii cu o bază de date specifică. Extensiile sunt actualizate mult mai
des decât programul de bază Flask în sine.
Caracteristici: conține opțiuni de debugging și dezvoltare de server, funcții de
implementare a serviciilor rest, utilizează Jinja2 pentru partea de template, suport pentru setarea
sigură a cookie-urilor (sesiuni pe partea de client), folosește standardele unicode ( standard
industrial de calcul pentru codificare coerentă, reprezentarea și manipularea textului exprimat în
cele mai multe sisteme de scriere din lume ), documentație extinsă, compatibilitate Google App
Engine, extensii disponibile pentru a îmbunătăți caracteristicile dorite. [7]
2.2.7. Jinja
Jinja2 este un generator de template-uri cu un număr mare de funcții predefinite, foarte
ușor de înțeles, care ajută la structurarea paginilor într-o metodă clară și concisă. Acesta are
suport unicode, un mediu de execuție pentru testare integrat utilizat pe scară largă și este licențiat
BSD. Cea mai des întâlnită utilizare a JavaScript este în scriptarea paginilor web. Programatorii
web pot îngloba în paginile HTML script-uri pentru diverse activități cum ar fi verificarea
datelor introduse de utilizatori sau crearea de meniuri și alte efecte animate. [8]
Exemplu de cod pentru generarea unei pagini în Jinja:
{% extends "layout.html" %}
{% block body %}
<ul>
{% for user in users %}
<li><a href="{{ user.url }}">{{ user.username }}</a></li>
{% endfor %}
</ul>
{% endblock %}
2.2.8. Blueprints
Un blueprint reprezintă un plan/model de definire a structurii aplicației ce poate avea în
componența sa colecții de template-uri, fișiere statice și alte elemente care pot fi aplicate unei
aplicații de tip web. De exemplu, să ne imaginăm că avem creat un blueprint (plan) pentru
panoul de administrare a unei aplicații. Acest model va fi definit și valabil pentru toate link-urile
9

Crețu Paul Alexandru
de forma /admin/login și /admin/dashboard. Poate deservi de asemenea și template-uri, dar și
fișiere statice (elemente css, javascript) pentru aceste link-uri.
Avantajul folosirii unui blueprint este că, pe lângă o structurare corectă și concisă a
fișierelor, acesta se poate oricând îndepărta de la aplicație fără a modifica întreaga structură a
proiectului.
De ce să folosim blueprint-uri?
Principalul motiv pentru a folosi blueprint-uri este de a organiza aplicația noastră în
componente distincte. Fiecare zonă a aplicației poate fi separată în zone distincte a codului.
Această opțiune ne permite să structurăm aplicația noastră în mai multe aplicații mici, în care
fiecare aplicație face un singur lucru. [9]
2.2.9. JSON
Pentru cei care nu sunt familiari cu acest termen, JSON este o abreviere pentru
JavaScript Object Notation . Reprezintă o tehnologie de serializare a datelor, așadar este foarte
apropiat ca și funcționalitate de limbajul XML, dar pentru majoritatea programatorilor JSON este
mai ușor și mai eficient. JSON a crescut în popularitate de când Douglas Crockford a propus
acest limbaj ca fiind alternativă la XML acum 15 ani.
Serializarea – reprezintă tehnică de convertire a diferitelor date în șiruri și conversia
acestor șiruri înapoi în valori. Mai adecvat, serializarea reprezintă un proces care generează o
reprezentare textuală a unor valori de execuție (cum ar fi o variabilă booleană, număr sau
matrice). Această operațiune nu ar fi prea folositoare dacă nu ar exista și deserializarea, operația
opusă care parcurge un șir de date serializate și le transformă în valorile inițiale.
2.2.10. De ce este serializarea benefică?
•Să putem salva valorile structurate, într-un fișier sau bază de date.
•Să putem trimite valorile într-o rețea, pe Internet, într-o rețea locală sau între
procesele de lucru ale aceleași aplicații.
2.2.11. Limitări
Ca în majoritatea aplicațiilor, există și limitări. Pentru început, unele valori nu pot fi
serializate într-un mod fiabil. Funcțiile sunt cel mai evident exemplu. Multe limbaje de
programare tratează funcțiile ca fiind un tip de dată și acestea au un scop lexical, deci contează
unde anume sunt funcțiile definite în cod. În aceste limbaje de programare nu puteți serializa
funcțiile, ele fiind privite ca un tip de dată.
Din acest motiv, pentru că serializarea poate fi complicată, multe limbaje de programare
au propriile lor abordări, care sunt optimizate. De exemplu în Python exista pickle, care știe
foarte multe despre acest limbaj și poate serializa o gamă relativ largă de obiecte. Abordările
proprii pentru serializare sunt benefice, dar în practică de multe ori avem nevoie pentru a
transfera date între procese care folosesc limbaje diferite. Poate un client Javascript dorește să
transmită date către un server Ruby, în acest caz trebuie folosită o metodă de serializare comună
celor două limbaje. [10]
10

Capitolul 3. Proiectarea Aplicației
Capitolul 3. Proiectarea Aplicației
Importanța analizei în detaliu asupra cerințelor aplicației este o etapă foarte importantă în
realizarea oricărei aplicații, etapă care de cele mai multe ori pare să fie tratată cu superficialitate.
Tratarea acestei etape cu superficialitate poate conduce la efecte majore negative care pot
afecta funcționalitatea proiectului. Un alt dezavantaj în urma acestei omiteri este faptul că se vor
consuma resurse mai multe și mai mari în etapa de realizare și dezvoltare a aplicației, deoarece
dezvoltatorul nu are o imagine foarte clară asupra cerințelor aplicației și nu știe exact care este
rezultatul final la care aplicația trebuie să ajungă.
Pentru ca analiza aplicației să fie realizată într-un mod corect și eficient, aceasta ar trebui
să cuprindă două mari etape:
-etapa de analiză din punct de vedere funcțional
-etapa de analiză din punct de vedere al interacțiunii utilizatorului cu interfața
Procesul de analizare a cerințelor în vederea proiectării aplicației se poate observa detaliat
în Figura 3.1 .
Unele cerințe rezultate în urma analizării pot acționa ca limitări în vederea dezvoltării
aplicației, acesta fiind un alt motiv bine întemeiat pentru tratarea acestei etape în detaliu. În cazul
în care avem o imagine clară asupra arhitecturii aplicației, cu siguranță se va reduce costul
aplicației într-un mod clar vizibil, dar și timpul în care vom finaliza aplicația cu succes va fi unul
mai scurt.
În urma unei analize în detaliu asupra arhitecturii aplicației mele, am ajuns la următoarele
concluzii:
•interfața aplicației trebuie să fie clară, butoanele să conțină texte relevante cu
acțiunile lor
•aplicația trebuie să răspundă acțiunilor în cel mai scurt timp posibil, fapt care m-a
determinat să fac un studiu amănunțit și asupra tehnologiilor folosite.
11
Figura 3.1: Analiza cerințelor – imagine preluată de pe
http://www.aut.upt.ro/staff/diercan/data/PSSC/curs-13.pdf

Crețu Paul Alexandru
•aplicația trebuie să răspundă cerințelor cotidiene, motiv pentru care am decis să
folosesc tehnologii de ultim moment, cele care sunt în continuă dezvoltare dar și
într-o continuă cerere.
3.1. Arhitectura aplicației
Aplicația este proiectată pe mai multe nivele, acestea fiind organizate independent, fapt
care conduce la structurarea fișierelor aplicației într-un mod clar și corect, dar totodată și la
structurarea codului pe module. Un alt avantaj major în structurarea aplicației pe mai multe
nivele este faptul că în orice moment când se dorește dezvoltarea aplicației sau mentenanța
acesteia se poate lucra exact în acea parte software fără a modifica tot conținutul aplicației.
Într-o altă ordine de idei, faptul că aplicația este structurată oferă posibilitatea
dezvoltatorului ca orice modul existent să poată fi folosit și în cadrul altor aplicații. [11]
În Figura 3.2 este ilustrată structura aplicației proiectate.
Principalele avantaje ale utilizării unei arhitecturi multi nivel sunt:
•Procesarea datelor indiferent de locația utilizatorului – trăim într-o eră în care
evoluția tehnologiei se face cu pași repezi, iar faptul că putem accesa unele
informații fără a fi constrânși de locația noastră reprezintă un important atu în
dezvoltarea aplicației.
•Comunicarea este sincronă – comunicarea între module este sincronă de tipul
cerere-răspuns. Această comunicare se face într-un sigur sens, în sensul că se
așteaptă cererea de la nivelul utilizatorului, aceasta este preluată și prelucrată de
către server, în final utilizatorul primește răspunsul dorit în cazul în care
operațiunea s-a efectuat cu succes sau este informat în cazul unei posibile erori.
•Securitatea – serverele au bun control asupra accesului și a resurselor, acela de a
asigura că doar clienții autorizați pot accesa și manipula informațiile existente.
12
Figura 3.2: Exemplu de arhitectură multi nivel – imagine preluată de pe https://www.google.ro/

Capitolul 3. Proiectarea Aplicației
Principalul dezavantaj al utilizării unei arhitecturi multi nivel este supraîncărcarea
serverului, și apare atunci când există multe cereri din partea utilizatorilor în același timp, de cele
mai multe ori serverul nu reușește o bună gestionare și un timp de răspuns atât de scurt încât să
nu fie supraîncărcat.
Aplicarea unei arhitecturi de tip multi-nivel presupune combinarea mai multor părți
software și/sau hardware cu scopul final de a realiza o aplicație funcțională, care să respecte
cerințele inițiale și care să ofere un timp cât mai scurt de răspuns.
Astfel, pot apărea nivele de tip interfață, utilizator, server de baze de date, etc. Într-o altă
ordine de idei aceste nivele pot funcționa simultan pe mai multe dispozitive, ceea ce duce la o
creștere substanțială în utilizarea sistemului.
O arhitectură pe trei nivele este structurată astfel :
•nivelul de prezentare sau nivelul client : – acest nivel are rolul de a realiza
legătura dintre interfață și utilizator. În cadrul acestui nivel se creează și se trimit
cereri HTTP către serverul web
•nivelul de business logic – acest nivel are rolul de a prelua cererile lansate de
către utilizator și de a le furniza mai departe următorului nivel. Este un nivel care
realizează legătura între celelalte două nivele.
•nivelul de bază de date – acest nivel reprezintă mediul de stocare al aplicației.
Principala sa funcționalitate este de a prelua informațiile de la nivelul logic și de a
le stoca sau furniza înapoi acestuia.
3.2. Nivelurile aplicației
Aplicația ce s-a dorit a fi implementată este realizată în baza arhitecturii pe trei nivele și
în continuare voi detalia fiecare nivel în parte.
3.2.1. Nivelul de prezentare
Fiind o aplicație web, pentru ca utilizatorul să o poată folosi trebuie să aibă instalat un
browser web. Acesta are rolul de a crea sau prelua cererile HTTP lansate de către utilizator și de
a le direcționa serverelor web în scopul prelucrării lor. Odată ajunse la serverul web, cererile vor
13
Figura 3.3: Exemplu de arhitectură pe 3 nivele (Imagine preluată de pe
http://researchpedia.info/difference-between-3-tier-and-mvc-architecture/ )

Crețu Paul Alexandru
fi prelucrate, iar în final, când această operațiune s-a realizat cu succes, serverul web v-a trimite
răspunsul browserului. Prin intermediul limbajelor HTML, CSS, Javascript și Jinja răspunsul
este interpretat și stilizat astfel rezultând pagina web dorită.
Imaginea din Figura 3.4 ilustrează cum se realizează interacțiunea utilizatorului cu
serverul web.
3.2.2. Nivelul de business logic
Acest nivel reprezintă puntea de legătură între nivelul de prezentare și nivelul de baze de
date. În cadrul acestuia răspunsul este preluat de la browserul web și urmează a fi prelucrat în
vederea obținerii informațiilor dorite. În același timp resursa primită poate fi creată, modificată,
ștearsă, citită din baza de date.
3.2.3. Nivelul de bază de date
Acest nivel cuprinde baza de date a aplicației mele. Am ales să folosesc o bază de date
nerelațională, din categoria NoSQL și anume MongoDB. Aceasta este o bază de date orientată
document, rapidă, flexibilă, datele sunt parcurse rapid. Colecțiile și structurile acesteia vor fi
descrise în capitolul de implementare a aplicației. [6]
3.3. Schema bloc a aplicației
➢ Partea de frontend – este partea în care utilizatorul accesează link-ul aplicației și poate
observa informațiile furnizate de către server și gestionate de către administratorul aplicației.
În cadrul acestei interfețe utilizatorului nu îi este cerută niciun fel de autentificare pentru a
vizualiza informațiile, prin intermediul acesteia se preiau cererile HTTP care sunt mai departe
transmise către server.
➢ Partea de backend (sau partea de administrare a aplicației) – este partea în care, prin
intermediul unui email și o parolă administratorul aplicației trebuie să se autentifice la sistem.
Dacă autentificarea s-a realizat cu succes, utilizatorul este redirecționat pe o pagină unde are
acces și dreptul de a modifica conținutul aplicației. Prin intermediul acestor pagini se
realizează anumite cereri http care apelează serviciile rest. O cerere este trimisă la serviciu, iar
dacă toate condițiile necesare (datele trimise să fie cele corecte, cererea să fie validă, serverul
cu serviciile rest să fie pornit, accesul la baza de date să fie făcut cu succes) sunt îndeplinite,
acel serviciu returnează un răspuns cu informațiile dorite.
➢ Interfața de acces la baza de date – reprezintă principalul mediu de stocare al informațiilor
din întreaga aplicație, prin urmare alegerea unei baze de date sigure și rapidă este o
caracteristică foarte importantă.
14
Figura 3.4: Nivelul de prezentare – imagine preluată de pe https://www.google.ro/

Capitolul 3. Proiectarea Aplicației
3.4. Modulele aplicației
Împărțirea aplicației pe module are ca principală caracteristică o mai bună organizare a
codului, pe mai mule fișiere. Un modul reprezintă o componentă software care poate fi scoasă
sau folosită și în altă aplicație. Faptul că aplicația este împărțita pe module face posibilă
înțelegerea funcționalității structurat, într-o manieră mai rapidă. Un alt avantaj major al folosirii
modulelor este acela că ajută foarte mult pe partea de mentenanță, deoarece atunci când se
dorește modificarea sau adăugarea unei funcționalități, programatorul trebuie să modifice doar
modulul respectiv, fără a afecta funcționalitatea întregii aplicații.
În cadrul acestui subcapitol voi detalia fiecare modul folosit în realizarea aplicației.
3.4.1. Modulul de autentificare
Prin intermediul acestui modul un utilizator se va putea autentifica în cadrul aplicației
realizate, cu scopul de a modifica sau adăuga conținut. Pentru ca autentificarea să aibă succes,
utilizatorul trebuie să acceseze zona de login, să introducă datele de autentificare corecte și sa
aibă rolul de administrator al aplicației. Acest rol se atribuie de către un administrator deja
existent pe site și trebuie aprobat pentru a fi valid. Dacă informațiile introduse nu sunt valide,
utilizatorul va fi redirecționat pe pagina de logare și va fi informat că datele nu sunt corecte sau
că acesta nu are dreptul de a accesa zona de administrare.
Spre exemplu, utilizatorul cu un email “test@test.com” și parola “test” dorește să
administreze conținutul aplicației. Acesta trebuie să acceseze link-ul de logare și sa introducă
datele de acces. Datele mai departe sunt verificate și dacă informațiile sunt corecte, acesta este
redirecționat în partea de administrare a aplicației, în caz contrar utilizatorului îi este afișat un
mesaj prin care este informat ca datele introduse nu sunt valide.
În Figura 3.5 este prezentat procesul de autentificare și accesare a resursei dorite.
3.4.2. Modulul de controlere
În cadrul acestui modul se regăsesc funcțiile create pentru întreaga funcționalitate a
aplicației, dar și apelul serviciilor rest care au o mare importanță în realizarea aplicației.
15
Figura 3.5: Modulul de
autentificare

Crețu Paul Alexandru
După ce utilizatorul cu emailul “test@test.com” trece de modulul de securitate
(autentificare), acesta are acces la sec țiunea de gestionare a conținutului aplicației. Să
presupunem că userul dorește să adauge o nouă pagină și pentru aceasta el va trebui sa introducă
anumite informații necesare care îi sunt menționate (titlul paginii, conținutul paginii, etc). În
momentul apăsării butonului de adăugare pagină noua, controlerul va prelua cererea și va studia
formatul linkului. În cazul în care nu există o funcție definită pentru acel link utilizatorul va fi
redirecționat către o pagină cu codul 404 (not found). În caz contrar, controlerul va accesa
16
Figura 3.6: Modulul de controlere

Capitolul 3. Proiectarea Aplicației
funcția definită pentru acel format de link în cadrul căreia este apelat și serviciul rest
corespunzător. La rândul său, serviciul rest care se va ocupa de funcționalitatea dorită verifică
dacă informațiile primite sunt corecte, în caz afirmativ se efectuează modificările asupra paginii
dorite și se trimite un răspuns de succes, în caz contrar se va returna un răspuns de eroare.
3.4.3. Modulul de servicii
Acest modul conține funcțiile ce implementează serviciile rest. În cadrul acestor funcții
se vor prelua parametrii și/sau datele primite împreună cu metodele de accesare a cererii HTTP,
după care se va realiza prelucrarea resursei și se va returna un răspuns controlerului. Rolul
principal al acestor servicii rest în aplicația realizată de mine este de a gestiona legătura dintre
resursa primită și baza de date.
3.4.4. Modulul de funcționalitate
Partea cea mai importantă din cadrul aplicației este realizată de către acest modul. La
rândul său acesta este împărțit în două mari module: cel care este responsabil pentru interfața cu
utilizatorul (frontend) și cel care este desemnat pentru gestionarea conținutului și la care au acces
doar utilizatorii autorizați (backend). Cu ajutorul acestor module, funcționalitatea aplicației va fi
structurată în funcție de tipul utilizatorului.
Modulul frontend – modulul este desemnat redării paginilor statice din aplicație, pagini
create fie în interiorul acestui modul (manual), fie create de către utilizatorii autorizați
(administratorii) în secțiunea de administrare conținut.
Modulul backend – în cadrul acestui modul regăsim funcționalități precum creare,
editare, ștergere a unei pagini. Tot prin intermediul acestuia, administratorul poate vizualiza toți
userii înregistrați în cadrul aplicației și le poate modifica starea lor (acceptare sau blocare) în
orice moment. O altă funcționalitate de bază din nucleul acestui modul este aceea de a crea sau
edita template-uri, funcționalitate care redă dinamism aplicației dar și posibilitatea userului de a-
și aranja propriul conținut fără a fi un bun cunoscător al limbajelor de programare, ci doar să
urmărească anumite reguli care trebuie impuse pentru o funcționare bună și sigură. Într-o altă
ordine de idei, funcționalitate precum gestionarea paginilor care să apară în meniu și ordinea lor
este o idee inovativă, bine primită de către publicul utilizatorilor, opțiune care permite
modificarea conținutului unei pagini întru-un interval de timp în care doar administratorii pot
vedea realizările făcute. Astfel se pot evita apariția unor nereguli din punct de vedere informativ,
dar și estetic.
O altă funcționalitate care crește dinamismul aplicației este aceea de a încărca fișiere și de
a le putea utiliza în conținutul oricărei pagini, fapt care oferă posibilitatea administratorului de a
schimba întreaga interfață a aplicației într-un timp relativ scurt.
În momentul în care este accesat unul din modulele mai sus prezentate, în funcție de
modulul apelat, controlerul accesează un anumit serviciu rest pentru a manipula informațiile în
baza de date.
Spre exemplu atunci când se dorește vizualizarea informațiilor despre o anumită pagină,
utilizatorul va apăsa fie pe edit, fie pe titlul paginii din cadrul list static pages, iar controlerul va
prelua toate informațiile despre acea pagina,le va formata și le va furniza serviciului rest
desemnat pentru modificarea unei pagini. Acesta va verifica informațiile primite și a returna un
JSON către controlerul apelant, care nu reprezintă altceva decât răspunsul serviciului REST.
17

Crețu Paul Alexandru
3.5. Tehnologia aleasă pentru implementare
Limbajul de programare ales pentru implementarea aplicației este Python. Python este un
limbaj de programare dinamic multi-paradigmă, creat în 1989 de programatorul olandez Guido
van Rossum.
Specificațiile principale care m-au determinat să aleg acest limbaj de programare sunt:
•Rapiditate – în ultimii ani s-au făcut lucruri uimitoare pentru a îmbunătăți
performanța Python, fapt care îl poate confirma și creșterea de cereri pentru acest
limbaj. Din punctul meu de vedere, dacă doriți performațe mari în domeniul
programării, Python este o opțiune viabilă în zilele noastre.
•Ușurință în învățarea limbajului, dar și în crearea aplicațiilor. Sintaxa limbajului
este proiectată pentru a fi ușor de citit. O mare parte din popularitatea Python se
află în domeniul de calcul științific. Oamenii care lucrează în acest domeniu sunt
în primul rând oameni de știință și nu programatori. [12]
•Portabilitate – din acest punct de vedere
Python stă foarte bine, fiind independent de platforma de lucru, aceeași aplicație
poate rula fără nici o modificare pe sistemele de operare.
•Popularitate – în ultima perioadă de timp, Python cunoaște o creștere
semnificativă pe piața limbajelor de programare, fapt care ne sugerează că poate
promite mult, este în plină desfășurare, deci dezvoltarea unei aplicații într-un
astfel de limbaj de programare este mai mult decât ideală.
Pentru dezvoltarea aplicației am folosit framework-ul Flask, utilizat pentru a crea și
aplicații web, deoarece oferă resurse și librării care îmi asigură buna funcționare pentru toate
cerințele propuse ale aplicației și de asemenea se bucură de o mare răspândire în domeniul IT.
O altă librărie care a fost esențială este librăria requests, special creată pentru mediul de
programare Python. Principala funcționalitate în lipsa căreia aplicația mea nu ar fi putut fi
realizată cu succes este apelul serviciilor rest prin intermediul acesteia. Prin intermediul acestei
librării nu a fost necesar să adaug șiruri de tip string la adresele URL sau să ma preocup de
conexiunile HTTP, toate acestea fiind realizate de către librăria expusă.
18

Capitolul 4. Implementarea aplicației
Capitolul 4. Implementarea aplicației
În acest capitol voi vorbi despre modul în care a fost implementată aplicația, dar și despre
tehnologiile folosite pentru a putea realiza aplicația dorită.
4.1. Nivelul de bază de date
Baza de date este proiectată pe modelul bazei de date nerelațională. Este o bază de date
orientată document, din categoria NoSQL . Bazele de date NoSQL au apărut ca noi generații de
baze de date ce se pliază perfect pe ultimele tehnologii folosite. [6]
Am ales acest tip de bază de date deoarece principalul avantaj pentru aplicația mea este
că, fiind o bază de date nerelațională, colecțiile care formează baza de date nu trebuie sa aibă un
număr fix de câmpuri, ceea ce mă avantajează foarte mult în ceea ce privește structura unei
pagini sau a meniului, unde se pot adăuga sau șterge mai multe câmpuri într-un mod dinamic.
Structura bazei de date este una sugestivă pentru aplicația realizată de către mine
cuprinzând următoarele colecții:
•counters – în această colecție am stocate unele valori care reprezintă
identificatorii (id) cu rol de autoincrement pentru pagini, meniuri, template-uri.
Aceste valori mă ajută în generarea unor id-uri de tip număr cu ajutorul cărora pot
obține informații despre o anumită secțiune.
• menus – în această colecție rețin informații legate de meniul aplicației, respectiv
id-ul paginilor pe care administratorul a dorit să le salveze în vederea afișării lor
în meniul principal.
•page – această colecție cuprinde informații despre fiecare pagină creată de către
administrator, dar și informații legate despre template-ul paginii și despre
câmpurile adăugate în fiecare pagină.
•templates – în această colecție se regăsesc toate datele cu privire la template-urile
(șabloanele) create de administrator. Tot în acest context se memorează conținutul
acestora, de unde este preluat și salvat și în fișierele cu extensie html, fișiere care
reprezintă template-ul aplicat fiecărei pagini.
•users – în cadrul acestei colecții se regăsesc informații legate de toți utilizatorii
aplicației, rolurile lor (0 – utilizator regulat, 1 – administrator) și starea lor
(acceptat sau blocat)
4.2. Nivelul de interfață cu baza de date
În cadrul acestui nivel se realizează operații de citire, scriere, modificare sau ștergere a
unei resurse din interiorul unei colecții. Conexiunea cu baza de date MongoDb este realizată în
interiorul modului rest, cu ajutorul librăriei flask_pymongo.
Salvarea de utilizatori, pagini, template-uri s-a realizat prin intermediul claselor. Am ales
această metodă deoarece aceste tipuri de resurse conțin cele mai multe câmpuri și am considerat
utilă o astfel de abordare pentru a reda aplicației dinamism, dar și o structurare cât mai bună a
codului pe module/funcții.
4.3. Nivelul de logică
Acest nivel reprezintă partea ce mai importantă a aplicației, în cadrul acestuia fiind
implementate și serviciile de tip rest. Acesta este împărțit în module:
•modulul de autentificare
19

Crețu Paul Alexandru
•modulul de controlerele
•modulul de servicii
În continuare voi detalia fiecare modul.
4.3.1. Modulul de autentificare
Acest modul mai poate fi numit și modulul securitate, deoarece în cadrul acestuia se fac
verificări de corectitudine și validare a unor informații pe care un utilizator le introduce în zona
de logare. Pentru ca logarea să se facă cu succes, utilizatorul trebuie sa îndeplinească următoarele
condiții:
•să fie înregistrat
•sa aibă acces la acea resursa (să nu fie blocat de către un administrator)
•datele introduse să fie corecte
Autentificarea se face în baza unei adrese de email și a unei parole. În cazul în care se dorește
autentificarea pentru partea de administrare, utilizatorul mai trebuie să aibă acordat rolul de
administrator și să fie validat, lucru care se realizează de către un alt administrator al aplicației.
Odată trimise, datele sunt preluate de către controler și furnizate mai departe către
serviciile rest. În cadrul acestei operații sunt făcute mai multe verificări și anume pentru email,
parolă, rol (dacă e administrator) și starea utilizatorului (acceptat sau blocat).
În momentul când toate aceste condiții s-au îndeplinit, se salvează în zona cookie a
browserului o sesiune pentru userul logat ce conține ca valoare id-ul utilizatorului. Stocarea
acestei sesiuni de cookie este necesară pentru verificarea stării utilizatorului (logat sau delogat),
dar și pentru realizarea deconectării în cazul când se dorește acest lucru sau atunci când variabila
de cookie expiră. În caz contrar, utilizatorul este redirecționat către pagina de login și este
informat că nu toate condițiile sunt îndeplinite, deci logarea nu a avut loc cu succes.
Partea de cod pentru controler este ilustrata mai jos:
@frontend.route('/adminlogin', methods=['GET', 'POST'])
def adminlogin():
if request.method == 'POST':
#preia credentiale
email=request.form['email'];
password=request.form['password'];
ok=1
headers = {'Content-Type': 'application/json'}
#apeleaza serviciul rest
req = requests.post(_urlRest('/userexists'),

data=json.dumps(email),headers=headers)
if req.status_code != requests.codes.ok:
#eroare
ok=0
error = 'Invalid Credentials. Please try again.'
context.update({'error':error})
else:
#succes REST
userExist=req.json()
userExist=userExist['userInfo']
passwordDB=userExist['password'];
checkPass=check_password_hash(passwordDB, password)
20

Capitolul 4. Implementarea aplicației
#Eroare credentiale
if checkPass!=True:
ok=0;
error = 'Invalid Credentials. Please try again.'
context.update({'error':error})
#a trecut cu succes
if ok==1:
response = make_response(redirect('/site-admin/dashboard'))
#setare cookie
response.set_cookie('userid', userExist['_id'])
return response;
else:
#redirect login in caz contrar
return render_template('/login.html',context=context)
Mai jos este ilustrată partea de servicii REST care este desemnată pentru verificarea
efectivă în baza de date a informațiilor trimise:
@restapi.route('/userexists',methods=['POST'])
def userExists():
data=request.json
if not data:
Response(status = '400')
else:
userExists=mongo.db.users.find_one({"email":str(data),"role":1})
if userExists:
if isinstance(userExists['_id'],ObjectId):
userExists['_id']=str(userExists['_id'])
return jsonify(userInfo=userExists)
else:
return Response(status = '400')
4.3.2. Modulul controler
În cadrul acestui modul se realizează funcționalitatea care asigură legătura dintre cererea
utilizatorului și interfața cu baza de date. După ce cererea HTTP este preluată, se caută un
controler care să fie definit pentru link-ul respectiv. În cazul în care controlerul este definit,
cererea este furnizată controlerului, iar în caz contrar se întoarce template-ul paginii
corespunzătoare codului 404 (not found). Pentru a defini un controler am folosit Blueprint
framework, despre care am oferit mai multe detalii în partea de fundamente teoretice. Tot în
cadrul unui controler trebuie specificat și link-ul cu metoda HTTP accesată.
Modul în care se definește un controler pentru un anumit link este ilustrat mai jos:
#definire parte controler
frontend = Blueprint('frontend', __name__,template_folder='templates')
#definire url controler
@frontend.route('/adminlogin', methods=['GET', 'POST'])
#înregistrare controler în aplicație
app.register_blueprint(frontend)
21

Crețu Paul Alexandru
4.3.3. Modulul servicii
Acest modul implementează serviciile Rest (Repressentational State Transfer ). Acestea
reprezintă un stil arhitectural pentru aplicațiile Web, ideea centrală fiind pusă pe reprezentarea
datelor. În serviciile web care se bazează pe acest tip de modul, informațiile despre metoda
accesată sunt date de metodele HTTP.
Cea mai important ă parte în serviciile REST este resursa, informațiile despre aceasta se
regăsesc de obicei în funcție de link-ul accesat. În aplicația mea, avantajul folosirii acestui tip de
resurse pe lângă faptul că acesta cunoaște o foarte mare răspândire, este timpul foarte scurt de
răspuns, fapt care oferă întregii aplicații rapiditate, cerință esențială a aplicației.Linkul de bază
pentru accesarea serviciilor REST în cadrul aplicației mele este „licenta.rest.com”, iar metodele
folosite pentru configurarea serviciilor sunt următoarele:
•GET – folosită pentru citirea informațiilor din baza de date
•POST – folosită pentru inserarea unor informații în baza de date
•PUT – folosită pentru actualizarea unei informații în baza de date
•DELETE – folosită pentru ștergerea unei informații în baza de date [2]
Formatul răspunsului serviciilor REST în aplicația mea este de tip JSON (JavaScript
Object Notation). Am ales acest tip de răspuns deoarece am considerat că este lizibil, pe lângă
faptul că acest format reprezintă un format universal de transmitere a datelor între diferite
platforme. Atunci când utilizatorul apelează o resursa REST cu succes, acesta returnează
răspunsul de forma 200 OK și conține informația serializată. Pentru a realiza serializarea am
folosit framework-ul jsonify, special creat pentru a realiza serializarea obiectelor în Python.
Pentru decodificarea răspunsului în format JSON am folosit librăria json din cadrul limbajului
Python. Modul cum lucrează un serviciu rest este ilustrat mai jos:

#apelare serviciu-modul controler
req = requests.get(_urlRest('/templates/'+idtemp))
#captare informații și stabilire răspuns-modul servicii
@restapi.route('/templates/<tempid>',methods=['GET'])
def getSingleTemplate(tempid):
if tempid:

singleTempCursor=mongo.db.templates.find_one({"_id":int(tempid)})
return jsonify(**singleTempCursor)
else:
return Response(status = '404')
#verificare răspuns primit de la serviciul REST-modul controler
if req.status_code != requests.codes.ok:
return 'eroare'
else:
4.3.4. Modulul ce conține clasele
Un alt modul care este implementat în cadrul aplicației realizate de mine este cel al
claselor, modul în care se regăsesc următoarele funcționalități:
•Criptare și verificare parolă criptată – folosite atunci când se creează un nou
utilizator sau atunci când se încearcă logarea unui utilizator existent.
22

Capitolul 4. Implementarea aplicației
def set_password(self, password):
self.password = generate_password_hash(password)

def get_password(self,password):
return check_password_hash(self.password, password);
•Salvare utilizatori – folosită atunci când se creează un nou utilizatori
class Users(object):
def save(self):
ok=1
headers = {'Content-Type': 'application/json'}
data = self.encode()
req = requests.post(_urlRest('/users'),data,headers)
if req.status_code != requests.codes.ok:
ok=int(req.status_code)
return ok
•Salvare template-uri – folosită atunci când se creează un nou template
class Templates(object):
def save(self):
headers = {'Content-Type': 'application/json'}
data = self.encode()
req = requests.post(_urlRest('/templates'),data,headers)
ok=int(req.status_code)
return ok
•Salvarea unei pagini – folosită atunci când se creează o nouă pagină
class Pages(object):
def save(self):
ok=1
headers = {'Content-Type': 'application/json'}
data = self.encode()
req = requests.post(_urlRest('/page'),data,headers)
if req.status_code != requests.codes.ok:
ok=int(req.status_code)
return ok
4.4. Nivelul prezentare
În interiorul acestui nivel am realizat partea de interfață cu utilizatorul, iar pentru design
am ales să folosesc un template, deoarece principala contribuție în aplicația mea a fost
funcționalitatea.
Această parte cuprinde un modul de frontend, în care este realizată funcționalitatea de
afișare a paginilor statice și tot ceea ce un vizitator poate observa, fără a fi nevoit să se
autentifice. O alta parte importantă din cadrul acestui nivel o reprezintă paginile cu extensia
.html, care au un rol esențial în afișarea conținutului aplicației.
Html (Hyper Text Markup Language) este cel mai folosit limbaj Web cu rolul esențial în
afișarea paginilor web. Acest limbaj a fost inventat de Berners Lee în anul 1991, dar primele
specificații ale limbajului au apărut în anul 1995. Având în vedere faptul că în era noastră se pune
23

Crețu Paul Alexandru
din ce în ce mai mult accentul pe tehnologie, iar aplicațiile cunosc o popularitate foarte mare,
template-ul ales utilizează tehnologia responsive design. Această tehnologie constă în faptul că,
deși aplicația mea este una de tip web, aceasta are posibilitatea de adaptabilitate a design-ului în
funcție de dispozitivul de pe care este accesată. [13]
Pentru realizarea acestei funcționalități s-a ales utilizarea librăriei Bootstrap. Bootstrap
oferă fișiere cu extensia CSS ce conțin clase cu reguli predefinite, cu ajutorul cărora interfața
html se poate adapta din punct de vedere al design-ului în funcție de dimensiunile ecranului
dispozitivului de pe care este accesată. Aplicația realizată este una de tip multi-page. Această
caracteristică constă în faptul că, în comparație cu aplicațiile de tipul single-page, aplicația mea
conține mai multe pagini și resursele necesare afișării acestora sunt încărcate dinamic, în
momentul accesării paginii.
Pentru partea de animații s-au folosit unele funcționalități din interiorul librăriei
Bootstrap, dar s-a pus accentul și pe limbajul Javascript. Acesta este un limbaj cel mai adesea
folosit de către programatori pentru a crea pagini web. O altă funcționalitate majoră este crearea
și modificarea animațiilor, fapt care oferă aplicației o mai bună interacțiune cu utilizatorul.
Interfața cu utilizatorul este împărțita în două mari componente. Partea de frontend (cea
pe care o poate accesa vizitatorul) și partea de backend (cea pe care o poate accesa
administratorul aplicației în vederea modificării conținutului). Pe partea de frontend se regăsesc
toate paginile create și publicate în zona de meniu.
Trecerea de la o pagină la alta se poate realiza prin accesarea oricărui link din bara de
navigație a aplicației, sau schimbând adresa url din bara browserului. În vederea realizării acestei
funcționalități, am ales să realizez o funcție care primește ca parametru identificatorul unic al
paginii (slug). În cadrul funcției realizate, se verifică dacă acel slug este valid ( dacă este stocat
în baza de date). În caz afirmativ, se preiau din baza de date toate informațiile corespunzătoare și
se afișează acestea prin intermediul template-urilor html, care pot fi definite de către
administrator în mod dinamic și a extensiei Jinja.
Codul care a fost realizat pentru această funcționalitate este prezentat în detaliu mai jos:
@frontend.route('/<page_slug>/')
def static_page(page_slug):
context={}
#creare cale pentru serviciile REST
urlNew="/pageslug/"+str(page_slug)
req = requests.get(_urlRest(urlNew))
#codul de răspuns nu este 200
if req.status_code != requests.codes.ok:
return 'eroare'
#se preiau informațiile
pageExist=req.json()['pageExist']
#în cazul în care slug-ul este greșit se returnează template-ul not
found
if pageExist==None:
return render_template('staticPages/page_not_found.html'), 404
#in caz contrar se stabiliște template-ul paginii și se afișează
utilizatorului conținutul paginii
else:
pageTemplate=pageExist['page_template']+'.html'
context.update({'page_info':pageExist})
return render_template('/staticPages/'+pageTemplate,page=pageExist)
24

Capitolul 4. Implementarea aplicației
Jinja este un framework special creat pentru limbajul Python, în vederea dinamizării
design-ului și în componența sa conține un concept extrem de eficient și anume cel de moștenire
al template-urilor. Acest concept constă în faptul că se definește un template de bază (părinte) în
interiorul căruia se introduc toate datele comune tuturor paginilor care îl vor moșteni, în special
fișierele CSS, Javascript și toate secțiunile comune. Template-ul de baza pentru o pagină statică
este ilustrat mai jos:
<!DOCTYPE html>
<html lang="en">
<head>
{% block head %}
<link rel="stylesheet" href="style.css" />
<title>{% block title %}{{context['title']}}{% endblock %} – My
Webpage</title>
{% endblock %}
</head>
<body>
{% block body %}
<ul class="nav-list">
{% set counter = 0 -%}
{% for url in urls -%}
<li><a href="{{ url }}">{{ url }}</a></li>
{% set counter = counter + 1 -%}
{% endfor -%}
</ul>
<div id="content">{% block content %}{% endblock %}</div>
<div id="footer">
{% block footer %}
&copy; Copyright 2008 by <a href="http://domain.invalid/">you</a>.
{% endblock %}
</div>
{% endblock %}
</body>
</html>
După cum bine putem observa, în componența acestui template observăm sintaxa de
forma {% block nume_block %}{% endblock %}, care definește o variabilă de template,
variabilă ce poate fi accesată și modificată din cadrul oricărei pagini care moșteneste șablonul.
Pentru ca un template să fie moștenit este nevoie de apariția sintaxei de forma {%
extends "nume_parinte.html" %} în interiorul șablonului copil. Un exemplu de moștenire este
prezentat mai jos:
{% extends "layout.html" %}
{% block head %}
{{ super() }}
{% endblock %}
{% block content %}
25

Crețu Paul Alexandru
{% import 'forms.html' as forms %}
<h1>{{context['title']}}</h1>
{% if context['error'] %}
<p class="error"><strong>Error:</strong> {{ context['error'] }}
{% endif %}
<h1></h1>
<p class="important"></p>
<form action="" method="POST">
<div class="each_row">
<div class="label">Email</div>
<div
class="form_element">{{ forms.input('email',value=email) }}</div>
<div>
<div class="each_row">
<div class="label">Password</div>
<div class="form_element">{{ forms.input('password',
type='password') }}</div>
<div>
<button type="submit">Submit</button>
</form>
{% endblock %}
Tot prin intermediul extensiei Jinja am definit un al fișier, forms.html care con ține în
interiorul lor anumite funcții de definire a input-urilor, apelate sub forma
{{ forms.input('email',value=email) }}. Această opțiune ajută foarte mult dezvoltatorul în special
pentru a avea o structură cât mai clară și structurată asupra fișierelor cu extensia html.
Codul care definește funcțiile este prezentat mai jos:
{% macro input(name, value='', type='text') -%}
<input type="{{ type }}" value="{{ value|e }}" name="{{ name }}">
{%- endmacro %}
{%- macro textarea(name, value='', rows=10, cols=40) -%}
<textarea name="{{ name }}" rows="{{ rows }}" cols="{{ cols
}}">{{ value|e }}</textarea>
{%- endmacro %}
Pentru partea de gestionare a conținutului aplicației, în vederea design-ului am folosit un
template realizat în cadrul companiei la care lucrez. S-au respectat întru totul principiile enunțate
mai sus. Navigarea aplicației se face diferit, meniul cuprinzând informații legate strict de această
parte de funcționalitate.
26

Capitolul 4. Implementarea aplicației
Administratorul aplicației are acces la următoarele funcționalități:
•List Admins, List Users – în aceste secțiuni sunt listați toți utilizatorii aplicației.
Evenimentele care pot fi realizate de către administrator sunt aprobarea sau
blocarea unui user.
•Add Admins, Add Users – în aceste zone se pot adăuga utilizatori în cadrul
aplicației. Administratorul poate decide dacă tipul utilizatorului va fi unul normal
sau adminstrator.
•Manage Menus – în această secțiune utilizatorul poate vedea meniurile existente
pe site și are acces de editare asupra acestora. El poate aduce modificări meniului
în sensul că poate schimba ordinea paginilor și adăuga sau elimina pagini.
•Accesând meniul static pages utilizatorul poate adăuga sau edita conținutul
paginilor. Procesul de adăugare a unei pagini și afișarea ei o voi detalia în cele ce
urmează.
•Site Gallery-în cadrul acestei zone se pot vizualiza toate informațiile de tip
imagine, însă administratorul poate și adăuga altele noi în vederea folosirii lor
pentru conținutul paginilor.
27
Figura 4.1: Meniu navigare administrator

Crețu Paul Alexandru
•Zona de Page Templates este destinată șabloanelor aplicației pentru paginile
create. În cadrul acestei zone se pot adăuga sau edita template-urile paginilor,
pentru o mai bună gestionare din partea utilizatorului.
O funcționalitate asupra căreia doresc să ma opresc și să o detaliez este cea de adăugare a
unei pagini și afișarea ei în conținutul aplicației. Pentru ca un administrator să poată adăuga o
nouă pagină, acesta trebuie să fie autentificat, să acceseze zona de static pages a meniului și să
selecteze secțiunea Add Static Page.
După realizarea cerințelor enunțate, utilizatorului îi este afișată zona de adăugare a unei
pagini unde acesta trebuie să introducă toate informațiile necesare publicării. Tot în cadrul
acestei pagini se poate observa existența unui buton Add Field care are rolul de adăuga un nou
text-box pentru conținut, opțiune ce oferă o mai bună structurare a aplicației în cazul în care o
anumită pagină dispune de foarte mult conținut. Un aspect care nu trebuie trecut cu vederea este
numele acestui câmp, care trebuie reținut de către administrator, deoarece acesta îi este util în
momentul când se dorește afișarea conținutului în zona de template.
În Figura 4.2 este ilustrat modul de adăugare a unei noi pagini:
După ce toate informațiile dorite sunt introduse, acestea urmează a fi publicate prin
apăsarea butonului Save. Pentru afișarea conținutului în modul dorit, am hotărât să folosesc un
șablon special create pentru această pagină. Pentru aceasta administratorul trebuie să navigheze
la secțiunea Page Templates din meniu și să acceseze zona Add Page Template. În urma
efectuării acestor pași, utilizatorului îi va fi afișată o pagină unde acesta trebuie să introducă
numele șablonului și conținutul efectiv. Pentru conținut am ales structura oferită de Jinja și
anume moștenire de template. Pentru afișarea conținutului paginii adăugate, utilizatorul trebuie
28
Figura 4.2: Adăugare unei noi pagini

Capitolul 4. Implementarea aplicației
să introducă sintaxa {{page['page_content']|safe}}. În cazul în care pagina adăugată conține și
câmpuri suplimentare, acestea pot fi afișate în cadrul template-ului prin sintaxa
{{page['extraFields']['NUMECÂMP']|safe}}, unde NUMECÂMP reprezintă numele atributului
adăugat ce se dorește a fi afișat.
În Figura 4.3 este prezentat un model de template pentru pagina principală a aplicației:
În cazul în care template-ul a fost creat după momentul creării paginii, utilizatorul trebuie
să navigheze în zona de List Static Pages, să editeze pagina dorită în vederea setării șablonului
corespunzător. După ce această etapă este realizată cu succes, utilizatorul mai trebuie doar să o
adauge în meniul aplicației și pagina va fi vizibilă.
29Figura 4.3: Adăugarea unui template
Figura 4.4: Afisare slider conform șablonului

Crețu Paul Alexandru
4.5. Probleme întâmpinate și soluții alternative în dezvoltarea aplicației
Principala problemă cu care m-am confruntat în dezvoltarea aplicației a fost modul în
care am realizat adăugarea unei noi pagini astfel încât să fie foarte ușor pentru utilizator, luând în
considerare faptul că acesta nu trebuie să aibă neapărat cunoștințe de programare. Ca soluție
alternativă am abordat tehnica creării și modificării de șabloane împreună cu funcționalitatea de
a adăuga noi câmpuri de tip conținut pentru o mai bună structurare a paginii, dar și pentru o mai
bună gestionare a datelor din cadrul acelei pagini.
O altă problemă cu care m-am confruntat a fost accesarea serviciilor REST, care inițial
erau implementate în interiorul unui modul al aplicației. Principala dificultate a fost faptul că
serviciile și aplicația aveau același link de bază. Soluția pe care am abordat-o a fost să structurez
partea de servicii într-un modul separat, care rulează pe un server diferit de cel al aplicației, astfel
având un link diferit de rulare.
Având în vedere faptul că este un prototip, cu siguranță nu cred că am reușit să acopăr
toate cazurile de testare, astfel fiind posibil apariția anumitor bug-uri.
30

Capitolul 5. Testare și rezultate
Capitolul 5. Testare și rezultate
Testarea aplicației reprezintă o etapă esențială în dezvoltarea acesteia. În cadrul
implementării proiectului, din cauza unor situații neprevăzute, nu am luat în calcul toate
evenimentele ce pot interveni atunci când existe diferențe între rezultatele obținute în urma
execuției unei anumite funcții și rezultatele așteptate.
Am ales să testez fiecare funcție imediat după ce a fost implementată, astfel am reușit să
rezolv apariția unor eventuale neconcordanțe, dar și propagarea lor în nucleul aplicației.
Pentru aplicațiile de tip web există mai multe tipuri de testare:
➢ Testarea unitară – se realizează în special de către programator. Aceasta constă în testarea
metodelor implementate în aplicație. Această testare nu se poate realiza ușor dacă arhitectura
aplicației nu este bine structurată.
➢ Testarea funcțională – se testează funcționalitatea propriu zisă și cuprinde verificări pentru
redirecționări invalide, verificări ale întreg mecanismului de lucru a sistemului
➢ Testarea utilizării – principalul responsabil pentru aceasta este clientul, în cadrul acesteia se
testează cât de ușor este modul de a folosi aplicația.
➢ Testarea compatibilității – se testează compatibilitatea în diferite browsere, compatibilitatea
cu diferite sisteme de operare, compatibilitate pe dispozitive diferite de lucru.
➢ Testarea performanței – se realizează pentru a studia timpul de răspuns al serverului și timpul
de încărcare al aplicației.
•Testarea de încărcare – reprezintă cea mai simplă formă de testare care conduce
la înțelegerea comportamentului sistemului supus la o anumită sarcină de lucru.
Testarea de încărcare are ca răspuns măsurarea tranzacțiilor critice și încărcarea
bazei de date.
•Testarea de stres – se realizează pentru a găsi capacitatea de limită superioară a
sistemului
•Testarea de nivel înalt – se realizează prin creșterea numărului de utilizatori dintr-
o dată cu o cantitate foarte mare și se măsoară performanțele sistemului. Scopul
principal este de a determina dacă sistemul va fi capabil să susțină sarcina de
lucru.
➢ Testarea securității – efectuată pentru a vedea dacă aplicația este securizată pe web împotriva
furtului de date și a accesului neautorizat. Mai jos am enunțat câteva posibile tehnici de
verificare a nivelului de securitate:expunere de date sensibile care pot da informații despre
accesul sau câmpurile din baza de date, injecție, folosirea unor componente vulnerabile,
apariția unor erori vulnerabile la autentificare. [14]
5.1. Testele unitare
Conform literaturii software de specialitate, o unitate se definește ca fiind cea mai mică
bucată de cod ce se poate testa. De obicei aceasta poate fi o metoda, un pachet sau o mulțime de
clase. Dispozitivul pe care se poate test poate fi calculatorul. Testele unitare reprezintă doar o
etapă din întregul ansamblu de testare a unei aplicații web. Aceasta este văzută în general ca o
clasă de test din cadrul white box testing (tehnică de testare care urmărește mecanismul
aplicației), operațiune care ia în calcul doar rezultatul obținut în urma introducerii unui șir de
date și ignoră mecanismul intern al proiectului. [15]
În cadrul aplicației mele am folosit framework-ul unittest, special creat pentru limbajul
Pyhon. Am reușit să implementez teste unitare pentru clasa Users, clasă ce se ocupă cu crearea
unui nou utilizator, criptarea unei parole, verificarea unei parole. Testul implementat se regăsește
31

Crețu Paul Alexandru
în fișierul junit_testin.py, din cadrul aplicației și rezultatul acestuia este ilustrat în Figura 5.1
5.2. Testele automate
Acest tip de teste au un rol important mai ales atunci când se dorește testarea unei
aplicații mari, în care testele manuale sunt foarte greu de urmărit și de efectuat. Extensia pe care
am ales-o în vederea efectuării acestor teste este Selenium, un mediu foarte popular pentru
testarea automată. Acesta preia controlul browserului și execută instrucțiuni pe care le-ar fi
executat un utilizator. Pentru limbajul Python se poate executa cod ce poate fi rulat pe post de
test, în cadrul acestui cod trebuie specificat cu ce browser se dorește testarea. Eu am ales să fac
testul asupra timpului efectiv de deschidere a paginii de start și browserul folosit de mine este
Firefox. Codul care realizează acest test se găsește la calea testing/selenium_testing.py, iar mai
jos este listată secvența principală:
def setUp(self):
self.driver = webdriver.Firefox()
def test_search_in_python_org(self):
driver = self.driver
#adresa care se testează
driver.get(" http://licenta.local.com:5000/homepage/ ")
#caut cuvântul Homepage în titlul paginii
self.assertIn("Homepage", driver.title)
def tearDown(self):
self.driver.close()
În interiorul metodei setUp se stabilește browserul dorit, în cazul meu acesta este Firefox.
Metoda test_search_in_python_org reprezintă principala funcționalitate a testului. În cadrul
acesteia se setează adresa care se dorește a fi deschisă. Funcția tearDown va fi apelată după
fiecare test. Aceasta reprezintă locul unde se fac acțiunile de terminare a testării, în cazul meu
acțiunea dorită este închiderea browserului. În Figura 5.2 se poate observa timpul de răspuns și
răspunsul efectiv al realizării testării.
32
Figura 5.1: Test unitar asupra clasei Users
Figura 5.2: Exemplu test automat folosind Selenium

Capitolul 5. Testare și rezultate
5.3. Testarea funcțională și a interfeței
Testarea funcțională este realizată manual, de către utilizator și reprezintă acele teste de
validare și autentificare din cadrul aplicației. Am hotărât să ma opresc spre a testa
funcționalitatea de autentificare a unui user deoarece reprezintă o parte importantă din cadrul
aplicației și nu trebuie omisă. În momentul introducerii unor date care nu sunt corecte,
utilizatorul este informat acest lucru. În Figura 5.2 este ilustrată interfața cu utilizatorul în urma
realizării acestui test.
Un alt test important pe care l-am realizat este atunci când se dorește adăugarea unei noi
pagini, dar nu sunt completate toate câmpurile. Utilizatorul este informat în acest sens și
operațiunea nu se poate duce la bun sfârșit.
33
Figura5.3: Testare credențiale zona de logare
Figura 5.4: Testare adăugarea unei pagini având câmpuri necompletate

Crețu Paul Alexandru
Capitolul 6. Concluzii și directive de dezvoltare
Această aplicație a fost proiectată cu scopul de a ajuta oamenii în vederea realizării unui
site propriu fără a fi nevoie de cunoștințe în domeniul programării sau a unui limbaj de
programare specific.
Implementarea aplicației a fost făcută astfel încât să fie ușor de înțeles și folosit de către
orice utilizator. Implementarea interfeței s-a făcut după două cerințe principale:
•să fie interactivă din punct de vedere vizual
•să fie clară și să ofere informații utilizatorului despre fiecare acțiune care poate fi
executată
Consider că am atins aceste obiective, folosind ultimele tehnologii în domeniu. Funcționalitățile
propuse pentru aplicația implementată au fost:sistem de gestiune al paginilor (creare, editare,
ștergere), funcționalitate de editare a meniului ce se dorește afișat pe partea de frontend, creare
de utilizatori și modificarea stării acestora și funcționalitate de gestiune a fișierelor media. Toate
aceste propuneri au fost realizate cu succes și pe lângă acestea am implementat și opțiunea de
creare și editare al unui șablon de pagină, fapt care a dat aplicației un motiv în plus de utilizare.
Folosind această aplicație, orice utilizator își poate realiza propriul site, dar mai mult,
acesta poate modifica și adăuga conținut în orice moment fără a fi nevoie de prezența unui
programator experimentat în vederea realizării acestui lucru.
În cadrul dezvoltării aplicației, am dorit ca implementarea să fie structurată pe module,
fapt care conduce la o bună structurare a codului. Un alt avantaj major al acestei caracteristici
este faptul că orice alt dezvoltator va înțelege foarte ușor codul, fapt care duce la reducerea
costurilor în cazul în care se va dori adăugarea unor noi funcționalități asupra proiectului.
Pașii esențiali în dezvoltarea acestui proiect ar fi folosirea tehnologiei CDN (content
delivery network), tehnologie care constă în existența unui sistem de servere distribuite ce
furnizează paginile în funcție de locația geografică a utilizatorului, de originea paginilor și de
localizarea serverelor. Acest fapt ar avea un impact major în reducerea timpului de răspuns al
aplicației.
Într-o altă ordine de idei, o zonă de plugin-uri ar fi foarte benefică pentru utilizatori. În
această secțiune vor fi listate toate aplicațiile realizate de către dezvoltatori împreună cu o scurtă
descriere asupra acestora. Administratorul aplicației va putea instala modulele dorite, iar în cazul
în care nevoile acestuia nu sunt satisfăcute el o va putea dezinstala și șterge din sistem.
O altă opțiune în vederea dezvoltării ar fi o secțiune de blog, unde administratorul, dar și
utilizatorii vor putea publica diferite anunțuri sau informații în funcție de categoriile din care
acestea fac parte. Îmbunătățirea securității și o testare mai riguroasă asupra aplicației ar fi
benefice, aceste două aspecte fiind atinse de mine, dar la un nivel mediu, neavând cunoștințele
necesare în domeniu.
34

Bibliografie
Bibliografie
[1]The Advantages and Disadvantages of a WordPress Website [Online], Disponibil la adresa:
http://www.designedtoconnect.com/the-advantages-and-disadvantages-of-a-wordpress-website/,
Accesat: 2016.
[2]Ana Olteanu, [Online], Disponibil la adresa:
http://stst.elia.pub.ro/RIC/Teme_RIC_2008_9/AnaOlteanu/proiectFinal.doc, Accesat: 2008.
[3]Autentificarea [Online], Disponibil la adresa:
http://searchsecurity.techtarget.com/definition/authentication, Accesat: 2016.
[4]„Cookies PDF”, , .
[5]Ce este un CMS [Online], Disponibil la adresa: http://www.hostpedia.ro/ce-este-un-cms-top-cms-
uri, Accesat: 2016.
[6]Elena-Geanina Ularu,orina Puican, Revista Română de Informaticăși Automatică [Online],
Disponibil la adresa: http://rria.ici.ro/ria2012_4/art04.pdf, Accesat: .
[7]About Flask [Online], Disponibil la adresa: https://www.fullstackpython.com/flask.html, Accesat:
2016.
[8]Jinja [Online], Disponibil la adresa: http://jinja.pocoo.org/, Accesat: 2016.
[9]Blueprints [Online], Disponibil la adresa: http://exploreflask.com/en/latest/blueprints.html#what-is-
a-blueprint, Accesat: 2016.
[10]Json [Online], Disponibil la adresa: http://tutorials.pluralsight.com/software-engineering-best-
practices/everything-you-need-to-know-about-json, Accesat: 2016.
[11]Proiectarea sistemelor software complexe, curs 13 [Online], Disponibil la adresa:
http://www.aut.upt.ro/staff/diercan/data/PSSC/curs-13.pdf, Accesat: 2016.
[12]5 Reasons why Python is Powerful Enough for Google [Online], Disponibil la adresa:
https://www.codefellows.org/blog/5-reasons-why-python-is-powerful-enough-for-google, Accesat:
2016.
[13]Design Responsive [Online], Disponibil la adresa:
http://www.freshideas.ro/blog_web_design_responsive_obligatoriu.php, Accesat: 2016.
[14]Web Application Testing [Online], Disponibil la adresa:
http://www.tutorialspoint.com/software_testing_dictionary/web_application_testing.htm, Accesat:
2016.
[15]Rodney Parkin, Software Unit Testing [Online], Disponibil la adresa:
http://condor.depaul.edu/sjost/hci430/documents/testing/UnitTesting.pdf, Accesat: 2016.
35

Crețu Paul Alexandru
Anexe.
Codul complet se găsește pe cd.
36