Universitatea Politehnica Bucureti Facultatea de Automatic i Calculatoare

Sistem Integrat pentru Managementul unei Companii

Conductor tiinific: Sl. Dr. Ing. Mdlin Vlad

Absolvent: Udrea Emanuel

Bucureti 2009

Cuprins
Cuprins......................................................................................................................1 1. Introducere ............................................................................................................3 1.1 Definirea problemei ........................................................................................4 1.2 Scopul proiectului...........................................................................................4 2. Tehnologii i nouti n domeniu...........................................................................5 2.1 World-Wide Web n ziua de azi .....................................................................5 2.1.1 HTML ....................................................................................................6 2.1.2 CSS ........................................................................................................7 2.1.3 Web 2.0..................................................................................................9 2.2 Programare server side .................................................................................13 2.2.1 Hypertext Preprocessor (PHP) ............................................................13 2.2.2 SQL......................................................................................................14 2.2.3 Apache .................................................................................................16 2.3 Programare client side..................................................................................21 2.3.1 Javascript.............................................................................................21 2.3.2 Javascript asincron i XML (AJAX)....................................................24 2.4 Securitatea aplicaiilor web ..........................................................................30 2.4.1 Validarea mai sigur a datelor din formulare.......................................30 2.4.2 mbuntirea securitii sesiunilor ......................................................31 2.4.3 Asigurarea securitii SQL ...................................................................32 2.4.4 Criptarea i securitatea bazelor de date ...............................................33 3. Analiza i proiectarea aplicaiei...........................................................................35 3.1 Descrierea cazurilor de utilizare ...................................................................35 3.2 Alegerea modelelor de dezvoltare .................................................................38 3.3 Nucleul aplicaiei..........................................................................................40 3.4 Modulele aplicaiei .......................................................................................42 3.5 Seciunea Utilizatori.....................................................................................43 3.5 Seciunea multilingvistic.............................................................................43 3.5 Descrierea unor moduri de lucru ..................................................................44 3.6 Mrirea nivelului de abstractizare ................................................................50 3.7 Portarea modelului aplicaiei........................................................................52 1

4. Instalarea aplicaiei .............................................................................................53 4.1 Configurarea aplicaiei .................................................................................53 4.2 Descrierea componentelor.............................................................................54 4.4 Descrierea managementului aplicaiei...........................................................55 4.3 Gzduirea aplicaiei web ..............................................................................56 4.3.1 Alegerea unei companii de gzduire web ..............................................56 4.3.2 Crearea bazei de date pe serverul de gzduire......................................57 4.3.3 Copierea aplicaiei pe serverul web ......................................................59 5. Prezentarea aplicaiei ..........................................................................................61 5.1 Elemente de configurare ...............................................................................61 5.2 Conectarea la baza de date ..........................................................................62 5.3 Autentificarea n aplicaie ............................................................................62 5.4 Administrarea utilizatorilor..........................................................................64 5.5 Meniuri, navigare i interfaa cu utilizatorul................................................65 5.5.1 CSS Sprite............................................................................................66 5.5.2 Roll over offect.....................................................................................67 5.5.3 Ajax loading effect ...............................................................................69 5.5.4 Design-ul aplicaiei...............................................................................70 5.6 Descrierea unor moduri de lucru ..................................................................73 5.7 Suport multilingvistic...................................................................................77 5.8 Baza de date.................................................................................................79 5.9 Structura directoarelor i a fiierelor ............................................................82 6. Dezvoltri ulterioare............................................................................................84 6.1 Evoluia tehnologic.....................................................................................84 6.2 Extinderea funcionalitilor ........................................................................85 7. Concluzii..............................................................................................................87 Bibliografie ..............................................................................................................89 Index figuri..............................................................................................................91

Capitolul 1

Introducere

Astzi Internetul i n general univertsul IT a ptruns mai mult ca niciodat n viaa noastr, mbogind-o cu fiecare link accesat, cu fiecare email primit. Depinde n totalitate de noi cum vom folosi acest cadou pentru a ne bucura de via i a mbogi i pe alii cu experiene placute i interesante. Internetul deschide noi oportuniti de a pstra i mbogi relaiile dintre oameni, iar lumea computerelor devine mai abordabil i mai puin glacial prin prisma aplicaiilor ei. Aceast lucrare se dorete a fi de asemeni o dovad a modului n care putem folosi tehnologia pentru a da un plus de valoare relaiilor interpersonale i a optimiza n acest mod i procesele business. n domeniul afacerilor, fiecare lucru fcut n exces, orict de mic ar prea la o prim analiz, poate fi vital. Acel lucru mrunt poate cpta o importan sporit n coroborare cu celelalte elemente i astfel s fac diferena ntre locul I i II. De cele mai multe ori, a fi locul II este pur i simplu insuficient. Lucrarea de fa vine n sprijinul acestei idei prin combinarea i extinderea conceptelor de CRM (Customer Relationship Management) i CMS (Content Management System) i a modului n care o astfel de abordare tehnologic a relaiei cu partenerii de afaceri poate mbuntii legturile cu acetia i, implicit, volumul vnzrilor. Dezvoltarea continu a internetului i creterea masiv a numrului de persoane care interaconeaz online a determinat un interes masiv n acest domeniu n ultimii ani. Privit prin prisma potenialului imens de expunere comercial a unui produs sau companii sau din punctul de vedere al ratei de cretere, circulaie i mprosptare a informaiei, web-ul reprezint n acest moment locul ideal de publicare a diverselor tipuri de informaii disponibile.

Scopul aplicaiei prezentate n aceast lucrare este dezvoltarea unei platforme exhaustive de publicare a unor resurse simple. Prin utilizarea unor paradigme de design al interfeei, se intenioneaz oferirea unei platforme utilizabile de ctre oricine, indiferent de cunotinele web dobndite, o platform cu un foarte scurt timp de nvare i un cost redus de mentenan.

1.1 Definirea problemei

Accesul la informaie precum i controlul acesteia este mai important ca oricnd, i cu att mai mult n lumea afacerilor unde situaiile de criz se succed mult mai rapid i de cele mai multe ori cu repercursiuni mult mai dure. Prin urmare apare necesitatea existenei unei aplicaii care s satisfac necesitile unei companii (tratarea i fidelizarea clienilor, uurina folosirii i nvrii, managementul stocurilor, chitanelor, facturilor etc.) ntr-un cadru securizat i de maxim ncredere.

1.2 Scopul proiectului

Acest proiect dorete a fi o soluie viabil la problema firmelor de a i pstra clienii n portofoliu, fidelizndu-i, de a obine ali clieni prin recomandrile celor deja existeni, i, n acelai timp, de a avea o imagine clar, de asamblu, a tendinei pieii, mai exact a ceea ce i dorete un client n general, i, nu n ultimul rnd, a modului n care angajaii se ocup de problemele clienilor i insufl filosofia firmei prin aciunile lor. O asemenea aplicaie dorete s uureze, i, mai important, s mbunteasc munca personalului de marketing prin standardele care le-ar impune. n acelai timp ar restrnge procentul de erori umane la un minimum acceptabil prin nepermiterea abaterii de la un set de reguli simple, uor de urmat i uor de verificat. Astfel, personalul ar ti n permanen ce anume trebuie s ntrebe i ce anume s i spun clientului, indiferent de experiena sa anterioar. Procedurile de verificare a randamentului angajailor permit supervizorilor s fie n permanent alert privitor la calitatea sprijinului acordat de ctre acetia clienilor. Delegarea de sarcinii se face astfel i cu ntiinarea unei/unor persoane de control, astfel c eventualele erori de comunicare ntre departamentul de marketing i clieni s fie prentmpinate cu succes, sau, n caz de conflict, abordate cu profesionalism de ctre personalul avizat n luarea unor astfel de decizii. 4

Capitolul 2

Tehnologii i nouti n domeniu

2.1 World-Wide Web n ziua de azi

Foarte des ntlnit pe Internet, acronimul www vine de la World Wide Web. Iniial, www (sau web) a fost conceput pentru a permite fizicienilor s comunice rezultatele experimentelor desfurate de fiecare. n 1989 o echip de cercettori de la Laboratorul European de Fizic a Particulelor din Elveia a elaborate primele standarde pentru mediul World Wide Web. Unul dintre cele mai importante elemente a fost hiper-legtura, o bucat dintr-un document online care ghideaz utilizatorul, n momentul utilizrii ei, ctre un alt document online. Un alt moment important n istoria Internetului s-a desfurat n 1992, cnd programatorii de la National Center of Supercomputing (NCSA) de la Universitatea din Illinois au realizat browserul Mosaic, un program care arta nu doar textul unui document web, dar i elementele grafice incluse n acesta. Astzi exist o mare diversitate de browsere pentru aproape toate computerele utilizate: Internet Explorer, Mozilla, Opera, Netscape, Amaya, Lynx, Safari. Hipertextul i elementele multimedia sunt cele mai importante dou aspecte ale Internetului. Un alt avantaj este dat de faptul c www este construit pe baza unor standarde publice care permit accesibilitatea vizualizrii paginilor pe aproape orice computer care are o conexiune la Internet i un browser. Pentru a accesa informaia, tot ceea ce trebuie fcut este un click pe o hiper-legtur. Este att de simplu. Postarea informaiilor pe Internet prezint un set impresionant de avantaje. n primul rnd aceast metod de publicare este mult mai ieftin dect metodele alternative. Mai mult dect att, un document web poate fi citit i actualizat la orice moment.

World Wide Web ofer o gam larg de posibiliti de conectare la Internet. Pe scurt, oricine folosete un computer se poate conecta la Internet. Informaia este transmis n format ASCII, far un mecanism intern de codificare n cod main. Necesarul tehnic al clientului este minimal, de fapt Internetul nsui nu are niciun standard legat de cum ar trebui un browser s funcioneze i astfel s-au dezvoltat tipuri multiple de browsere pentru mai multe Sisteme de Operare. Este greu s ne imaginm astzi c Internetul a fost conceput pentru a trimite pagini simple, text, cu poze i linkuri incluse n ele. Povestea ultimilor 20 de ani ai programrii Internetului este cea a unui efort colosal de a oferi sofisticare i complexitate utilizatorului, fr a contrazice regulile www care necesit o simplitate extrem de realizare a paginilor web. Utilizatorul ateapt o experien pe Internet ct mai apropiat de aceea a folosirii aplicaiilor desktop, dar un astfel de nivel de complexitate nu a fost uor de implementat n mediul web, dat fiind complexitatea sa minimal. Web-ul face un singur lucru: ofer informaii. Dac avem informaii despre ceva anume, putem s le mprtim lumii prin crearea unui website. Pe parcursul dezvoltrii site-ului, putem da peste dou tipuri de probleme: site-ul nostru are att de mult informaie nct vizitatorii nu pot gsi rapid ceea ce caut i vizitatorii vor s ofere informaii; Ambele probleme pot fi soluionate prin crearea unei baze de date pe un website. Bazele de date se regsesc peste tot n www. Google, Yahoo! i eBay sunt baze de date. Amazon.com este o baz de date uria cu milioane de cri, CD-uri i alte produse.

2.1.1 HTML
HTML (HyperText Markup Language) este limbajul folosit de aplicaiile de tip browser Internet pentru a recunoate i a prezenta structura unei pagini web. Realizarea unui pagini web presupune cunoaterea limbajului HTML. Acesta este un limbaj de marcare, introdus de Tim Berners-Lee. Numeroase tutoriale de HTML se gsesc pe Internet, cele mai utile fiind ns cele bazate pe exemple concrete, coninnd articole despre frames (cadre), metatag-uri, inserarea de imagini i de fiiere sonore. n plus, exist i articole despre tabele, care joac un rol important n pagina web: tabele simple (tag-urile table, td, td, th) precum i tabele complexe (atributele colspan, rowspan .a.m.d.). Etapa de proiectare a unui site web, promovarea acestuia, upload-ul, webhosting-ul sunt de asemeni tratate n numeroase articole de pe blogosfer. 6

2.1.2 CSS
CSS (Cascading Style Sheets) este limbajul de programare folosit pentru descrierea prezentrii unui document structurat. Un document structurat este acel document ale crui seciuni sunt definite clar i sunt categorizate. Un program de genul CSS poate prezenta un document n diverse stiluri deoarece coninutul a fost categorizat. CSS este utilizat pentru stilizarea documentelor scrise n limbaje precum HTML, XHTML, SVG, XUL i numeroase altele. Unul dintre cele mai atractive aspecte ale documentelor structurate este acela dat de posibilitatea reutilizrii coninutului n diverse contexte i prezentrii acestuia n diverse metode. Diverse stiluri pot fi ataate structurii logice pentru a produce prezentri diferite. Pentru a fi prezentat coninutul din documentele structurate trebuie aplicat un set de reguli de stil descriind, spre exemplu, culori, fonturi i moduri de aezare n pagin. O colecie de reguli din acestea de stil este numit foaie de stil. Foile de stil n forma documentelor scrise au o lung istorie, fiind folosite de editori i de tipografi pentru a asigura consistena prezentrii, a scrierii corecte a cuvintelor i a punctuaiei. n publicaiile electronice foile de stil sunt folosite mai mult pentru vizualizarea prezentrii i mai puin pentru celelalte aplicaii ale lor. Exist trei elemente de baz ale unei pagini web dinamice moderne: coninutul este administrat prin utilizarea limbajului HTML, modul de prezentare a acestuia i revine CSS-ului, JavaScript rmnnd s se ocupe de comportarea dinamic i de interaciunea paginii web cu utilizatorul. Prima specificaie CSS, CSS1 a fost recomandat n 1996 de W3C, i includea proprieti pentru controlul elementelor tipografice, precum cea a fonturilor, alinierii textului, spaierea, marginile i a formatarea listelor; permitea de asemeni designer-ului s specifice dimensiunea cutiilor de tip block i s ncadreze cutiile cu margini. Totui, cnd venea vorba de aezarea n pagin i de design, CSS1 nu avea prea multe de oferit, putnd specifica culorile de fundal i cele utilizate pentru text, precum i pozele de fundal. Permitea de asemeni stabilirea de cutii plutitoare la stnga i la dreapta i poziionarea de text n jurul acestora. CSS2 a aprut n 1998 i coninea o mulime de opiuni mult dorite de ceva timp de designeri. Cutiile puteau fi fcute s se comporte ca celulele tabelelor din HTML, sau puteau fi poziionate n diverse moduri, selectori mai puternici puteau fi utilizai, stilurile puteau fi importate n alte stiluri, regulile de stil puteau fi specificate pe anumite tipuri de elemente media i multe alte opiuni de acest gen. S-au fcut mari optimizri i n direcia printrii i generrii de coninut pornind de la o foaie de stil. 7

Cum s-a observat mai trziu, unele pri ale CSS2 erau foarte greu de implementat, iar W3C a decis s revizuiasc specificaiile i s le adapteze la situaiile concrete din realitate. Majoritatea opiunilor speciale pentru elementele de tip media au fost anulate. Crearea coninutului generat a fost restrns la pseudoelementele :before i :after i s-au pus de asemenea restricii privitoare la cum poate fi prezentat coninutul generat. Sintaxa CSS nu este rigid: spaiile albe pot fi de obicei adugate far repercursiuni ntre elementele de sintax, iar ntreruperile de linie nu au valoare semantic. CSS este insensibil la modul n care scriem, cu litere mici sau mari. Totui, unele lucruri nu depind de acesta i pot sau nu fi tratate diferit n funcie de cum sunt scrise, de limbajul de marcare i de sistemul de operare folosit. Numele tipurilor elementelor, spre exemplu, sunt insensibile la modul de scriere n limbajul HTML, dar sensibile pentru XML(incluznd i XHTML servit ca XML). Numele de fonturi, cu excepia cuvintelor generice folosite n CSS, pot fi cazuri sensibile pe unele sisteme de operare. Pentru clarificarea unor elemente de baz de nomenclatur, n figura de mai jos este prezentat un exemplu simplu de descriere de stil de tip CSS:

Figura 1. Descrierea unui stil n CSS

Limbajul CSS este astfel deosebit de util pentru a oferi claritate i consisten prezentrii unei pagini web. Din pcate nc exist incompatibiliti ntre modul de interpretare a stilurilor CSS de ctre diverse browsere Internet, aa numitele CSS bugs. Aceasta se traduce direct n costuri suplimentare aduse programrii CSS, fiind necesare testri cross-browsing, adic testarea stilurilor pe mai multe tipuri de browsere, i, din pcate, de cele mai multe ori crearea unui stil special pentru fiecare browser care ar putea accesa respectivul document. La ora actual exist o concuren acerb ntre motorul de rendare Mozilla Gecko, WebKit folosit n browserul Safari de la Apple, motorul similar KHTML utilizat n browserul KDE Konqueror, Presto Layout Engine de la Opera, fiecare dintre ele lider n diverse aspecte legate de CSS. Din 2007, motorul Trident de la IE rmne cel mai slab la rendarea css-urilor, lucru judecat de W3C. Anul acest Internet Explorer 8 a fixat multe din neajunsurile acestea i rendeaz CSS2.1.

Aproape c trece i testul ACID2, unde celelalte browsere, Mozilla Firefox, Opera 9 sau safari se comport mult mai bine.

2.1.3 Web 2.0

Articolul lui Tim O'Reilly What Is Web 2.0 - Design Patterns and Business Models for the Next Generation of Software, aprut n septembrie 2005, este unul din articolele de baz, ce fundamenteaz conceptele Web 2.0. Tim O'Reilly explic faptul c termenul de Web 2.0 a aprut n 2004, n timpul unui brainstorming ntre O'Reilly Media i MediaLive International, n pregtirea organizrii unei conferine legate de Web. n cutarea numelui, organizatorii au remarcat c n ciuda colapsului .com, o serie de aplicaii web noi, apar cu regularitate, caracterizate prin colaborarea utilizatorilor la crearea coninutului. Tabelul de mai jos, prezentat n articol i discutat la brainstorming, conine perechi de aplicaii similare, cu implementri caracteristice web1.0 i web 2.0:

Web 1.0
DoubleClick Ofoto Akamai mp3.com enciclipedii dedicate site-uri personale clasificare dup calitatea domeniului publicitate la numrul de afiari screen scraping coninut prin publicare content management systems arhviare tip director stickiness

Web 2.0
Google AdSense Flickr BitTorrent Napster Wikipedia blogging Optimizare motoare de cutare publicitate pe aciune (click) web services coninut prin participare wikis arhivare tip etichete syndication

Figura 2. Tabel celebru privind evoluia internetului

Web 2.0 poate fi caracterizat prin: include o palet foarte larg de aplicaii i servicii care folosesc Web-ul ca platform unitar i organizat de comunicare; este construit pe baza unei arhitecturi care ncurajeaz participarea activ a utilizatorilor; permite interaciunea facil ntre utilizatorii care au aceleai interese; ofer utilizatorilor posibilitatea de a produce coninut, de a-l partaja cu alii, deci o mai puternic interactivitate;

 o experien mult mai apropiat de aplicaiile desktop, cu interfee grafice intuitive, plcute, programabile i, mai ales, transparente; faciliteaz accesul public la baze de date, prin API-uri; are abilitatea de a conecta ntre ele diverse aplicaii sau servicii i de a agrega date din diverse surse - RSS, bloguri; vorbete despre: socializarea informaiei - un concept despre aplicaii i oameni; apariia instrumentelor colaborative de genul wiki-urilor, a platformelor de socializare ca MySpace, Hi5, LinkedIn sau Second Life, a blogurilor, a structurilor de comunicare de date i documente, a coleciilor de bookmarkuri (ca del.icio.us sau Digg), de clipuri video (YouTube, Metacafe, DailyMotion) sau de imagini (Flickr, Picassa) etc.; o sindicalizare - RSS i structuri de taguri: eliminarea clasificrilor tip arbore i aplicarea de etichete astfel nct un anumit lucru nu mai e strict descendent dintr-un altul ci poate face parte din mai multe categorii; creterea uzabilitii mbuntirea experienei utilizatorilor, coninutului i distribuia acestuia (coninut creat de utilizatori i distribuit liber; folosete puterea comunitilor de internaui; indic o schimbare de paradigm n ceea ce privete Web-ul. Termenii caracteristici Web 2.0 apar n imaginea de mai jos Web2.0 extended mindcloudmap, publicata de Markus Angermeier la flickr; notele pe imagine conduc la diferite aplicatii.

Figura 3. Tag cloud: Universul Web 2.0 - cuvinte cheie

Denumirea de Web 2.0 reprezint a doua etap n dezvoltarea www i nglobeaz utilitarele i serviciile lui. Multe din tehnologiile i conceptele dezvoltate n

10

trecutul apropiat le putem include aici, de exemplu: bloguri, podcast, RSS, wiki, sisteme de bookmark colaborativ, LoL (publicate de ctre muli pentru muli), web APIs, servicii web online, Ajax, Ruby on Rails, etc. Imaginea de mai jos ofer o perspectiv asupra noilor tehnologii i momentul apariiei a fost publicat n septembrie 2006 de Jrgen Schiller Garca n nsemnarea Web 2.0 Buzz Time Bar din blogul Scill web2.0 repository; sunt multe referiri la imagine n articole despre Web 2.0.

Figura 4. Distribuia Web 2.0 n viaa de zi cu zi

Despre Web 2.0, partizanii momentului tehnologic actual spun c: este mai degrab o noua viziune asupra Web-ului dect o tehnologie; este mai mult o atitudine dect o tehnologie; este un fenomen cultural, mai mult dect unul tehnic; este un termen de marketing; este un nou val de tehnologie avansat; este un amalgam logic de tendine; un Internet la ndemna oricui. Dac totui ar trebui s facem o descriere a Web 2.0, atunci aceasta se regsete n principalele sale trsturi latura social, aspectul interactiv si ingredientele sale de baz: coninutul postat de utilizator, aplicaia n sine i indexarea informaiilor.

11

Printre marii jucatori care au implementat aceast tehnologie se numar: Microsoft; Amazon; Yahoo: aplicaia de webmail Yahoo!MailBeta, marcare social del.icio.us cumparat n decembrie 2005, partajare fotografii Flickr cumprat n martie 2005, portal personalizat my.yahoo.com, Yahoo Instant Search, .a.m.d.; Google care, la nceputul anului 2005, prin folosirea Ajax-ului, a introdus pe scar larg versiunea 2.0 a Web-ului n aplicaiile sale: GMail, Google Calendar, Google Google Docs & Spreadsheets lansat la 10 octombrie 2006, dupa ce n 9 martie, Writely fusese cumprat, Google Reader, Google Scholar, Google Suggest depit ns n performane de SurfWax LookAhead, Google Book Search, Blogger, YouTube cumprat n octombrie 2006, Google Maps, etc.

12

2.2 Programare server side

2.2.1 Hypertext Preprocessor (PHP)
PHP este un limbaj de programare ce ofer dinamism paginilor web. Este unul din cele mai importante limbaje de programare web open-source i server-side. Numele PHP provine din limba englez i este un acronim recursiv: Php Hypertext Preprocessor. Exemple faimoase de aplicaii web care utilizeaz acest limbaj sunt Wordpress, Blogger (blogging i pagini personale), PhpBB (forumuri de discuii), PhpNuke, Joomla (Content Management Systems), Phpld, ESyndicat (directoare web), MediaWiki (engine pentru Wikipedia). Creterea masiv a numrului programatorilor PHP a condus la includerea n mediilor de dezvoltare ale giganilor internetului precum Yahoo, Google, Microsoft, Adobe, Amazon etc. a unor API-uri special create pentru a interaciona cu PHP. Folosirea PHP poate fi vzut ca o alternativ gratuit la utilizarea unor limbaje comerciale precum ASP de la Microsoft, ColdFusion de la Macromedia, sau chiar JSP de la Sun Microsystems. PHP a fost nceput n 1994 ca o extensie a limbajului server-side Perl, i apoi de o serie de CGI-uri compilate de ctre Rasmus Lerdorf. Pe 18 iunie 2008 a fost lansat ultima versiune stabil, PHP 5.2.10. ncepnd cu versiunea 5.2 datorit includerii modulului Zend Engine II, acest limbaj de programare s-a bucurat de un suport puternic pentru OOP, zon neexplorat pn n acel moment i care era considerat veriga lipsa a PHP. Popularitatea de care se bucur acest limbaj de programare se datoreaz urmtoarelor caracteristici: familiaritatea sintaxa limbajului este foarte uoar combinnd sintaxele unora din cele mai populare limbaje, Perl i C; simplitatea sintaxa limbajului este destul de liber; nu este nevoie de includere de biblioteci sau de directive de compilare, codul PHP inclus ntr-un document executndu-se ntre marcajele speciale; eficiena folosete mecanisme de alocare dinamic a resurselor, un lucru extrem de important n mediile multi-utilizator, aa cum este web-ul; securitatea pune la dispoziia programatorului un set flexibil i eficient de msuri de siguran;

13

 flexibilitatea fiind aprut din necesitatea dezvoltrii web-ului, PHP a fost modularizat pentru a ine pasul cu dezvoltarea diferitelor tehnologii; nefiind legat de un anumit server web, PHP-ul a fost integrat pentru numeroasele servere web existente: Apache, IIS, Zeus etc.; gratuitatea este probabil cea mai important caracteristic a PHP-ului; dezvoltarea PHP-ului sub licen open-source a determinat o adaptare rapid la nevoile web-ului, eficientizarea i securizarea codului i rspndirea de proporii.

2.2.2 SQL
Structured Query Language, sau prescurtat, SQL, are o istorie care a nceput n laboratoarele IBM din San Jose, unde limbajul a fost dezvoltat n ultimii ani ai deceniului opt. SQL este un limbaj neprocedural. SQL este ceea ce face funcional un sistem de gestiune a bazelor de date relaionale. Pentru majoritatea sistemelor de administrare a bazelor de date relaionale, acest limbaj este SQL. Structured Query Language (SQL limbaj structurat de interogare) este limbajul standard de facto folosit pentru manipularea i regsirea datelor din aceste baze de date relaionale. Utiliznd SQL, un programator sau un administrator de baze de date poate face urmatoarele lucruri: s modifice structura unei baze de date; s schimbe valorile de configurare pentru securitatea sistemului; modifice drepturi utilizatorilor asupra bazelor de date sau asupra tabelelor; interogheze o baz de date asupra unor informaii actualizeze coninutul unei baze de date Cel mai bun exemplu pe care l tim despre cum arat o baz de date este un document Microsoft Excel cu rndurile i coloanele aferente. La fel ca i n Excel se pot face calcule, sortri, adunri i chiar mai mult... MySQL este cel mai popular sistem de management pentru baze de date relaionale deoarece este open-source. ntr-o baz de date relaional datele sunt stocate n mai multe tabele separate, fiind astfel mbuntit viteza i flexibilitatea. Tabelele pot fi legate ntre ele prin relaii definite de proiectantul bazei de date, fiind astfel posibile combinri la cerere de date din mai multe tabele. SQL Pentru a ne putea face o baz de date trebuie ca serverul MySQL s fie pornit. n continuare va trebui s folosim o aplicaie cu ajutorul creia s comunicm cu serverul. Aplicaia se numeste mysql.exe i se gsete n c:\mysql\bin\. Pentru a rula, din prompul so scriem: c:\mysql\bin\mysql.exe -p -u root iar cnd ni se cere parola apsm enter (sau scriem parola dac am introdus la instalare vreuna).

14

Dac serverul nu este pornit vom primi mesajul de eroare Can't connect to MySQL server on localhost. n cazul de fa am optat pentru utilizarea aplicaiei Easy PHP, care administrez fr intervenia noastr serverul de MySQL. Dei MySQL are suport pentru diacritice i setul de caractere 8859-2, este preferabil s nu folosim diacritice n numele bazelor de date, a tabelelor sau a cmpurilor. De asemeni, nu putem folosi ca nume de tabel sau de cmp cuvinte rezervate (nume de funcii, tipuri de caractere din MySQL precum create, drop sau column). Se pot folosi nume de tabele care conin spaii dar n practic trebuie s ncadrai numele ntre back-ticks ` (semul pe care l localizm pe tasta aflat imediat sub escape i nainte de 1). Exemplu:
CREATE TABLE `tabel al carui nume are spatii` (`camp 1`, TEXT); SHOW COLUMNS FROM `tabel al carui nume are spatii`;

Semnul * este definit n MySQL ca nsemnnd tot/toate. Semnul % este folosit n interogrile MySQL dac vrem s gsim cuvntul oriunde n cadrul textului. Mai exact: %cuvant_cautat - dac vrem s afieze toate cuvintele care se termin n 'cuvntul_cutat' (pot fi i cteva caractere); cuvnt_cutat% - afieaz toate cuvintele care ncep cu 'cuvntul_cutat'; %cuvant_cautat% - afieaz toate cuvintele care conin 'cuvntul_cutat' oriunde n text. Putem afla cte nregistrri sunt pentru un criteriu de selecie cu ajutorul lui count(). Putem afla astfel cte nregistrri sunt n total n tabel sau cte nregistrri sunt n tabel al cror cmp este cel cutat... Cu ajutorul instruciunii group by putem grupa rezultatele astfel nct s nu vedem duplicatele. Pentru a limita numrul de rezultate folosim instruciunea limit. Dac avem 10.000 de nregistrri i nu dorim s vedem dect primele 3, folosim limit 0,3 (adic de la prima nergistrare afieaz 3 nregistrri) sau limit 10,5 (afieaz ncepnd de la nregistrarea 10 nc 5 nregistrri). Pentru tergerea nregistrrilor dintr-un tabel se folosete comanda delete. Pentru tergerea unui tabel sau a unei baze de date comanda este drop. Comanda update se foloeste cnd vrem s modificm coninutul unei nregistrri fr a o terge. Dac dorim s schimbm structura unui tabel existent sau s adugm alte coloane folosim comanda alter table. Indeci cel mai folosit tip de index este id. Id-ul este un numr unic de identificare pentru un element distinct (un rnd) al unui tabel. Un exemplu de id din viaa real este numerotarea cd-urilor. Cnd avei un cd nou l numerotai i 15

l punei n raft la sfrit, iar n catalog putei s l punei sortat dupa titlu sau dup numrul de ordine. La fel i ntr-o baz de date, putei crea un cmp care s introduc automat un numr pentru fiecare rnd nou adugat n baza de date i la afiare putei s l folosii (de exemplu la vizualizarea ultimilor 10 vizitatori folosii id-ul). n continuare vom prezenta comenzile utilizate pentru crearea unui index. S presupunem c avem o baz de date numit list cu un cmp caset i adugm cmpul id_casete comanda este urmtoarea:
ALTER TABLE `caseta` ALTER TABLE `caseta` UNSIGNED ALTER TABLE `caseta` ALTER TABLE `caseta` UNSIGNED ADD `id_caseta` INT; CHANGE `id_caseta` `id_caseta` INT(11) NOT NULL; ADD PRIMARY KEY (id_caseta); CHANGE `id_caseta` `id_caseta` INT(11) DEFAULT "0" NOT NULL AUTO_INCREMENT;

Din acest moment, orice caset nou introdus va avea automat un numr de ordine. Este posibil ca toat niruirea de comenzi de mai sus s se poata face printr-o singur linie de cod, dar este mai sigur s facei cte o modificare n parte dect toate odat, pentru a detecta eventualele erori. Este bine s creai un id la nceputul tabelului, cnd nu avei ntrri n baza de date, pentru a face incrementarea automat, altfel e posibil s v dea erori. Cu ajutorul id-ului putei afia de exemplu noutile, cu o comand de genul - afieaz ultimele 10 intrri sortate dup id tiind c ntotdeauna ultima intrare are numarul cel mai mare... MySQL stocheaz fizic datele unui tabel ntr-un fiier pe hard disc i cu ct tabelul este mai mare, cu att mrimea acestui fiier va crete. Versiunea 3.22 a MySQL are o limit de 4 GB pentru mrimea unui tabel. n versiunile superioare aceast limit este extins pn la 8 milioane TB pentru tipul de tabel MyISAM. Cu toate acestea, sistemele de operare pot avea propriile limitri ale mrimii fiierelor. Mrimea impicit a tabelelor MySQL este de aproximativ 4 GB. Putei verifica mrimea maxim pentru un tabel cu ajutorul comenzilor show table status sau myisamchk -dv table_name. Pe platforma Windows va trebui s folosim sistemul de fiiere NTFS dac dorim s avem tabele mai mari de 4 GB.

2.2.3 Apache
Apache este un server HTTP flexibil, care implementeaz ultimele protocoale, fiind foarte configurabil, extensibil cu module strine i care ofer codul surs complet. Apache este gratuit, avnd o licen nerestrictiv. Ruleaz pe sisteme Windows, Netware, OS/2 i aproape toate versiunile de UNIX. ncurajeaz utilizatorii pentru a veni cu idei noi, reportri de bug-uri i ofer pachete pentru mbuntiri.

16

Serverul HTTP Apache poate fi descrcat gratuit de pe Internet de la adresa http://httpd.apache.org, unde se mai pot gsi documentaii i toate informaiile necesare utilizrii i configurrii. Principalele diferene ntre vesiunile Apache pentru cele mai des folosite sisteme de operare, Windows i Unix, sunt: deoarece Apache pentru Windows este de tip multithread, nu folosete un proces separat pentru fiecare cerere, aa cum face Apache sub Unix. n mod curent, sunt doar dou procese Apache care ruleaz, un proces printe i un copil care se ocup de cereri. n interiorul procesului copil, fiecare cerere este controlat de un thread separat. directivele care accept ca argument nume de fiier trebuie s foloseasc numele de fiier din Windows. Dar, deoarece Apache folosete intern nume de tip Unix, trebuie folosit slash n loc de backslash; Apache pentru Windows poate ncrca modulele la runtime, fr recompilarea serverului. Dac Apache este compilat manual, va instala unele module opionale n directorul modules. Pentru activarea acestora trebuie folosit directive LoadModule. Apache pentru Windows versiunea 1.3 este implementat cu apeluri sincrone. Aceasta este o problem pentru autorii de scripturi CGI, care nu vor vedea rezultatele de tip unbuffered trimise imediat la browser; Apache poate ncrca extensiile ISAPI, ca cele folosite de Microsoft IIS. Apache nu poate ncrca filtrele ISAPI; La rularea scripturilor CGI, metoda folosit de Apache pentru a gsi interpretorul pentru scripturi este configurabil folosind directive ScriptInterpreterSource. Dac este instalat pe sistemul de operare Windows, Apache-ul este rulat n mod normal ca un serviciu pe Windows NT, Windows 2000, Windows XP sau ca o consol de aplicaie pe Windows 98. n sistemele de operare Microsoft Windows exist dou posibiliti n care poate fi rulat Apache ori ca un serviciu: aceasta este cea mai bun opiune dac se dorete ca Apache s porneasc automat la pornirea Windows ori dintr-o fereastr de consol: nchiderea acestei ferestre va duce la nchiderea Apache. Pentru a porni Apache ca un serviciu, trebuie mai nti instalat ca un serviciu. Aceasta se face prin selectarea la instalare a opiunii Install as Service for All Users. Astfel, serviciul va aprea n lista de servicii din Windows. Dup pornirea

17

serviciului Apache, acesta va aprea n lista de procese active, cu denumirea de apache.exe. n Unix programul httpd este executat ca un daemon care se execut continuu n background i se ocup de cereri. Dac portul specificat n fiierul de configurare este lsat pe default, adic pe portul 80, atunci este necesar s avem privilegii de root pentru a putea porni Apache. Odat pornit, serverul va executa cteva activiti preliminare i apoi va lansa n execuie procese fii care practic ascult orice cerere venit de la clieni. Primul lucru pe care l face httpd cnd este invocat este s citeasc fiierul de configurare httpd.conf. Ca o alternativ la invocarea httpd, este pus la dispoziia administratorilor scriptul shell apachectl, controlnd procesul daemon cu comenzi simple ca apachectl start sau apachectl stop. n mod implicit, Apache folosete portul 80 (dac nu s-au schimbat directivele Port, Listen sau BindAddress din fiierele de configurare). Pentru conectarea la server i accesarea paginii de start se deschide urmtorul URL ntr-un browser de Internet: http://localhost/. n cazul n care serverul este instalat i configurat, va fi afiat o pagin de start i un link ctre manualul cu documentaii Apache. Dac exist o eroare, va fi creat o nregistrare n fiierul error.log din directorul logs. Deoarece Apache nu poate folosi acelai port cu o alt aplicaie TCP/IP, este nevoie s fie oprite sau dezinstalate unele servicii (anumite servere web, anumite aplicaii firewall). Configurarea Apache se face prin modificarea directivelor din fiierul httpd.conf. Pe lng acest fiier mai exist alte dou fiiere, access.conf i srm.conf, dar acestea sunt mai vechi i nu mai sunt folosite de majoritatea administratorilor. Apache are trei modaliti de a asigura c cererea pentru o anumit resurs va fi ndeplinit. Acestea se numesc Authorization, Authentication i Access control. Authentication este procesul prin care se verific faptul c cineva este chiar cine pretinde a fi. Aceasta implic de obicei un nume utilizator i o parol asociat acestuia, dar poate include i alte metode. Authorization nseamn c, odat identificat persoana, se verific dreptul acesteia de a accesa resursa. Acesta se acord dac persoana aparine unui grup sau dac are un nivel de autorizare corespunztor. Access control este un mod mai general de a vorbi despre acces controlat la o resurs web. Accesul poate fi permis sau nu n baza unor criterii variate, cum ar fi adresa clientului sau browser-ul folosit. Autentificarea de baz este cea mai simpl metod de autentificare i pentru mult timp a fost i cea mai comun. Recent i alte metode de autentificare au nceput s fie folosite n mod curent. Cnd o resurs a fost protejat folosind autentificarea de baz, Apache trimite un header de cerere de autentificare 401

18

cu rspunsul la cerere pentru a anuna clientul c este nevoie de autentificri pentru a folosi corespunztor resursa respectiv. Cnd primete un header de rspuns 401, browser-ul clientului, dac suport autentificarea de baz, va cere utilizatorului s introduc un nume utilizator i o parol care vor fi trimise serverului. Dac este folosit un browser grafic va aprea o fereastr n care se va introduce nume utilizator i parola, care vor fi trimise napoi la server. Dac nume utilizator este n lista permis i parola este corect, resursa va fi returnat clientului. Fiecare cerere va fi tratat la fel, chiar dac vine de la acelai client. Pentru fiecare resurs cerut va trebui s introducei datele de autentificare pentru a o primi. Din fericire, browserul are grij de detalii n acest caz, astfel nct va trebui s introducei datele o singur dat pe sesiune. O dat cu rspunsul 401 vor fi trimise napoi clientului i alte informaii. n particular, un nume care este asociat cu zona protejat a site-ului web. Acesta se numete realm. Browser-ul clientului preia numele de utilizator i parola introduce i le pstreaz mpreun cu realm-ul, astfel nct atunci cnd sunt cerute alte resurse aceleai informaii vor putea fi trimise fr a mai fi nevoie ca utilizatorul s le introduc iari. Exist trei pai de configurare care trebuie parcuri pentru a proteja o resurs folosind autentificarea de baz: se creaz un fiier de parole; se seteaz configuraia pentru a folosi acest fiier de parole; opional, se creaz un fiier de grup. Dei parola este pstrat pe server n format criptat, ea este transmis de la client la server necodat. Astfel, oricine poate intercepta numele de utilizator i parola cnd sunt transmise. n plus, numele de utilizator i parola sunt transmise cu fiecare cerere, nu doar atunci cn utilizatorul le introduce prima dat. Autentificarea digest ofer o metod alternativ pentru protejarea coninutului web. Totui, i ea are cteva bug-uri. Autentificarea digest este implementat prin modulul mod_auth_digest. Exist un modul mai vechi mod_digest dar probabil c nu va funciona pe browserele mai noi. Folosind autentificarea digest, parola nu este transmis niciodat necriptat prin reea, ci este transmis ntotdeauna ca un digest md5 al parolei utilizatorului. Dei autentificarea digest are marele avantaj c nu trimite parola necriptat prin reea, nu este suportat de majoritatea browserelor folosite astzi i nu ar trebui folosit pe un site pe care nu putei controla browserele utilizatorilor. n

19

particular autentificarea digest este suportat de o versiune de browser Internet Explorer mai mare de 5.0. Dac avem un coninut care trebuie asigurat foarte bine, vom folosi ssl. Autentificarea de baz i autentificarea digest au ambele acelai mare defect: folosesc fiiere text pentru memorarea informaiilor de autentificare. Problema este dat de faptul c o cutare ntr-un fiier text este foarte greoaie. Autentificarea trebuie fcut de fiecare dat cnd este cerut un anumit coninut. Apache trebuie s deschid fiierele text de parole i s caute linie cu linie pn gsete utilizatorul care ncearc s se logheze i s verifice parola acestuia. Alternativa o reprezint o varietate de baze de date. Bazele de date sunt optimizate pentru cutarea unei anumite informaii ntr-un set mare de date. Sunt mai multe module disponibile pentru Apache pentru autentificare folosind o varietate de baze de date. Mod_auth_db i mod_auth_dbm sunt module care pstreaz parolele n fiiere DB sau DBM. Pentru aplicaia noastr, am folosit utilitarul Easy PHP sub Windows 7 RC1, care se ocup de administrarea serverului Apache fr a fi nevoie de implicarea direct a administratorului.

20

2.3 Programare client side

2.3.1 Javascript
JavaScript este un limbaj de scripting dezvoltat la origine de Netscape, permind scrierea de secvene de program care se execut la apariia unui eveniment utilizator. Vom prezenta n continuare fundamentele JavaScript i, mult mai important, modaliti de valorificare i integrare n propriile pagini web a tehnologiei JavaScript. JavaScript nu este Java! Trebuie fcut distincia ntre limbajul de programare Java i limbajul de scripting JavaScript. Spre deosebire de JavaScript, Java este un limbaj de programare considerat "de nivel nalt" (foarte apropiat de gndirea utilizatorului i mai puin de arhitectura calculatorului) care permite scrierea de aplicaii de aproape orice tip i grad de complexitate. Pentru rularea programelor scrise n limbajul JavaScript avem n primul rnd nevoie de un browser care suport JavaScript de exemplu Netscape Navigator (ncepnd cu versiunea 2.0) sau Microsoft Internet Explorer (MS. I.E. - ncepnd cu versiunea 3.0). Din moment ce aceste browsere sunt extrem de larg rspndite, muli utilizatori (peste 95%) au posibilitatea de a rula fr probleme programele JavaScript. Pentru a utiliza n paginile proprii evenimente tratabile prin JavaScript avem bineneles nevoie i de cunoterea - cel puin la nivel mediu - att a limbajului HTML, ct i a limbajului de scripting JavaScript Codul JavaScript poate fi introdus direct n pagina HTML. Pentru a vedea cum functioneaza JavaScript, s lum n considerare urmtorul exemplu simplu:
< h tm l> < h ea d> <t i t l e> P ag in a H TM L c u J a v aS c ri pt < / t it l e > < / he ad > < b od y> <p > H e ll o u se r !< /p > < s cr ip t l a n g u a g e = " J av aS c ri p t " > do c u m en t .w ri t e( "A c es t a e s te Ja va Sc r ip t ! " ) ; < / sc ri p t > < p >D in n o u t e x t s i co d H TM L . < p > < / bo dy > < / ht ml >

La prima vedere aceast secven de cod arat ca un fiier HTML normal, singura noutate o constituie blocul <script> ... </script>: 21

< s cr ip t l a n g u a g e = " J av aS c ri p t " > do c u m en t .w ri t e( "A c es t a e s te Ja va Sc r ip t ! " ) < / sc ri p t >

Acesta este JavaScript-ul nostru! Pentru a observa modul de funcionare a scriptului vom salva codul HTML de mai sus ca i fiier normal HTML lansnd pagina astfel salvat n browserul nostru cu suport JavaScript. Daca browserul suport JavaScript vom vedea trei linii:
A c es ta e s t e u n d o c u me nt HT M L c o n t i na nd Ja va S cr i p t . A c es ta e s t e J a v a S c r ip t! D i n no u t e x t s i c o d H TM L .

Este perfect adevrat c acest script extrem de simplist nu este unul foarte folositor acelai rezultat l puteam obine mult mai simplu utiliznd cod HTML. Am dorit doar s exemplificm utilizarea tagului <script>. Tot ceea ce se afl ntre eticheta <script> i eticheta </script> este interpretat drept cod JavaScript. Putem observa folosirea document.write() una dintre cele mai folosite comenzi n programarea JavaScript. document.write() este o rutin JavaScript folosit pentru a scrie text, imagini, etc... ntr-un document. Aadar, scurtul nostru program JavaScript scrie textul Acesta este JavaScript! n documentul HTML n care a fost inserat. Libraria script.aculo.us este prima colecie de efecte vizuale realizate cu ajutorul JavaScript. Alternativa este jQuery, care functioneaz puin altfel, n sensul c suport cascade de instruciuni. Script.aculo.us este uor de neles, avnd doar trei funcii de baz: efecte - new Effect.effectName() i controale drag&drop new Control.controlName() event-uri new Event.observe( [ click, mouseover, mouseon, etc. atenie, fara on-ul din fa ], id-ul elementului, functia de executat ) call-uri AJAX new Ajax.Update() Tag-urile folosite pentru ncadrarea scripturilor sunt <script> i </script>. Tag-ul care deschide scriptul ar trebui s arate aa:
<script language="JavaScript"> Codul JavaScript </script>

Se pot folosi cte astfel de tag-uri dorii n fiierul HTML, ca i cnd ar fi un tag normal. Doar amintii-v s-l nchidei. Dac urmrii s folosii funcii JavaScript, acestea trebuie plasate ntre <head> i </head> ale documentului. n acest fel, funciile sunt ncrcate nainte ca pagina s nceap s fie afiat i nu vor aprea nici un fel de erori ale codului. Mai este un lucru de care trebuie inut cont nainte s trecem la scrierea scripturilor: browserele vechi nc sunt folosite, dar ele nu recunosc tag-ul <script>. Dect s scriei scriptul i s vi-l afieze ca 22

pe un simplu text, mai bine "pclii" browserul. Vei face asta ignornd textul din tag-ul <script>. Acest lucru se face folosind un comentariu HTML. Browserele vechi vor ignora textul dinuntrul comentariilor, dar un browser care suport JavaScript va procesa totui scriptul. Cum se face asta? Un exemplu:
<script language="JavaScript"> <!-- Asta deschide partea in care punem comentariile. Comentariu //--> Asta inchide partea comentariilor, iar browserul va procesa scriptul. </script>

n continuare vom analiza un script care folosete evenimentele mouse-ului.

<a href="exemplu.html" onMouseover="window.status='Salut, asta e primul script'; return true">Pune mouse-ul aici!</a>

Acest script nu necesit tagurile <script> i </script> fiind foarte simplu. Ceea ce face este s modifice statusul ferestrei la mutarea de ctre utilizator a mouseului peste un link. n rest, programarea n JavaScript este, privitor la sintax, foarte asemntoare cu cea n limbajul Java i C++. Ce este necesar n plus este cunoaterea proprietilor ce pot fi ataate fiecrui element. Scripturile realizate n JavaScript acioneaz asupra unui ansamblu de obiecte coninute n pagina Web sau aparinnd browserului. Aciunea va presupune apelul unor metode definite n acest scop pentru obiectele respective sau atribuirea unor valori membrilor date ai obiectelor. Obiectele care pot fi accesate pot fi definite prin structura ierarhic din figur:

Figura 5. Structura ierarhic JavaScript

23

2.3.2 Javascript asincron i XML (AJAX)

Ajax este prescurtarea pentru Asynchronous JavaScript and XML (JavaScript i XML asincron) i reprezint o colecie de tehnologii utilizate n dezvoltarea aplicaiilor web. Scopul principal este de a aduga o interactivitate mai mare n paginile web i de a micora timpul de ncrcare al acestora. n msura n care internetul este n continu dezvoltare unde numrul de pagini web se dubleaz la o perioad de cteva luni, se dezvolt foarte mult servicii de comer electronic, magazine virtuale sau site-uri sociale, tehnologia Ajax devine o component de baz pentru orice astfel de site. Ajax presupune un schimb mic de date ntre client i server, astfel nct s nu mai fie necesar rencarcarea ntregii pagini web de fiecare dat cnd utilizatorul interaoneaz cu aceasta. Ajax reprezint o colecie de tehnologii, fiecare utilizat i dezvoltat n mod de sine-statator, dar care combinate permit obinerea unei unelte foarte puternice, din car dorim s amintim cele mai importante: prezentarea n mod standard a paginilor, prin HTML sau mai nou XHTML, i CSS pentru aranajrea n pagin a coninutului; afiare dinamic i interaciune folosind DOM, accesat printr-un limbaj de scripting, pentru a modifica n mod dinamic i a asigura interaciunea cu informaia prezentat; schimb bidirecional de date i manipulare prin XML ntre client i server, dei orice format poate fi folosit, inclusiv HTML, XSLT sau text simplu; schimbul de date asincron se realizeaza prin obiectul XMLHttpRequest, dei n unele implementari AJAX se poate folosi un iFrame pentru schimbul de date, sau chiar tag-uri <script> adugate dinamic; JavaScript folosit pentru a lega toate aceste elemente ntr-un pachet puternic. Modelul clasic al aplicaiilor web este urmtorul: aciunile utilizatorilor n interfaa din browser conduc la o cerere HTTP ctre serverul web; serverul realizez nite procesri i ulterior returneaz o pagin HTML ctre client. Este modelul clasic, sincron, dezvoltat odat cu apariia internetului ca reea la nivel mondial. Este calea cea mai simpl, dar n timp ce serverul proceseaz cererea, utilizatorul ateapt i nu poate interaciona n niciun alt mod cu pagina web, acest lucru crend un blocaj care de cele mai multe ori este foarte neplcut. AJAX elimin aceast modalitate de interaciune start-stop-start-stop a Webului introducnd un nivel intermediar ntre utilizator i server motorul AJAX. Adugarea unui nou nivel ntr-o aplicaie de obicei o face s lucreze mai greu, dar n acest caz este adavarat afirmaia invers. n loc s ncarce pagina la

24

inceputul sesiunii, browserul ncarc un motor AJAX, scris n JavaScript i plasat de obicei ntr-un cadru invizibil. Acest motor este apoi responsabil att cu interfaa pe care o afieaz utilizatorului, ct i cu comunicaia cu serverul pentru folosul utilizatorului. Motorul AJAX permite interaciunea utilizatorului cu aplicaia n mod asincron, independent de comunicaia cu serverul. Prin urmare utilizatorul nu mai privete o fereastra goal, ateptnd ca aceasta s se ncarce direct de pe server. Prima utilizare a termenului AJAX n mod public a fost n februarie 2005. Jesse James Garrett susine c a gndit aceasta denumire realiznd necesitatea unui termen simplu, scurt i usor de pronunat n momentul cnd urma s prezinte unor clieni o suit de tehnologii propuse pentru implementare. Dei termentul AJAX are mai puin de doi ani de la apariie, istoria tehnologiilor care au dus la implementarea acestuia ncepe cu 10 ani n urm, atunci cnd Microsoft avea iniiativ n a dezvolta Remote Scripting. Tehnici pentru ncrcarea asincrona a coninutului ntr-o pagina web, fr necesitatea rencrcrii totale, au aprut de pe vremea elementului iframe i a elementului layer. Ambele elemente aveau cmpul src pentru ncrcarea unui url extern, i, prin utilizarea JavaScript se putea manipula pagina mam, obinnduse un efect asemanator cu AJAX. Astfel de tehnici au fost implementate n DHTML, i chiar i produsul Macromedia Flash putea ncrca fiiere XML sau CSV de pe un server fr a necesita o rencrcare a paginii n browser. Remote Scripting de la Microsoft funciona ca un nlocuitor mai elegant al acestor tehnologii, datele fiind extrase de un applet Java cu care clientul comunica prin JavaScript, tehnic disponibil n IE4. Microsoft a creat pentru IE5 obiectul XMLHttpRequest i a aratat avantajele lui in Outlook Web Access, care face parte din pachetul Microsoft Exchange Server 2000. Comunitatea Web, suficient de dezvoltat la nceputul anilor 2000 a preluat iniiativa n dezvoltarea acestui tip de tehnologie. Prin colaborare public s-a mbuntit tehnica de scripting pentru a permite utilizarea i pe alte browsere. n 2002 a fost modificat Remote Scripting pentru a nlocui applet-ul Java cu XMLHttpRequest care a devenit modalitatea preponderent de comunicare cu serverul.

25

Microsoft a introdus tehnologia Callback n ASP.NET, dar XMLHttpRequest a rmas cel mai folosit deoarece este foarte bine implementat n toate browserele, celelalte tehnologii nefiind folosite dect n cazuri de incompatibilitate.

Figura 6. Modelul AJAX, cerere-rspuns

Prin generarea de HTML local, n browser, i aducnd de pe server doar apelri JavaScript i date, paginile realizate cu AJAX se ncarc mai repede deoarece informaia necesar este mai mic. De exemplu se pot aduce doar datele dintr-un tabel, iar afiarea tabelului n sine, tag-urile <TABLE>, <TR> si <TD> se genereaz local, n browser, nefiind necesar i transferul acestora de pe server. Structura generala a unei pagini, titlu, meniu lateral, subso de pagin, se genereaza o singur dat, iar la navigarea acelui site se aduc doar datele noi din coninutul paginii respective, titlul i meniurile rmnnd neschimbate. Aplicaiile AJAX sunt n principal executate n computerul utilizatorului, prin manipularea paginii curente de ctre browser folosind DOM. AJAX poate fi utilizat pentru o serie de funcii precum actualizarea nregistrrilor, expandarea formularelor, returnarea unor cutari simple, editarea de elemente, trimiterea de formulare, toate fr nevoia de a rencarca ntreaga pagina web n momentul cnd aceasta este modificat. Se trimit doar cereri scurte ctre server i se primesc rspunsuri de dimensiuni mici. Acest lucru crete interactivitatea i apropie paginile web de posibilitile aplicaiilor desktop. Pentru magazin virtuale, site-uri de eBanking sau eCommerce, sau pentru implementarea unui chat ntr-o pagina web tehnologia AJAX este foarte potrivit. n condiiile n care un studiu recent a artat c un client prsete site-ul unui magazin online n favoarea altuia dac ncrcarea unei pagini dureaz mai mult de 4 secunde, interaciunea oferita de Ajax privind posibilitatea de a modifica doar anumite aspecte ale paginii (de exemplu apariia prerilor altor cumprtori 26

despre un anumit produs sau calculul sumei totale din coul de cumprturi fr a rencrca toat pagina, ci doar acea zona) este foarte important. Paginile web ce utilizeaz Ajax pot s mpiedice buna funcionare a comportamentului normal, obinuit i ateptat al butoanelor de Back i Forward dintr-un browser. Utilizatorii sunt obinuii ca apsnd aceste butoane s fie dui la aspectul anterior al paginii, dar acest lucru nu este mereu adevrat cnd se utilizeaza Ajax, deoarece browserul nu poate ine mereu evidena modificrilor survenit n mod dinamic i asincron. Dezvoltatorii de site-uri au introdus diverse rezolvri pentru aceast problem, folosind iframe-uri invizibile pentru a reine coninutul paginii anterioare. Google Maps, de exemplu, face cutarile ntr-un iframe invizibil i apoi aduce rezultatele n partea vizibil a paginii. n recomandarea XHTML 1.1 a World Wide Web Consortium, organismul care standardizeaza metodele si limbajele utilizate in Internet, se recomanda folosirea elementului object. O alt problem a paginilor dinamice este dificultatea crerii unui link sau bookmark ctre o stare particular a aplicaiei. Soluii au fost gsite prin utilizarea de identificatoare de fragmente url, deoarece prin JavaScript se poate modifica adresa paginii prin schimbarea acestui identificator de fragment. Aceast soluie ajut i la problema butonului Back, dar nu este una complet. Modificarea doar a unor poriuni din pagini poate crete totui timpul aparent de rspuns, deoarece utilizatorul observ mai greu modificrile fcute ntr-o poriune mic a unei pagini deja ncrcate. Se recomand utilizarea unor indicatori de activitate de procesare, de exemplu celebra clepsidra. Website-urile care utilizeaz pagini ncrcate prin AJAX trebuie s fie atente s ofere aceeai informaie i ntr-un format clasic, pentru a putea fi indexat de roboii de indexare ai motoarelor de cautare pe Internet. Dac anumite informaii (date, text, imagini) nu apar dect la apelarea unor funcii JavaScript prin Ajax, aceste informaii nu vor fi gsite de un motor de cutare deoarece acestea citesc doar textul existent n pagin i nu ruleaz i funciile din aceasta. Google a fcut pai imeni n implementarea acestei tehnologii n site-urile proprii i a dus astfel la popularizarea ei. Toate produsele Google folosesc din plin Ajax, ncepand cu Gmail, Google Groups, Google Suggest, Google Read. Google Analytics, Google AdWords i Google Maps. Cel mai mare site de fotografii online, Flickr, recent achiziionat de Yahoo utilizeaz Ajax pentru a permite utilizatorilor s noteze, voteze, catalogheze fotografii, s scrie comentarii i s organizeze aspectul general al interfeei fr a

27

rencarca pagina. Magazine online precum Amazon, eBay utilizeaz Ajax pentru a prezenta cumprtorilor informaia cerut de acetia fr a fi nevoii s atepte rencrcarea paginii dupa fiecare click. Recent Yahoo a anunat integrarea elementelor de Yahoo Messenger n fereastra web a serviciului de webmail Yahoo Mail Beta. Chat-ul cu contactele din lista de Yahoo Messenger se va face direct din browser, mesajele noi aprnd fr a fi necesar rencarcarea paginii. Un alt exemplu foarte bun este Google Analytics considerat cel mai bun serviciu de analiz a traficului unui site. Google Analytics prezint informaii precum site-ul de pe care au venit vizitatorii, browserul folosit, rezoluia ecranului, sistemul de operare, adncimea de culoare, prezena tehnologiei Java sau Flash, pagini citite, timpul petrecut pe site, ce reclame din site au atras cel mai mare interes pentru vizitatori. Aceste informaii sunt prezentate prin grafice, tabele i alte reprezentri dinamice n funcie de specificului fiecrui raport. Cnd deintorul site-ului evaluat dorete s treac de la informaiile despre rezoluia ecranului la versiunea browserului folosit, n pagin sunt ncarcate prin AJAX un nou grafic i un nou tabel cu numele browserelor i procentele de utilizare folosind date extrase din baza de date, deci doar dou elemente, toate celelalte elemente din pagina (titlu, meniul de opiuni din stnga, textele din subsol i din dreapta) ramnnd neschimbate. Doar graficul se schimb chiar i atunci cnd se modific perioada dorit pentru afiare (numrul de zile, afiare pe luni, trimestriala, etc), culorile, tipul de grafic i alte astfel de elemente de interfa. Informaia cerut la o apelare prin Ajax este de cteva ori mai mic dect dac ar fi fost vorba de relaia client-server clasic, i, prin urmare, timpul ctigat i mulumirea fa de eficiena i rapiditatea serviciului Google Analytics crete proporional, totul datorits tehnologiei Ajax. n cele ce urmeaz prezentm un exemplu simplu Ajax, o pagina HTML care comunic dinamic cu un script PHP.
Pagina HTML: <html> <head> <title>Exemplu AJAX</title> <script language="Javascript"> function xmlhttpPost(strURL) { var xmlHttpReq = false; var self = this; // Mozilla/Safari if (window.XMLHttpRequest) { self.xmlHttpReq = new XMLHttpRequest(); }

28

// Internet Explorer else if (window.ActiveXObject) { self.xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP"); } self.xmlHttpReq.open('POST', strURL, true); self.xmlHttpReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); self.xmlHttpReq.onreadystatechange = function() { if (self.xmlHttpReq.readyState == 4) { updatepage(self.xmlHttpReq.responseText); } } self.xmlHttpReq.send(getquerystring()); } function getquerystring() { var form = document.forms['f1']; var word = form.word.value; qstr = 'w=' + escape(word); return qstr; } function updatepage(str){ document.getElementById("result").innerHTML = str; } </script> </head> <body> <form name="f1"> cuvnt: <input name="word" type="text"> <input value=Go type="button" onclick=' JavaScript:xmlhttpPost("procesor.php")'> <div id="result"></div> </form> </body> </html> fiier PHP: <? if (isset($_POST["w"])) $var_ajax = $_POST["w"]; echo "Ati specificat: ".$var_ajax."<br />" echo "IP d-voastr: ".$_SERVER['REMOTE_ADDR']; ?>

29

2.4 Securitatea aplicaiilor web

Securitatea aplicaiilor web este un subiect foarte important nct acesta trebuie tratat separat i inclus chiar de la primele etape din proiectarea aplicaiei. Cel mai important concept pe care trebuie s-l nelegem despre securitate este acela c o aplicaie web nu va fi nici sigur, nici nesigur. Aplicaia va fi mai sigur sau mai puin sigur. Securitatea nu este un comutator, cu poziiile pornit i oprit, ci un cursor pe care l deplasm mai sus sau mai jos. De asemeni, n mod normal, un nivel mai nalt de securitate este obinut cu preul reducerii comoditii n utilizare (att pentru programatori ct i pentru utilizatorul final) i a performanelor. Creterea securitii nseamn, de obicei, mai mult cod, mai multe verificri i ncrcarea suplimentar a serverului. Ca urmare, atunci cnd dezvoltm aplicaii web, trebuie s inem seama de aceste aspecte i s lum deciziile corecte nc de la nceput, n funcie de situaia concret.

2.4.1 Validarea mai sigur a datelor din formulare

Regula de baz pentru validarea oricror date primite de o pagina PHP este s presupunem c datele sunt invalide, pn cnd trec de testele care arat contrariul. La un nivel minim, ar trebui: s folosim variabile superglobale (precum $_POST['id'] sau $_GET['id']) n locul variabilelor globale nregistrate ($id); s verificm completarea rubricilor de text i parole din formulare folosind funcia empy(); s verificm completarea celorlalte elemente de intrare din formulare folosind funcia isset(); s verificm dac lungimea tuturor elementelor de intrare din formulare are o valoare pozitiv. O cale mai bun de validare a datelor din formulare este s verificm dac acestea sunt de un anumit tip. O metod i mai exact de validare a datelor din

30

formulare necesit folosirea expresiilor regulate, sau folosirea Javascript-ului pentru operaii elementare de validare a datelor pe partea de client, n browserul web, nainte ca datele s fie transmise ctre server.

Prevenirea transmiterii multiple a formularelor

Un asemenea eveniment poate fi considerat un disconfort minor sau o problem major pentru orice aplicaie web, n funcie de modul n care se face transmiterea repetat accidental sau intenionat. Exist mai multe soluii pentru prevenirea transmiterilor multiple din care prezentm un exemplu. n primul rnd, dac folosim deja sesiuni, o soluie la ndemn este s crem o variabil de sesiune prin care s indicm dac un anumit formular a fost deja transmis.
if (isset($_SESSION['nume_formular'])){ // nu prelucrez formularul } else { // prelucrez formularul // indic faptul c formularul a fost deja prelucrat $_SESSION['nume_formular']=TRUE; }

Aceast soluie tehnic este foarte simpl, dar impune folosirea sesiunilor.

2.4.2 mbuntirea securitii sesiunilor

Deoarece, n mod normal, informaiile importante sunt stocate ntr-o sesiune (nu ntr-un modul cookie), securitatea devine un aspect critic. Trebuie s ne amintim faptul c n cazul sesiunilor trebuie s tinem seama de dou lucruri: identificatorul sesiunii, care reprezint un punct de referin pentru datele sesiunii, i sesiunea propriu-zis, care este stocat pe server. Este mai probabil ca o persoan ruvoitoare s ncerce ptrunderea ntr-o sesiune prin identificatorul sesiunii, nu prin datele stocate pe server, aa c n continuare ne vom concentra asupra acestui aspect. Stocarea identificatorului unei sesiuni ntr-un modul cookie este considerat o metod mai sigur de folosire a sesiunilor, n contrast cu transmiterea identificatorului prin adresele URL sau stocarea acestuia ntr-un element de intrare ascuns al formularului. Aceste alternative sunt mai puin sigure, deoarece sesiunea poate fi deturnat cu uurin de un alt utilizator. Dac se poate afla identificatorul de sesiune al unui utilizator, se poate pcli serverul pentru a

31

crede c acela este identificatorul sesiunii noastre. Din acel moment, am preluat complet ntreaga sesiune a utilizatorului original i avem acces la toate datele acestuia. Ca urmare, stocarea identificatorului unei sesiuni ntr-un modul cookie l face ceva mai greu de furat. O metod de prevenire a deturnrilor este s stocm un identificator al utilizatorului n sesiune, apoi s verificm n mod repetat aceast valoare. Variabila HTTP_USER_AGENT este un candidat potrivit pentru scopul urmrit. Acesta este un nivel suplimentar de securitate, deoarece nu se poate deturna sesiunea unui alt utilizator dect dac se ruleaz pe aceaiai combinaie de browser i sistem de operare. De exemplu, pagina de autentificare ar putea conine linia:
$_SESSION['agent']=$_SERVER['HTTP_USER_AGENT'];

Paginile ncrcate ulterior ar putea apoi s compare valoarea agent stcat cu valoarea HTTP_USER_AGENT a utilizatorului.
if ($_SERVER['HTTP_USER_AGENT']!=$_SESSION['agent']){ /* sesiune deturnat */ }

Sugestii de mbuntire a securitii sesiunilor: criptarea informaiilor $_SERVER['HTTP_USER_AGENT'], folosind funcia md5(), pentru a le face mai dificil de nlocuit. Pentru utilizrile critice ale sesiunilor, trebuie s impunem folosirea moduleleor cookie i transmiterea acestora print conexiuni sigure; dac se folosete un server partajat cu alte domenii, este mai sigur s modificm valoarea prestabilit a opiunii session.save_path - care permite accesul tuturor utilizatorilor - cu ceva mai specific; din punctul de vedere al securitii pe partea de server, datele sesiunii pot fi stocate ntr-o baz de date, nu ntr-un fiier text. Aceasta este o metod mai sigur, dar necesit un efort suplimentar de programare; adresa IP a utilizatorului (adresa de reea de la care s-a conectat utilizatorul) nu este un bun identificator unic, din dou motive. n primul rnd, adresa IP a unui utilizator se poate schimba frecvent (i, in mod normal, chiar se ntmpl acest lucru, deoarece furnizorul ISP i aloc dinamic adresa pentru o scurt perioad de timp). n al doilea rnd, mai muli utilizatori care au acces la un site din aceeai reea (cum ar fi o reea la domiciliu sau dintr-un birou) pot avea aceeai adresa IP.

2.4.3 Asigurarea securitii SQL

32

Securitatea bazelor de date, n privina scripturilor PHP, poate fi mprit n dou domenii largi: protejarea informaiilor de acces la baza de date; precauiile la rularea interogrilor, n special a celor care implic date furnizate de ctre utilizatori. Primul obiectiv poate fi ndeplinit prin stocarea scriptului de conectare la MySQL undeva n afara directorului web, astfel nct s nu poat fi vizualizat printr-un browser web. Pentru al doilea obiectiv, exist numeroi pai pe care i putem parcurge. n primul rnd, trebuie folosii vectorii $_POST sau $_GET n detrimentul variabilelor globale definite. n al doilea rnd, verificm dac au fost transmise date din formular i dac datele transmise sunt de tipul corespunztor. n al treilea rnd, trebuie folosite expresii de cutare pentru a verifica dac datele transmise respect formatul la care ne ateptm. A patra recomandare este de a folosi funcia specific mysql_real_escapestring(). Aceast funcie insereaz secvene escape pentru caracterele care ar putea cauza probleme. Aceast funcie este asemntoare cu funcia addslashes() i trebuie folosit pentru orice text transmis din formulare dar este conceput special pentru bazele de date. Deoarece este posibil ca serverul s aib activat opiunea Magic Quotes, scriptul trebuie s se asigure c n datele transmise din formular nu sunt adugate prea multe secvene escape.

2.4.4 Criptarea i securitatea bazelor de date

Dac deinem drepturi administrative asupra bazei de date, trebuie s inem seama de urmtoarele recomandri: s nu permitem conectarea utilizatorilor anonimi la MySQL; s impunem ntotdeauna introducerea unei parole pentru conectare; s solicitm utilizatorilor s specifice i un nume gazd; n acest fel restricionm calculatoarele de la care utilizatorii au acces la MySQL; s atribuim fiecrui utilizator numai privilegiile minime necesare; s restricionm accesul utilizatorului root numai de la calculatorul local; s tergem baza de date de test, la care, n mod prestabilit, au acces toi utilizatorii; atunci cnd stocm ntr-un tabel date confideniale, i n special parole, trebuie s protejm datele prin folosirea funciilor de criptare; trebuie s validm datele transmise de utilizatori nainte de a le insera ntr-o baz de date;

33

 s folosim extensia .php pentru fiierele care conin informaii pentru conectarea la baza de date; dac este posibil, s stocm scriptul de conectare la baza de date n afara directorului web rdcin; MySQL are cteva funcii de criptare i decriptare ncorporate n software. O funcie foarte asemntoare cu sha() i md5() este encrypt() care este folosit pentru criptarea datelor, dar difer prin faptul c permite adugarea unui parametru, numit sare care mbuntete caracterul aleatoriu al procesului de criptare. Funcia encrypt() folosete programul Unix crypt(), care s-ar putea s nu fie disponibil pe orice sistem (n special sub Windows). MySQL include i o alt funcie de criptare, numit des_encrypt(), care poate fi folosit pentru ssl. Funcia sha() i encrypt() creeaz un ir de caractere criptat care este aproape imposibil de decriptat. Aceasta este o msur de securitate foarte puternic, deoarece nseamn c datele stocate nu mai pot fi regsite sub o form inteligibil. Dac dorim ca datele s fie stocate ntr-o form criptat care s poat fi decriptat, trebuie s folosim perechile de funcii encode() i decode() sau aes_encrypy() i aes_decrypt(). i aceste funcii primesc un parametru sare, care mbuntete caracterul aleatoriu al procesului de criptare. Funcia aes_encrypt() este considerat cea mai sigur opiune ce criptare, dar este disponibil numai ncepnd cu versiunea MySQL 4.02.

34

Capitolul 3

Analiza i proiectarea aplicaiei

n faza faza iniial de proiectare a aplicaiei ncercm s realizm o lista cu principalele cerine ale acesteia. Lista reprezint un ghid pentru alegerea arhitecturii utilizate i pentru dezvoltarea conceptual a entitilor incluse n proiect. Aplicaia dezvoltat n cadrul lucrrii de fa trebuie s ndeplineasc urmtoarele cerine funcionale i nefuncionale: s permit accesul restrictiv la sistemul de administrare; s permit dezvoltarea unui produs multilingvistic; s permit adugarea unor noi limbi de circulaie internaional; s permit crearea de pagini de coninut; s permit manipularea facil a datelor de ctre utilizatori; s permit modificarea vizual a produsului finit; s menin modificrile efectuate unei nregistrri; s permit organizarea structurii produsului finit pe mai multe nivele; aplicaia s fie securizat; aplicaia s ofere un grad ridicat de ncredere i robustee;

3.1 Descrierea cazurilor de utilizare

Accesul la module de ctre un utilizator se face prin interfaa de privilegii, altfel spus, utilizatorul are acces la o seciune care ii permite ulterior s acceseze metodele modulelor la care are nevoie pe baza privilegiilor pe care le deine. n continuare trebuie analizat sistemul din dou perspective:

35

 elemente necesare pentru realizarea aciunilor specifice lucrului cu resursele unei companii: intrri, ieiri, contracte, facturi, chitane, casierie, companii; elemente necesare pentru integrarea celor mai sus menionate ntr-o aplicaie web care are specifice: managementul utilizatorilor, elemente de configurare, elemente de securitate, acces n sistem pe baza de privilegii; n figura de mai jos este prezentat diagrama cazurilor de utilizare:

Figura 7. Diagrama cazurilor de utilizare

Trebuie avut n vedere dezvoltarea urmtoarelor module privind procedurile specifie unei companii: intrri este nevoie de o seciune care s gestioneze toate intrrile n companie; pentru fiecare nregistrare trebuie s se rein un index consecutiv i consistent denumit registru, o desriere scurt, i alte date specifice precum compania de la care s-a primit intrarea, numele utilizatorului care a efectuat-o; ieiri asemntor seciunii intrri, trebuie s inem evidena tuturor evenimentelor care ies din companie; avem de reinut un registru, descriere, compania ctre care s-a efectuat i numele utilizatorului care a efectuat; contracte trebuie conceput astfel nct s reinem date precum compania cu care se efectueaz contractul, datele de contact ale persoanei responsabile din

36

exterior, descriere, numele persoanei care a ncheiat contractul; de asemeni trebuie s avem un registru special pentru contracte; facturi trebuie ca pe lng datele privitoare la o factur n general: numr registru, sum, descriere detaliat, persoana care o emite, s avem i o coresponden cu contractele existente, mai precis putem avea facturi emise pentru orice contract existent, dar i facturi fr contract; chitane avem nevoie de gestionarea datelor privitoare la numrul registrului, sum, tipul chitanei, numele persoanei care a emis-o mpreun cu legtura cu facturile existente n sistem; o chitan nou poate s fie emis pentru dou mulimi distincte: mulimea facturilor emise fr contract precum i mulimea facturilor care au asociate un contract; casierie n cadrul unei companii avem nevoie de un modul care s ina evidena traseelor banilor, cu alte cuvinte acest modul va inventariza chitane, bonuri fiscale, mprumuturi de tip asociat; va conine de asemeni un registru, detalii privind nregistrarea, suma; Dup cum am putut observa toate modulele trebuie s aib un cmp numit nume utilizator care este foarte util deoarece tim cine este responsabil pentru acea nregistrare. Un alt aspect este acela c, existnd posibilitatea ca o nregistrare s fie eronat realizat sau trebuie s sufere mici modificri, sistemul va oferi posibilitatea editrii acesteia doar de ctre persoana care a realizat-o. Pe partea de aplicaie web, vom avea nevoie de urmtoarele seciuni: utilizatori seciune care s permit gestionarea persoanelor care au voie s foloseasc aplicaia; aici discutm de posibilitatea adugrii, editrii i tergerii unui utilizator: nume, prenume i privilegii; cereri tergeri seciune care gestioneaz aciunea utilizatorilor; este posibil ca utilizatorii s nu-i exercite n mod corect drepturile, din acest motiv putnd ca la un moment sistemul s conin nregistrri eronate;

37

3.2 Alegerea modelelor de dezvoltare

Pentru Sistemul integrat pentru Managementul unei Compani am ales un model de dezvoltare incremental deoarece aceasta este tendina n momentul de fa n ceea ce privete dezvoltarea aplicaiilor web de dimensiuni medii. Aceast elegere este sustenabil deoarece: procesul de specificare, proiectare i implementare este un proces concurent; nu exist o specificaie detaliat i documentarea proiectrii este minimalizat; sistemul este dezvoltat ntr-o serie incremental; utilizatorii finali evalueaz fiecare variant incremental i fac propuneri pentru urmtoarea variant; interfeele utilizator ale sistemului sunt dezvoltate de obicei ntr-un proces interactiv; prezint urmtoarele avantaje: livrarea accelerat de servicii clienilor; fiecare variant incremental livreaz cea mai prioritar funcionalitate ctre client; implicarea utilizatorului vis-a-vis de sistem; utilizatorul trebuie s se implice n dezvoltare ceea ce duce la un sistem care se modeleaz mai bine pe cerinele sale; etapele de testare i acceptare sunt mai rapide; elementele mai importante sunt dezvoltate primele i prin urmare sunt testate mai mult timp;

Figura 8. Modelul incremental de dezvoltare software

38

n cadrul unui increment, pentru implementarea diverselor procese am ales modelul funcional de tip pipeline: proceseaz intrrile n ieiri conform unor transformri funcionale; este asemntor modelului pipe din shell-ul Unix; variante ale acestui concept sunt des ntlnite; cnd transformrile sunt secveniale, acesta este un model de prelucrare a loturilor de date foarte comun n sistemele de procesare a datelor; avantajele modelului pipeline: sprijin reutilizarea transformrilor; organizare intuitiv; uor de adugat noi transformri; relativ uor de implementat att concurent ct i secvenial; Exemplu de folosire a modelului pipe-line:

Figura 9. Modelul pipeline de dezvoltare al unui proces

39

3.3 Nucleul aplicaiei

Aplicaia de fa va trece prin trei ciclii de via pentru a putea ajunge la versiunea final care s respecte toate cerinele impuse. n figura de mai jos este prezentat nucleul sistemului care conine cele mai importante elemente, a cror interdependen este foarte puternic. Aceste elemente asigur un minimum de funcionaliti pentru ca aplicaia s mearg.

Figura 10. SIMC nucleu, primul ciclu de via

n continuare este prezentat ciclul 2 de viaa n care sunt ataate dou module, mai precis Intrri i Ieiri. Aceste din urm dou module sunt opionale, ele nu altereaz modul de funcionare al nucleului.

Figura 11. SIMC, al doilea ciclu de via

n figura urmtoare este prezentat ciclul de viaa final n care s-au adugat toate componentele necesare bunei funcionri n conformitate cu cerinele impuse.

40

Aceste module sunt independente de sistem, dar pot exist interdependene n configurarea unora dintre ele; spre exemplu modulul de chitane nu poate funciona dac nu este instalat modulul de facturi, care n schimb este independent de celelalte module.

Figura 12. SIMC, ciclul de via final

41

3.4 Modulele aplicaiei

Deoarece nu putem prevedea cu exactitate numrul i tipul modulelor pe care le vor solicita ulterior clienii, precum i datorit faptului c ne dorim o implementare ct mai cursiv i uoar a acestora, ne punem problema crerii unui ablon. n dezvoltarea acestui ablon am identificat urmtoarele elemente de care trebuie s inem cont; orice nregistrare: tebuie s fie unic; s poat returna id-ul utilizatorului care a creat-o (id unic care se reflect n modul utilizatori i care ulterior ne poate oferi numele i prenumele); s permit schimb de referine (de exemplu n modulul chitane trebuie s cunoatem referina facturii chitanate din modulul facturi) s permit adugarea unei descrieri care s ajute ulterior utilizatorul n identificarea nregistrrilor pe baza unor cutri prefereniale; s permit extinderea de la ablon prin tipuri structurale simple.

Figura 13. ablon realizare module

42

3.5 Seciunea Utilizatori

Aplicaia asigur un management complet n ceea ce privete utilizatorii. Adugarea unui utilizator se realizeaz prin completarea unui formular cu datele de autentificare ale noului utilizator, date personale cum ar fi vrsta, cod numeric personal, caliti i experiena n domeniu etc. precum i alegerea unor drepturi de autorizare pentru acesta. Pentru definirea unui grup sau rol se va completa formularul aferent i se vor alege drepturile pe care un utilizator din acest grup le va avea. n formularul de adugare a unui grup nou sunt prezentate principalele aciuni pe care un utilizator le poate ntreprinde n cadrul seciunii de administrare. Se vor selecta o serie de aciuni pe care le va putea efectua utilizatorul i se va salva respectivul grup. Odat cu salvarea acestuia se va atribui noul rol utilizatorilor noi sau existeni ai aplicaiei. Trebuie luat n considerare posibilitatea de a dezvolta ulterior seciunea utilizatorilor, mai precis fiecare utilizator s-i poate particulariza panoul de lucru central, s-i poate modifica singur username-ul i parola de acces n aplicaie. Se dorete ca aplicaia s fie robust cu un nivel ridicat de securitate; aplicaia trebuie s fac fa tentativelor ce acces neautorizat i de atac informatic, rejectarea unor atacuri de tip dos sau sql injection.

3.5 Seciunea multilingvistic

n cadrul acestei seciuni se va lucru cu limbile care vor fi ulterior disponibile ntregului sistem. Se poate aduga o nou limb sau se poate modifica/edita starea unei limbi deja instalate. Parametrul default descrie limba care este selectat implicit n momentul n care un utilizator viziteaz aplicaia, iar aciunea de publicare modific permite administratorului setarea unei alte limbi existente. Prin aceast funcionalitate se permite administratorului controlarea procesului de publicare a coninutului ntr-o noua limb, un administrator cu drepturile de acces aferente avnd posibilitatea s fac public noua limb doar n momentul n care coninutul acesteia este completat n totalitate. Instalarea unei noi limbi trebuie s fie facil, selectandu-se limba strin dorit i apsnd doar instaleaz. Seciunile de editare ale unei pagini de coninut sau de redirectare se vor modifica n mod corespunzator, permind editarea coninutului n noua limb strin instalat. 43

3.5 Descrierea unor moduri de lucru

3.5.1 Autentificarea unui utilizator
Accesul unei persoane la sistem se face prin intermediul paginii de autentificare unde va fi ntmpinat de un formular de autentificare. Dac i se valideaz formularul, sistemul va genera o sesiune unic i ii va permite accesul n sistem; n caz contrar va naviga ctre pagina de log-in unde i se vor afia mesaje de eroare; n acest moment utilizatorul are posibilitatea de a ncerca din nou validarea formularului sau de a prsi sistemul.

Figura 14. Autentificare unui utilizator

3.5.2 Adugarea unui utilizator

Doar administratorii au posibilitatea de a crea utilizatori noi i acest lucru dup ce au parcurs pasul prezentat la punctul de mai sus. Ulterior vor trebui s navigheze n seciunea utilizatori unde vor trebui s completeze un formular de adugare utilizator, fiind necesar completarea cmpurilor nume, prenume, username i bifarea privilegiilor care i se acord respectivului utilizator.

Figura 15. Adugarea unui utilizator

44

3.5.3 Editarea privilegiilor unui utilizator

Sistemul trebuie s fie flexibil n ceea ce privete gestionarea utilizatorilor. Astfel, sistemul trebuie s permit modificare privilegiilor unui utilizator, existnd dou cazuri majore: restricionarea unui utilizator de a mai folosi nite module sau extinderea privilegiilor ctre alte module.

Figura 16. Editarea privilegiilor unui utilizator

3.5.4 tergerea unui utilizator

Pe parcursul funcionrii unei companii este destul de probabil ca mulimea angajailor s sufere mereu modificri. n continuare ne vom referi la cazul cnd anumii utilizatori prsec compania, i, evident, trebuie s le tergem contul pentru ca acetia s nu se mai poat conecta la sistem. Acest lucru este detaliat n figura urmtoare.

Figura 17. tergerea unui utilizator

45

3.5.5 Adugarea unui contract

Una din cele mai frecvente activiti desfurate ntr-o companie este adugarea unor noi contracte. Acest lucru trebuie s fie extrem de facil, s se navigheze n pagina de contracte de unde printr-un singur click trebuie apelat procedura de adugare contracte. Ulterior se va completa un formular. Dac acesta este validat se va produce nregistrarea contractului, altfel se poate opri din aceast procedura.

Figura 18. Adugarea unui contract

3.5.6 Editarea unui contract

Editarea unui contract se face navignd n pagina de contracte, cutnd i selectnd contractul int i fcnd click pe butonul de editare din dreptul nregistrrii. La pasul urmtor se va deschide un panou n care vor fi aduse datele deja existente pentru acel contract utilizatorul putnd modifica aceste date.

Figura 19. Editarea unui contract

46

3.5.7 tergerea unui contract

Pentru a terge un contract trebuie s mergem n seciunea contracte. Odat identificat contractul vizat, se va face click pe butonul de tergere din dreptul nregistrrii. Aceast operaie este exemplificat n figura de ma jos:

Figura 20. tergerea unui contract

3.5.8 Adugarea unei facturi

O alt procedur foarte frecvent printre operaiile unei companii este crearea de noi facturi. Trebuie tiut faptul c o factur poate fi sau nu asociat unui contract. Prin urmare, navignd n pagina de contracte i acionarea unui buton de creare factur nou trebuie s vizualizm un formular intuitiv cu care printrun minimum de interacionare s completm datele necesare, sum, tipul facturii, numr registru etc.

Figura 21. Adugarea unei facturi

47

3.5.9 Editarea unei facturi

Editarea unei facturi se face navignd n pagina facturilor, cutnd i selectnd factura int i fcnd click pe butonul de editare din dreptul nregistrrii. n continuare se va deschide un panou n care vor fi aduse datele deja existente pentru acea nregistrare utilizatorul putnd edita aceste date.

Figura 22. Editarea unei facturi

3.5.10 tergerea unei facturi

Se poate ntmpla ca o anumita factur s fie creat n mod eronat, caz n care se poate proceda ca la punctul precedent prin simpla editare sau ca aceast s nu mai fie valabil. tergerea trebuie s fie foarte simpl, printr-un simplu click pe butonul de tergere din dreptul facturii vizate.

Figura 23. tergere factur

3.5.11 Soluionarea cererilor de tergere

Ori de cte ori n sistem se va ncerca tergerea unei nregistrri, fie ea intrare, ieire, contract sau factur, n prealabil se va crea o cerere de tergere care va trebui validat de ctre un administrator. Odat fcut cererea de tergere, acea nregistrare va trece ntr-o stare de ateptare (nu mai pot fi editatd sau create alte nregistrri cu referine ctre aceasta) pn la soluionarea cererii. n seciunea cereri tergere, un administrator va vizualiza acele cereri, avnd dou opiuni: prima de a respinge cererile, moment n care acestea i reiau starea iniial i a doua opiune de a le valida, moment n care nregistrrile vor trece ntr-o stare special numit cereri terse. 48

Diagrama de activiti corespunztoare acestei operaii poate avea urmtoarea form:

Figura 24. Soluionarea cererilor de tergere

Proiectarea aplicaiei web trebuie s in cont i de anumite elemente specifice domeniului afacerilor, dintre care enumerm: indecii care corespund numerelor registrelor (vorbim aici despre registrele de intrri, ieiri, contracte, facturi, chitane i casierie) trebuie s fie consistente; altfel spus nu putem avea goluri n registre deoarce aceasta este o restricie impus de lege n ceea ce privete desfurarea activitilor companiilor; suprascrierea unor nregistrri sau tergerea acesteia poate fi efectuat doar dac nu are nregistrri copii; cu alte cuvinte nu vom putea terge un contract dac avem facturi sau chitane asociate; sistemul trebuie s atenioneze i s ntiineze utilizatorul n momentul n dorete s fac o astfel de operaie; ca o metod de optimizare a modului de lucru, aplicaia trebuie s ajute modul de completare a unor formulare; un exemplu elocvent este acela n care utilizatorul dorete s adauge o factur, sistemul returnndu-i inline ca opiuni toate contractele asociate companiei selectate de utilizator; sistemul trebuie s faciliteze navigarea i cutarea unei nregistrri ntr-o anumit seciune, utilizatorului trebuind s i se ofere posibilitatea de a ordona nregistrrile dup dat, numr registru, numr curent, etc.; odat creat o nregistrare, sistemul trebuie s aib grij s permit editarea i tergerea acesteia doar de persoanele acreditate s fac acest lucru: autorul nregistrrii i administratorii.

49

3.6 Mrirea nivelului de abstractizare

Aplicaia de fa urmrete un model de dezvoltare incremental, impunndu-se existen unui subsistem minimal care s ofere funciile de baz ale aplicaiei. Acest lucru este dorit din mai multe motive cum ar fi cel de a nu complica aplicaia acolo unde nu este cazul i, mai ales, de a avea n final o aplicaie robust; acest obiectiv este atins prin faptul c acest subsistem este primul creat i n consecin este cel mai mult testat. Sistemul Integrat pentru Managementul unei Companii poate fi construit n prim instan dintr-un nucleu avnd o form asemntoare cu cea din figura de mai jos, unde acele subentiti au o interdependen puternic fiind practic scheletul viitoarei aplicaii.

Figura 25. SIMC 2.0 - nucleu

Pasul urmtor n dezvoltarea aplicaiei este acela de a pune la dispoziia utilizatorilor posibilitatea de a-i personaliz aplicaia n funcie de necesiti. Astfel, o companie mic ar putea avea nevoie doar de un modul de contabilitate i unul de facturare, pe de alt parte o companie care spre exemplu opereaz foarte multe vnzri ar avea nevoie n plus de un modul de stocuri precum i un modul de relaii cu clienii. Sistemul va fi conceput de aa natura de a fluidiz i minimiz sarcinile utilizatorului privind realizarea interdependenelor modulelor. Astfel, sistemul va detecta automat existena unei conexiuni cum ar fi de exemplu ntre modulele de contabilitate i facturare, utilizatorul netrebuind s fac nimic mai mult dect nite simple confirmri de mesaje primite din partea sistemului. Structural, aceast bibliotec de module, precum i interdependena acesteia fa de nucleul aplicaiei, este foarte sugestiv reprezentat n figura urmtoare: 50

Figura 26. SIMC 2.0 - bilioteca de module

Comunitatea business este elocvent reprezentat n figura de mai jos. SIMC ofer posibilitatea companiilor de a interaciona rapid i eficient ntr-un cadru standardizat. Simpla integrarea a unui modul de voip ar duce la micorarea drastic a facturilor telefonice pentru companii. Comunitatea de afaceri se concentreaz ntr-un cuvnt cheie i acesta este eficiena. Aceast eficien apare datorit uurinei de nvare i folosire a SIMC precum i a numeroaselor faciliti care oricnd pot fi customizate la cererea clienilor ntr-un timp scurt i avand costuri reduse.

Figura 27. SIMC 2.0 - comunitatea de afaceri

51

3.7 Portarea modelului aplicaiei

Modelul aplicaiei este foarte flexibil permind realizarea unor aplicaii din domenii total diferite, plecnd de la scheletul actual. Astfel, am putut identifica mai multe tipuri de aplicaii care ar putea fi dezvoltate folosind acest concept i care ar avea un timp redus de realizare datorit folosirii unor module preexistente. Putem enumera urmtoarele tipuri de aplicaii: eCommerce; eBanking; AdServer; eLearning.

AdServer
Modelul prezentat pentru Sistem integrat de management al companiilor poate foarte fi uor modelat pe un sistem de publicitate online. Mai precis, putem discuta aici despre oferirea deintorilor de siteuri web a unei aplicaii standalone care gestioneze spaiile publicitare de pe site-urile clientului, care, n acelai timp, s conin module de monitorizare a traficului, module de generare rapoarte privind eficiena folosirii acestora etc. Comunitatea n acest domeniu poate fi privit ca o piaa online n care deinatorii de site-uri se pot ntlni cu agenii de publicitate sau/i acele persoane/companii care doresc s relizeze campanii publicitare, un loc virtual n care se pot licita bannere precum i schimburi de experiena sau diverse interaciuni specifice domeniului.

eLearning
Acest domeniu este foarte sensibil, n principal datorit implicrii statului mai mult sau mai puin eficient, privind acceptarea internetului i a web-ului ca un mijloc nemijlocit de a crete nivelul educaiei n gradinie, coli, universiti etc. n antitez cu mijloacele clasice. Exist pe piaa diverse aplicaii de eLearning dintre care putem aminti Moodle, care este unul din cele mai modeste aplicaii web, dar care se bucur de cea mai rspndit utilizare datorit acceptrii acestuia de ctre public. Acestor aplicaii le lipsete o standardizare care le-ar putea face interoperabile. Modelul de fa tocmai acest lucru i dorete de a oferi unei eniti, n cazul de faa ar fi o instituie de nvaamnt, posibilitatea de a-i crea propria aplicaie plecnd de la necesiti comune: managementul elevilor, profesorilor, cursurilor, concursurilor etc. i de o dezvolta ctre specificul propriu putnd ulterior s realizeze interaciuni standardizate cu entiti asemntoare. 52

Capitolul 4

Instalarea aplicaiei

Funcionarea aplicaiei este intuitiv, aceasta fiind o condiie de baz a proiectrii sale, ntruct urmeaz a fi folosit de un personal cu pregtiri diverse n ce privete lucrul cu computerele. Este o soluie de management al firmei numit SIMC (Sistem Integrat pentru Managementul unei Companii). Programul se instaleaz pe un server i poate fi accesat pe baz de parol prin intermediul unui browser cu ajutorul interfeei de tip web. Aceast interfa permite gestionarea bazei de date ce conine evidena companiilor, a persoanelor, a mesajelor, a activitilor, a rapoartelor etc. sau realizarea unei serii de aciuni (adugarea de noi companii, persoane de contact, selectarea unor criterii de analiz i crearea unui raport, trimiterea de oferte adresate unor anumite persoane sau unor grupuri int etc.). Aplicaia poate fi folosit de dou mari categorii de persoane: administratori i mai muli utilizatori. Administratorul este cel care adaug, elimin sau inactiveaz utilizatori i le prescrie anumite sarcini (denumite n program activiti). De asemeni, el permite sau interzice dreptul de acces al utilizatorilor la anumite informaii i se ocup de implementarea setrilor de securitate pentru aplicaie i poate s genereze rapoarte centralizate ale activitii utilizatorilor.

4.1 Configurarea aplicaiei

Aplicaia Sistem Integrat pentru Managementul unei Companii este uor de configurat i instalat pe server, fiind necesare doar cunotine medii n domeniu. Doar utilizatorii cu privilegii de administrare pot efectua aceast configurare, sau pot desemna aceste privilegii unui alt utilizator. Printre elementele care pot fi setate pentru iniializarea aplicaiei putem aminti:

53

 datele de conectare la baza de date, numele serverului, numele i parola utilizatorului cu privilegii de acces al bazei de date i numele bazei de date care conine datele aplicaiei; limba care va fi folosit n mod implicit de ctre aplicaie; se va selecta o limb din cele deja existente sau se va parcurge etapa de adugare a unei limbi noi i setarea acesteia ca implicit; username-ul i parola super administratorului; numele aplicaiei prin care se va reflecta denumirea companiei n toate paginile aplicaiei.

4.2 Descrierea componentelor

n aplicaie sunt integrate mai multe componente care interacioneaz pentru a realiza mai multe activiti specifice unei companii: managementul intrrilor care este definit prin urmtoarele cmpuri: 1. numr registru; 2. data primirii; 3. primit de la compania de la care s-a efectuat intrarea; 4. descriere; 5. autor numele utilizatorului care a realizat aceasta nregistrare; 1. 2. 3. 4. 5. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. 6. managementul ieirilor definit prin: numr registru; data trimiterii; transmis ctre compania ctre care s-a efectuat ieirea; descriere; autor numele utilizatorului care a realizat aceasta nregistrare; managementul contractelor definit prin: numr registru; data emiterii; propriu dac contractul aparine companiei noastre sau nu; contract cu compania cu care s-a efectuat contractul; descriere; contact numele persoanei de mpreun cu care s-a realizat contractul; managementul facturilor definit prin: numr registru; data emiterii; companie numele companiei ctre care se factureaz; contract numrul registrului contractului facturat; suma valoarea facturii; descriere; 54

 1. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4.

managementul contractelor definit prin: numr registru; data emiterii; companie numele companiei ctre care se factureaz; contract numrul registrului contractului facturat; suma valoarea contractului; descriere; managementul chitanelor definit prin: numr registru; data emiterii; companie numele companiei ctre care se chitaneaz; factura numrul registrului facturii chitanate; suma suma chitana; descriere; managementul casieriei definit prin: numr registru; data emiterii; tipul nregistrrii (bon, banc sau mprumut asociai); suma; descriere; emis de numele utilizatorului care a emis nregistrarea; managementul companiilor definit prin: denumire; cui cod unic de nregistrare companie; descriere; contact numr de telefon, adresa e-mail, website, persoan de contact;

4.4 Descrierea managementului aplicaiei

[

1. 2. 3. 1. 2. 3. 1. 2. 3.

managementul utilizatorilor definit prin: nume i prenume; username; privilegii; managementul cererilor de tergeri definit prin: tip nregistrare; solicitat de numele utilizatorului care a solicitat tergerea; motiv motivul introdus de ctre utilizatorul care a efectuat cererea; managementul nregistrrilor de tergere definit prin: tip nregistrare; solicitat de numele utilizatorului care a solicitat tergerea; motiv motivul introdus de ctre utilizatorul care a efectuat cererea; 55

4.3 Gzduirea aplicaiei web

n acest capitol vom detalia modul n care poate fi plasat aplicaia pe internet, urmrind urmtorii pai: alegerea unei companii de gzduire web; instalarea phpMyAdmin pe serverul web de producie, n cazul n care compania de gzduire nu l ofer implicit.

4.3.1 Alegerea unei companii de gzduire web

Alegerea celei mai bune companii pentru gzduirea aplicaiei web este un pas esenial deoarece aceast alegere determin costurile totale de pstrare a aplicaiei funcional i caracteristicile pe care le vom avea la dispoziie. Setul minim recomandat de caracteristici tehnice pe care compania de gzduire web trebuie s le ofere include: PHP 5 (aplicaia conine funcii care nu sunt compatibile cu PHP 4); MySQL 4 (interogrile SQL din aplicaie sunt compatibile att cu MySQL 4.0 ct i cu MySQL 4.1); spaiu pe disc recomandat de 100MB; trafic de cel puin 2GB pe lun; uptime minim garantat 99,99%; n afar de aceste caracteristici, trebuie de asemeni s comparm nivelul de asisten tehnic ce ni se ofer, puterea serverului, durata de via garantat, viteza conexiunii, limitele de transfer i aa mai departe. De asemeni, este important s aflm dac respectiva companie de gzduire este flexibil n privina caracteristicilor pe care ni le ofer, n cazul n care cerinele noastre se modific n timp, cum ar fi de exemplu spaiul pe disc sau traficul lunar. O alt diferen major ntre companiile de gzduire web care asigur suportul pentru PHP i MySQL este platforma pe care o utilizeaz. Este recomandat gzduirea aplicaiei pe platforme Unix, deoarece acestea ofer de obicei performan, stabilitate i securitate mai bune pentru aplicaiile care lucreaz cu Apache, PHP i MySQL. Multe companii de gzduire ofer i instrumente de administrare a bazelor de date, cum ar fi phpMyAdmin. Detaliile tehnice depind de ateptrile noastre visa-vis de aplicaie web folosit.

56

4.3.2 Crearea bazei de date pe serverul de gzduire

Instrumentul pe care l vom utiliza aici este phpMyAdmin. Dup ce avem o instalare funcional a phpMyAdmin, putem utiliza aceast aplicaie pentru a mut baza de date de pe calculatorul nostru pe server.

Figura 28. Panoul de control phpMyAdmin

Prima etap const n utilizarea phpMyAdmin pe calculatorul nostru pentru a exporta structurile bazei de date i datele ntr-un fiier script SQL i apoi s utilizm phpMyAdmin pe serverul de producie pentru a executa scriptul SQL. Paii pentru exportarea bazei de date de pe calculatorul nostru este: 1. selectm baza de date n phpMyAdmin i apoi deschidem pagina Export;

Figura 29. Primul pas pentru portarea bazei de date

57

2. facem click pe legtura Select All de sub caseta cu lista Export;

Figura 30. Pasul 2 de portare a bazei de date

3. ne asigurm c am selectat casetele de validare Structure i Data; 4. selectm butonul radio gzipped, apoi introducem un nume pentru fiierul exportat n caseta care conine n mod implicit _DB_;

5. aps tasta Enter sau facem click pe butonul Go. 6. salvm scriptul SQL pe calculatorul nostru. Urmeaz s localizm ulterior acest fiier pentru a-l putea executa n baza de date de pe server. 7. accesm phpMyAdmin de pe server unde vom crea o nou baz de date, de exemplu o putem defini simc_nume_companie; 8. selectm din meniul din stng baza de date pe care tocmai am creat-o; 9. deschidem pagina Import din partea superioar a paginii; 10. apsm butonul Browse i vom selecta fiierul creat la pasul 6, dup care facem click pe butonul Open;

Figura 31. Finalizarea portrii bazei de date

11. ultimul pas, facem click pe butonul Go, i din acest moment am importat cu succest baza de date pe server;

58

4.3.3 Copierea aplicaiei pe serverul web

Dup ce am importat baza de date pe server, a sosit momentul s copiem aplicaia propriu-zis. De obicei, vom executa acest lucru prin FTP sau folosind instrumentele de ncrcare a fiierelor oferite de panoul de control al companiei de gzduire.

Upload folosind FTP

Sunt disponibile multe programe de gestionare a fiierelor care accept conexiuni FTP (cum ar fi Total Commander, pe care l putem descrca de la adresa http://www.ghisler.com). Pentru a obine o list cu mai muli clieni FTP, putem accesa adresa http://www.dmoz.org/Computers/Software/Clients/FTP. Trebuie s solicitm companiei de gzduite crearea unui cont FTP, acest lucru n condiiile n care nu avem posibilitatea de a ne crea singuri astfel de conturi din panoul de control. Utiliznd aplicaia favorit de gestionare a fiierelor, autentificndu-ne cu username i parol, copiem toate fiierele din folderul n care se afl aplicaia pe calculatorul personal n folderul de pe serverul web unde dorim s instalm aplicaia. Dup copierea fiierelor, trebuie s modificm fiierul de configurarea a aplicaiei includes/config.php, pentru a actualiza cel puin detaliile conectrii la baza de date (server, nume utilizator, baza de date). Vom obine aceste date din panoul de control al serverului de la compania de gzduire web.

Upload folosind HTTP

A doua posibilitate de uploada fiierele pe server este i cea pe care o folosesc cel mai des i pe care o recomand oricrui utilizator, indiferent de nivelul de pregtire n domeniu. Indiferent dac folosim un server partajat sau unul dedicat avem posibilitatea de a instala cPanel, un panou de control care este la rndul su o aplicaie web, dar care este situat la un nivel inferior, ce gestioneaz toate resursele ce le poate pune la dispoziie un server. Aplicaia cPanel vine cu o interfa web, astfel oferindu-ne posibilitatea de control remote. Unul din modulele incluse este de file management; astfel, direct din browser putem manipula fiierele exact cum suntem obinuii pe calculatorul personal. Astfel, putem uploada fiier cu fiier, sau, mai eficient, putem crea o arhiva .zip pe care o vom uploada prin HTTP, urmnd ca ulterior, pe server, s o dezarhivm. Din experiena personal pot afirma faptul c aceast soluie este considerabil mai rapid i mult mai facil de utilizat pentru cei care realizeaz primii pai n acest domeniu.

59

n figura de mai jos puteam vizualiza panoul central, mai precis seciunea File Manager, care ne permit lucrul cu fiiere, directoare: copierea, tergerea, mutarea i acordarea permisiunilor de acces ctre acestea. Pentru ce ne-am propus trebuie s facem click pe butonul de Upload,

Figura 32. Urcarea fiierelor pe web server

La pasul urmtor ne vor fi solicitate fiierele pe care dorim s le uploadm, avnd posibilitatea de a face acest lucru cu mai multe fiiere deodat prin simpla apsare a unui buton browse. Pentru fiecare transfer de fiier avem o reprezentare dinamic ce ne indic numele fiierului, dimensiunea acestuia precum i procentul de upload.

Figura 33. Selectarea arhivelor ce vor fi urcate pe server

La ultimul pas, moment n care arhiva este deja pe web server, nu ne rmne dect s o dezarhivm pentru ca ulterior s realizm setrile i de a porni aplicaia. Dezarhivarea se face prin selecia arhivei pe care tocmai am uploadat-o i apsarea butonului Extract aa cum este reprezentat n figura de mai jos.

Figura 34. Dezarhivarea fiierului

Dup copierea tuturor fiierelor i configurarea fiierului de conectare la baza de date, totul ar trebui s fie pregtit pentru a folosi aplicaia on-line.

60

Capitolul 5

Prezentarea aplicaiei
5.1 Elemente de configurare
Aplicaia de fa poate fi uor instalat i, eventual, ulterior portat pe un alt server printr-un minimum de efort. nainte de rulare este necesar parcurgerea etapei de configurare i anume completarea unor parametri ce vor determina modul de funcionare al aplicaiei. Acest lucru se face prin simpla parcurgere a fiierului config.php, i, acolo unde este cazul, modificarea parametrilor care sunt descrii n continuare: db_host denumirea serverului pe care se instaleaz aplicaia care n procent de 90% este localhost; db_name numele bazei noastre de date, aici purtnd un nume generic aplicaie, dar n practic se recomand folosirea unei denumiri secrete; db_username numele unui utilizator care are privilegii totale de a folosi baza de date curent; db_password parola de acces, n practic este foarte important ca aceast s fie ct mai complex, mai precis s conin cifre, majuscule i cel puin 2 caractere alfanumerice; simc_title numele aplicaiei care de obicei va corespunde cu denumirea companiei care folosete o copie a acestui produs; acest parametru se va regsi un tag-ul title al tuturor paginilor aplicaiei i este o modalitate de a personaliz aplicaia; language limba care este activ n momentul iniial, putnd ulterior a fi modificat de ctre administrator din seciunea multilingvistic; table_prefix prefix folosit n denumirea tabelelor pentru o mai uoar difereniere a tabelelor n cadrul bazei de date din care pot face parte i alte tabele auxiliare;

61

config.php

<?

# begin database define("DB_NAME", define("DB_USERNAME", define("DB_PASSWORD", define("DB_HOST", define("TABLE_PREFIX", define("SIMC_TITLE", define("LANGUAGE", # end database "aplicaie"); "root"); "parol"); "localhost"); "simc_"); "web 2.0 SIMC"); "ro"); ?>

Pentru partea de alegere a unei companii de hosting sau pentru problemele de copiere a aplicaiei pe serverul web, precum i migrarea bazei de date v recomandm s citii capitolul special creat pentru acest lucru.

5.2 Conectarea la baza de date

Conectarea la baza de date se face prin intermediul fiierului db_connect.php care trebuie inclus n orice script care folosete lucrul cu baza de date. Dup cum am menionat mai devreme la partea de configurare, pentru acces am reinut n 4 constante infomaii referitoare la server, numele bazei de date precum i datele de acces ale unui utilizator cu privilegii de administrare a bazei de date. Aplicaia conine foarte multe module i fiiere n general care lucreaz cu baza de date. Efortul conectrii la baza de date este minimizat prin acest procedeu deoarece includerea fiierului este mai rapid dect rescrierea liniilor de conectare ori de cte ori este efectuat un query; totodat se evit folosirea n scripturi diferite a unor conexiuni diferite.

5.3 Autentificarea n aplicaie

Utilizarea aplicaiei se va face folosind orice tip de browser. Accesul se face printr-un sistem securizat pe baz de privilegii, navignd mai nti n pagina de autentificare. Aceasta arat aa cum se poate observa n imaginea de mai jos:

Figura 35. Pagina de autentificare

62

Utilizatorii vor fi ntmpinai de formularul de autentificare unde pe baza username-ului i a parolei unice care li s-a generat de ctre un administrator, sau ulterior modificate de fiecare utilizator n parte, vor avea acces la contul lor unic:
<form method="post"> <div class="login-item"><?=LOGIN_USERNAME?>:</div> <input name="username" class="login-input" type="text" value="<?= ($login_msg==LOGIN_PASSWORD_ERROR ? $_POST["username"] : "")?>" /> <div class="login-item"><?=LOGIN_PASSWORD?>:</div> <input name="password" class="login-input" type="password" /> <input name="submit" class="login-submit" type="submit" value="<?=LOGIN_SUBMIT?>" /> </form>

Este de remarcat faptul c aplicaia vine cu suport multilingvistic; (acest lucru va fi detaliat n subcapitolele urmtoare) se poate observa mai jos faptul c LOGIN_USERNAME, care este o constant a limbajului PHP, va face ca n pagina de login s avem Nume utilizator aa cum LOGIN_SUBMIT va afia Intr n cont.

Figura 36. Mesaje restrictive la autentificare

Modulul de autentificare avertizez utilizatorul n cazul n care efectueaz vreo operaie greit n procesul de intrare n cont, afind mesaje de eroare aa cum se poate observa n imagina de mai sus; acest lucru se realizeaz prin secvena de cod urmtoare:
<? if ($login_msg != "ok" && $login_msg!=""){ ?> <div class="login-error"><?=$login_msg?></div> <? } ?>

unde prin variabila login_msg desemnm prima eroare aprut n sistemul de autentificare; aceasta este implicit ok, iar dac se valideaz toate condiiile impuse, se creaz o nou sesiune i se d acces n aplicaie.

63

5.4 Administrarea utilizatorilor

Aplicaia ofer utilizatorilor care dein drepturi de administrare posibilitatea de editare complet a datelor; n seciunea utilizatori suntem ntmpinai de un tabel cu toi utilizatori existeni n sistem, n dreptul fiecruia sunt bifate privilegiile pe care le au n a folosi anumite pagini ale sistemului, precum i dou opiuni, cea de tergere i cea de editare a profilului unui utilizator.

Figura 37. Modulul de management al utilizatorilor

n imaginea de mai sus este reprezentat pagina Utilizatori. Putem observa faptul c avem o un tabel cu toi utilizatorii din sistem. Pentru fiecare nregistrare avem numele i prenumele persoanei, username-ul precum i privilegiile pe care le deine fiecare. n partea dreapt avem un cmp numit Operaii, dou butoane specifice fiecrui utilizator: primul care iniiaz procedurea de tergere a utilizatorului, iar al doilea care va conduce la editarea utilizatorului respectiv. ncrcarea acestui tabel se face printr-un apel Ajax ataat iniializrii paginii HTML <body onload="loadUsers()">. Definirea acestei funcii se face n fiierul admin.js, iar rezultatul este returnat de loadUsers.php. Doar utilizatorii cu drepturi de administrare au posibilitatea de a vizualiza i edita privilegiile fiecrui utilizator dup cum urmeaz: apsnd butonul edit se va deschide un element de pagin n care putem modifica atribuiile unuia din utilizatorii din tabel, aa cum se poate vedea n figura de ma jos; apsnd butonul de teregere se va deschide un alt element de pagin n care administratorului i se va cere s confirme faptul c dorete cu adevrat s tearg profilul utilizatorului curent; crearea unui nou profil se face folosind seciunea adaug utilizator;

64

Aceste trei proceduri sunt realizate complet prin Ajax, astfel nct utilizatorul nu prsete deloc pagina. Adugarea unor utilizatori noi n sistem este foarte facil, dar restricionat doar la nivelul de administrator. Astfel, orice administrator, navignd n pagina Utilizatori, va putea face click pe caset din partea dreapta adaug utilizator. Imediat se va deschide un formular n care trebuie s completeze datele noului utilizator:

Figura 38. Operaiile posibile asupra unui utilizator

tergerea unui utilizator se realizeazt prin apsarea butonului de tergere din dreptului utilizatorului vizat. Pasul final pentru a terge definitiv contul acelui utilizator este confirmarea dorinei de a terge. n panoul de lucru din dreapta va aprea pe csu aa cum se poate vedea n imaginea de mai sus n care apar datele publice ale utilizatorului vizat.

5.5 Meniuri, navigare i interfaa cu utilizatorul

n capitolul urmtor vom pune accentul pe elementele care sporesc atractivitatea aplicaiei. Vorbim aici de modul n care sunt reprezentate informaiile, de modul de realizare a interfeei cu utilizatorul, butoane, cutii de lucru precum i de elemente care nu sunt percepute n mod implicit de utilizator, dar care mresc performanele aplicaiei.

65

5.5.1 CSS Sprite

n termeni de performan, cea mai mare parte a timpului ncrcrii unei pagini web se cnsum downloadnd diverse componente precum fiisere css, javascript, xml, obiecte flash, applei java, poze etc. Pentru fiecare component este necesar trimiterea unor pachete adiionale (HTTP Requests); un astfel de pachet are 4096bytes. Micornd numrul acestor cereri va conduce la o ncrcare mai rapid a paginii, crend experiena navigrii site-ului mult mai plcuta. Un al doilea mare avantaj al micorrii numrului acestor cereri este i pe partea de server, acest lucru traducnd-se n termeni de performan printr-o solicitare hardware mai redus sau pentru aceeai stressare hardware putem avea mai muli utilizatori. CSS Sprite este o tehnic de a micora numrul acestor cereri pentru poze, fie ele .jpg, .jpeg, .png sau .gif. Odat cu trecerea la web 2.0 site-urile au devenit i mult mai atractive prin estetica lor, lucru realizat de cele mai multe ori prin interfee cu multe butoane colorate, cu umbre i diverse efecte prin introducerea n template-ul paginii a unor poze. Acest lucru se realizeaz prin compactarea unor poze mai mici ntr-o poza mai mare i are cea mai mare eficien atunci cnd pozele mici au dimensiunile proprii sub 3072bytes sau restul mpririi la 4096 este sub 2048(bytes).

Figura 39. CSS Sprite (exemplu)

Ca exemplu s presupunem c am comprimat deja mai multe poze ntr-una singur i n cazul de fa vrem s reprezentm poza din centru. Pentru acest lucru avem nevoie de urmtoarea secven de cod n foaie de stil:
.clas_poz{ margin:0px 0px 0px 0px; width:130px; height:70px; display:block; background:url(poz_comprimat.png) -50px -60px no-repeat; }

66

unde poz_comprimat.png este numele pozei noastre, 130x70 sunt dimensiunile pozei mici, iar clas_poz este numele cu care v-a fi identificat poza n codul HTML n interiorul unui div.
<div class="clas_poz"> <!-- coninut --> </div>

Chiar dac vehiculm fiiere mici, n termeni de performan putem avea ctiguri importante. n tabelul de mai jos prezentm trei cazuri de optimizare: 16 poze 2048bytes/poz 16 3072bytes/poz 16 3840bytes/poz 16 HTTP requests 8 12 15 CSS Sprite requests 50% 25% 6.25% optimizare

Figura 40. Tabel comparativ CSS/HTML reqeusts

care, transpuse pentru trei tipuri de site-uri:

tip site blog site ni motor de cutare vizualizri lunare trafic lunar doar pentru poze/nr. requests 16 15 12 8 3 3010 1,920GB 120MB 480MB 960MB 30106 1,920TB 120GB 480GB 960GB 9 3010 1.920TB 120TB 480TB 960TB trafic fr CSS Sprite economie CSS Sprite
Figura 41. Tabel performane CSS

Urmrind datele din tabel i transpunandu-le n termeni de pia putem deduce c economia de trafic pe care o face Google folosind CSS Sprite pentru mini pozele de pe pagina bine-cunoscutului motor de cutare este mai mare dect ntregul trafic produs primele 3 site-uri din Romnia. Putem concluziona ca dei folosirea CSS Sprite-ului este uneori mai dificil, ctigurile n materie de trafic i de fidelizare a utilizatorilor printr-o ncrcare rapid a paginii pot face ca aceast implementare s merite din plin.

5.5.2 Roll over offect

Este foarte important, n special pentru persoanele care dein cunotine slabe n domeniu, ca aplicaia s fie foarte intuitiv i s necesite un timp foarte scurt de acomodare. Pentru ndeplinirea acestui obiectiv vom discuta n continuare de aspectul vizual al unor butoane. Pentru o aplicaie de uz intens este crucial ca dispunerea butoanelor s fie foarte bine gndit prin amplasarea ancorelor ctre seciunile cele mai importante n

67

centrul cmpului vizual al utilizatorului. De asemeni, tot timpul utilizatorul trebuie s fie contient de ceea ce se ntmpl n pagina web chiar i n momentele n care nu face click. Simpla navigare cu mouse-ul peste un element activ trebuie s-i ofere utilizatorului informaia conform creia efectuarea unui click n acea zon va avea ca rezultat un anumit eveniment. Sincronizarea funcionalitii unui buton cu estetic i mesajul pasiv pe care acesta l ofer trebuie creat ct mai bine cu putin. Din experiena personal, lund n calcul mai multe aspecte cum ar fi aspectul vizual, funcionalitatea oferit, aspecte de trafic sau de indexare n motoarele de cutare, consider faptul c cea mai bun soluie pentru acest obiectiv este realizarea butoanelor printr-un efect numit roll-over.
Cod HTML <div class="butonul_meu"> <span> <a href="#">buton activ</a> </span> </div> Foaia de stil .butonul_meu span{ height:20px; line-height:20px; background:url(layer_stnga.png) no-repeat; } .butonul_meu span:hover{ background:url(hover_layer_stnga.png) no-repeat; } .butonul_meu a{ display:block; color:#000000; background:url(layer_dreapta.png) right no-repeat; } .butonul_meu a:hover{ display:block; text-decoration:none; background:url(hover_layer_dreapta.png) right no-repeat; }

Mai sus sunt dou secvene de cod folosite pentru generarea unui buton, prima n cod HTML care este cea care determin apariia fiecrui buton n pagin, iar al doilea n CSS care definete o singur dat ablonul acelui buton. Practic avem dou straturi suprapuse, un span peste care avem o ancor. Suprapunerea acestor dou straturi creeaz un efectu vizual plcut i totodat pstreaz codul curat i meniul foarte flexibil pentru modificri ulterioare.

68

Avantaje oferite de aceast metod fa de alternative clasice: titlul butonului este text, ceea ce sporete vizibilitatea acelei aplicaii n motoarele de cutare; folosirea unui numr redus de poze, n general 4, sau, combinate cu CSS sprite chiar una singur, fa de metoda clasic n care avem 2 poze pentru fiecare buton; uurina modificrii titlurilor sau adugrii unor butoane noi; nu mai este nevoie crearea pozelor ntr-un mediu special de editare a pozelor; posibilitatea folosirii suportului multilingvistic, prin metoda clasic ar trebui sa avem pentru fiecare buton, 2 poze diferite pentru fiecare limb n parte, o chestiune care ar consuma foarte mult timp ntr-o dezvoltarea ulterioar;

5.5.3 Ajax loading effect

Dup cum am discutat n capitolul 2.3 odat cu introducerea tehnologiei AJAX, a aprut i problema care cnst n faptul c un utilizator, n momentul n care declaneaz un eveniment, nu tie cu exactitate ce se ntmpl, fiind obinuit cu navigarea obinuit, mai precis prsirea paginii. Acest neajuns este realizat printr-un mic artificiu. n pagin, ntr-o locaie ct mai apropiat de poziia acelui element cu care utilizatorul interacioneaz, amplasm un div, de exemplu:
<div class="ajax-loading" id="myDiv"></div>

a crui clas este definit n foaia de stil a astfel:

.ajax-loading{ display:none; background:url(ajax-loading-image.gif); }

acest lucru nseamn c aveam un div care n mod implicit este invizibil i care are ca fundal o poz .gif. Se alege o poz .gif din mai multe motive: spre deosebite de .jpg, .png i .bmp, .gif permite animaie; .gif are dimensiuni foarte reduse, de cele mai multe ori o astfel de imagine este transmis printr-un singur request HTTP; .gif ofer suport pentru transparen, universal acceptat de toate browserele; .png mai ofer transparen, dar necesit preocupri suplomentare pentru a fi acceptat de toate browserele;

69

Mai jos putem urmri o colecie de posibile astfel de poze, car, dei nu se poate observa n aceast poz, sunt dinamice:

Figura 42. Ajax loading effect

La declanarea unui eveniment vom folosi Javascript (folosim funcii care modific n mod dinamic stilul unui element) pentru a face vizibil respectivul div:
document.getElementById("myDiv").style.display="block";

pentru ca atunci cnd requestul utilizatorului este realizat, folosind din nou Javascript vom face din nou invizibil acel div:
document.getElementById("myDiv").style.display="none";

Chiar dac n realitate efectiv n browser nu se ntmpl nimic, utilizatorul, vizualiznd acea imagine dinamic, are impresia de continuitate, lucru ce mrete experiena interacionrii cu aplicaia.

5.5.4 Design-ul aplicaiei

Succesul aplicaiilor web este dat de combinarea tehnologiilor folosite precum i modul n care utilizatorul interacioneaz cu sistemul. n continuare vom vorbi de cel mai palpabil aspect al unei aplicaii web: interfaa vizual. n ultimii ani putem auzi de o nnoire a mediului internetetului, de aa bine cunoscuta trecere la Web 2.0 care de cele mai multe ori este asociat cu stilul de realizare a paginilor web. Chiar dac Web 2.0 este un cadru foarte general ce marcheaz modificri semnificative n evoluia internetului, ne vom concentra atenia asupra aspectului legat de stilizarea paginilor web.

70

Orice aplicaie web trebuie privit precum un produs comercial ce va ajunge s fie folosit de sute, mii de utilizatori. Nu este suficient ca aplicaia noastr s aib funcionaliti excepionale i implementari pe msur, fiind necesar i o bun interfa care va facilita interaciunea utilizatorului cu sistemul. O interfa foarte bun cu utilizatorul se caracterizeaz prin: mesaj de ntmpinare la autentificare, precum i la prsirea sistemului; mesaje de atenionare i indicaie care s fie relizate ntr-un limbaj familiar, dar totodat tehnic i la obiect; cereri de confirmare a unor aciuni eseniale care s nu fie enervante; acces rapid la seciunile importante, meniu bine poziionat i conturat; culori calde care s nu creeze un disconfort atunci cnd aplicaia este folosit o perioad mai ndelungat; butoane stilizate care s indice faptul c utilizatorul se afl ntr-o anumit seciune sau faptul c acionarea unui buton va avea efect navigarea ctre o alt pagin; Odat intrai n cont utilizatorii vor fi primi un mesaj de ntmpinare, n cazul de fa Bine ai venit [nume_utilizator] ! care poate fi modificat ulterior de ctre administrator folosind constanta LOGIN_WELCOME din fiierul lingvistic asociat limbii curente. Meniul principal este poziionat n partea superioar a paginii, avnd o vizibilitate maxim; dup cum se poate observ suntem n seciunea Intrri.

Figura 43. SIMC - meniul principal

Codul HTML generat pentru a realiza aceste meniu este

<ul id="top-nav" class="on-nav-inputs"> <li id="nav-home"> <span><a href="index.php">Acasa</a></span> </li> <li id="nav-inputs"> <span><a href="index.php?page=inputs">Intrari</a></span> </li> <li id="nav-outputs"> <span><a href="index.php?page=outputs">Iesiri</a></span> </li>

71

<li id="nav-contracts"> <span><a href="index.php?page=contracts">Contracte</a></span> </li> <li id="nav-invoices"> <span><a href="index.php?page=invoices">Facturi</a></span> </li> <li id="nav-receipts"> <span><a href="index.php?page=receipts">Chitante</a></span> </li> <li id="nav-accounting"> <span><a href="index.php?page=accounting">Casierie</a></span> </li> <li id="nav-companies"> <span><a href="index.php?page=companies">Companii</a></span> </li> </ul>

implicnd resursele: menu.php, main.css, nav-bg.gif, nav-on-right-bg.gif,

<ul id="top-nav" class="on-nav-<? if(isset($_GET['page']) && in_array($_GET['page'],$pages)) echo $_GET['page']; else if(!isset($_GET['page'])) echo "home"; else echo "none"; ?>"> <li id="nav-home"> <span><a href="index.php"><?=ucfirst(MENU_HOME)= ?></a></span> </li> <? for($i=0;$i<count($pages);$i++){ ?> <li id="nav-<?=$pages[$i]= ?>"> <span><a href="index.php?page=<?=$pages[$i].'"'. ucfirst(constant('MENU_'.strtoupper($pages[$i])))=?></a></span> </li> <? } ?> </ul>

Figura 44. SIMC - submeniu administrator

n figura de mai sus este reprezentat modul de prezentarea al submeniului principal, aici pentru seciunea administratori unde avem subseciunile utilizatori, cereri tergeri i nregistrri terse. Acest submeniu este stilizat prin metoda rollover descris n subcapitolul precedent.

72

Figura 45. Descrie stiluri cutie formular

n imaginea precedent avem un formular tipic folosit n aplicaie. Putem observa faptul c s-a ncercat ct mai mult posibil realizarea acestui formular cu o fereastr tipic a unui sistem de operare, tocmai din dorina de a face aplicaia ct mai familiar i de a minimiza timpul necesar acomodrii cu noua interfa. n acest scop am recreat n aplicaia de fa butoanele de close i submit. n ceea ce privete template-ul paginii de baz a aplicaiei am urmrit cele mai noi tendine n momentul de fa: coluri rotunjite, culori web 2.0 frumos contrastate, poze folosite ca background minimizate, dar care au culori calde care s nu oboseasc ochiul atunci cnd aplicaia este folosit un timp ndelungat;

5.6 Descrierea unor moduri de lucru

Adugarea unei facturi
O procedur foarte frecvent printre operaiile uzuale ale unei companii este crearea de noi facturi. Trebuie tiut faptul c o factur poate fi sau nu asociat unui contract. Prin urmare, navignd n pagina de contracte i acionarea unui buton de creare factur nou trebuie s vizualizm un formular intuitiv cu care printr-un minimum de interacionare s completm datele necesare:

Figura 46. Adugarea unei facturi

73

Editarea unei facturi

Editarea unei facturi se face navignd n pagina facturilor, cutnd i selectnd factura int i fcnd click pe butonul de editare din dreptul nregistrrii. n continuare se va deschide un panou n care vor fi aduse datele deja existente pentru acea nregistrare utilizatorul putnd edita aceste date.

Figura 47. Editarea unei facturi

n figura de mai sus putem vizualiza modul n care se efectueaz aceti pai pe aplicaia real, evideniindu-se simplitatea operaiunii.

tergerea unei facturi

Se poate ntmpla ca o anumita factur s fie creat n mod eronat sau s nu mai fie valabil, caz n care se poate proceda ca la punctul precedent prin simpla editare. Pentru a terge o factur nu trebuie dect s navigm n seciunea facturi s identificm factura pe care dorim s o tergem i s facem click pe butonul rou din dreapta acesteia. Vom fi ntmpinai de o csu de lucru n care ni se va cere s precizm motivul pentru care dorim s efectum aceast tergere. Ulterior vom primi mesajul de confirmare a faptului c factura a fost tears cu succes.

Figura 48. tergerea unei facturi

74

Adugarea unui contract

Una din cele mai frecvente activiti desfurate ntr-o companie este adugarea unui contract nou. Acest lucru este extrem de facil, prin simpla navigare n pagina de contracte de unde printr-un singur click vom apela procedura de adugare contract nou. Ulterior va trebui s completm un formular. Dac acesta este validat se va produce nregistrarea contractului, altfel se poate iei din aceast procedur.

Figura 49. Adugarea unui contract

Editarea unui contract

Editarea unui contract se face navignd n pagina de contracte, cutnd i selectnd contractul int i fcnd click pe butonul de editare din dreptul nregistrrii. La pasul urmtor se va deschide un panou n partea dreapt a paginii n care vor fi aduse printr-un apel Ajax datele deja existente pentru acel contract. Utilizatorul poate modifica tipul contractului: propriu sau nu, persoana de contact, informaiile de intrare pentru contract precum i compania cu care se efectueaz acel contract. Exist posibilitatea de a modifica data, dar nu trebuie s se intercaleze ca index cu celelalte contracte existente.

Figura 50. Editarea unui contract

75

tergerea unui contract

Pentru a terge un contract trebuie s mergem n seciunea contracte. Odat identificat contractul vizat, se va face click pe butonul de tergere din dreptul nregistrrii. La pasul urmtor ni se va deschide o cutie n care ne este solicitat s introducem motivul pentru care dorim s efectum aceast teregere. Apsnd butonul de salveaz datele vom primi confirmarea efecturii cu succes a acestei operaii.

Figura 51. tergerea unui contract

Dup cum a fost proiectat, sistemul nu va permite tergerea unor nregistrri care au alte nregistrri drept fii. Pentru a exemplifica propunem urmtorul exemplu: n sistem s-a creat deja o factura pentru contractul cu Flamingo Computers, motiv pentru care tergerea contractului nu poate fi realizat fr a terge n prealabil toate nregistrrile copii ale acesteia.

Figura 52. Exemplu respingere cerere tergere

Soluionarea cererilor de tergere

Ori de cte ori n sistem se va ncerca tergerea unei nregistrri, fie ea intreare, ieire, contract sau factur, n prealabil se va crea o cerere de tergere care va trebui validat de ctre un administrator. Odat fcut cererea de tergere, acea nregistrare va trece ntr-o stare de ateptare (nu mai pot fi editate sau create alte nregistrri cu referine ctre aceasta) pn la soluionarea cererii.

76

n seciunea cereri tergere, un administrator va vizualiza acele cereri, avnd dou opiuni: prima de a respinge cererea, moment n care aceasta i reia starea iniial i n al doilea caz, de a o valida, moment n care nregistrarea va trece ntr-o stare special numit nregistrri terse.

Figura 53. Anularea unei cereri de tergere

n figura de mai sus administratorul va anula cerere de tergere a contractului respectiv, prin urmare acesta va redeveni vizibil n sistem. Mai jos avem alternativa, mai precis validarea cererii de tergere, care va avea ca efect schimbarea strii respectivei nregistrrii n starea nrgistrri terse.

Figura 54. Confirmarea unei cereri de tergere

Aceste nregistrri terse vor aprea ntr-o seciune special vizibil doar de ctre administratori.

5.7 Suport multilingvistic

O funionalitate esenial a aplicaiei este suportul multilingvistic. Dup cum am menionat n capitolul precedent, n modul implicit avem limba setat n fiierul de configurare config.php (n cazul de fa limba romn). La fiecare execuie a unui script se va ncrca i fiierul de configurare care va ncrca la rndul lui fiierul de limb corespunztor constantei de configurare LANGUAGE. n continuare sunt prezentate cte dou paragrafe din dou fiiere lingvistice, ro.php i en.php.

77

Fiecare fiier lingvistic va fi localizat n subdirectorul language din directorul includes avnd ca nume prescurtarea internaionl de dou caractere: italian it, frana fr, spaniol es, englez en, romn ro, etc. Totodat fiecare fiier va coninte, din motive de precauie, i un header n care va fi precizat limba, denumirea fiierului i eventual numele persoanei care l-a creat.
# SIMC - language [ ro.php ] - romn # login define("LOGIN_TITLE", "Autentificare"); define("LOGIN_USERNAME", "Nume utilizator"); define("LOGIN_PASSWORD", "Parol"); define("LOGIN_SUBMIT", "Intr n cont"); define("LOGIN_USERNAME_ERROR","utilizator inexistent"); define("LOGIN_PASSWORD_ERROR","Parola greit"); define("WELCOME_MESSAGE", "Bine ai venit"); define("LOGOUT_MESSAGE", "Ieire din cont"); # end login # menu define("MENU_HOME", define("MENU_INPUTS", define("MENU_OUTPUTS", define("MENU_CONTRACTS", define("MENU_INVOICES", define("MENU_RECEIPTS", define("MENU_ACCOUNTING", define("MENU_COMPANIES", define("MENU_MYACCOUNT", # end menu

"Acas"); "Intrri"); "Ieiri"); "Contracte"); "Facturi"); "Chitane"); "Casierie"); "Companii"); "Contul meu");

Fiecare cuvnt folosit ca ieire a aplicaiei va fi declarat n fiierul lingvistic asociindu-i o constant. Este de preferat ca numele constantei s fi scris n limba englez deoarece aceasta este de uz internaional, eliminnd astfel situaiile neplcute n care extinderea suportului lingvistic s fie ncetinit este dependent de limba cunoscut de programator. Fiierul en.php este cel mai important fiier lingvistic, deoarece acesta va constitui baza crerii unor alte fiiere lingvistice. O metod foarte simpl de a crea un nou fiier lingivistic const n copierea fiierului en.php i redenumirea copiei n (de exemplu pentru limba francez) fr.php urmnd ca o persoan acreditat s parcurg fiierul i s efectueze traducerile corespunztoare.
# SIMC - language [ en.php ] - english # login define("LOGIN_TITLE", "Authentification"); define("LOGIN_USERNAME", "Username"); define("LOGIN_PASSWORD", "Password");

78

define("LOGIN_SUBMIT", "Log in"); define("LOGIN_USERNAME_ERROR","Incorrect username"); define("LOGIN_PASSWORD_ERROR","Incorrect password"); define("WELCOME_MESSAGE", "Welcome"); define("LOGOUT_MESSAGE", "Log out"); # end login # menu define("MENU_HOME", "Home"); define("MENU_INPUTS", "Inputs"); define("MENU_OUTPUTS", "Outputs"); define("MENU_CONTRACTS", "Contracts"); define("MENU_INVOICES", "Invoices"); define("MENU_RECEIPTS", "Receipts"); define("MENU_ACCOUNTING", "Accounting"); define("MENU_COMPANIES", "Companies"); define("MENU_MYACCOUNT", "My account"); # end menu

5.8 Baza de date

Baza de date este structurat n 10 tabele, toate fiind prefixate cu valoare simc_ definit prin constanta TABLE_PREFIX la configurarea aplicaiei de ctre un utilizator cu drepturi de administrare. Cele 10 tabele sunt: simc_users - folosit pentru pstrarea datelor utilizatorilor: nume, prenume, username i privilegii:
CREATE TABLE IF NOT EXISTS 'simc_users' ( 'id' int(11) NOT NULL AUTO_INCREMENT, 'surname' varchar(30) NOT NULL, 'firstname' varchar(20) NOT NULL, 'username' varchar(30) NOT NULL, 'password' varchar(32) NOT NULL, 'privileges' varchar(50) NOT NULL, PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=32;

simc_pages - conine nregistrri pentru modulele existente i modul de acces; de exemplu cele marcate cu 1 pot fi utilizate doar de ctre administratori, cele cu 0 fiind de uz general:
CREATE TABLE IF NOT EXISTS 'simc_pages' ( 'id' int(11) NOT NULL, 'name' varchar(20) NOT NULL, 'admin' int(1) NOT NULL, PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

79

 simc_companies tabela ce conine informaii despre companiile cu care sistemul interacioneaz: denumire, descriere, contact;
CREATE TABLE IF NOT EXISTS 'simc_companies' ( 'id' int(4) NOT NULL AUTO_INCREMENT, 'name' varchar(50) NOT NULL, 'information' text NOT NULL, 'number' varchar(50) NOT NULL, 'contact' text NOT NULL, 'user_id' int(3) NOT NULL, 'visibility' int(1) NOT NULL, PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=10 ;

simc_delete tabela n care sunt salvate cererile de teregere a nregistrrilor de orice tip, precum i id-ul nregistrrilor care au fost trimise pentru editare: tipul nregistrrii, id-ul nregistrrii respective, motivul pentru care a fost tears sau propus spre tergere;
CREATE TABLE IF NOT EXISTS 'simc_delete' ( 'id' int(4) NOT NULL AUTO_INCREMENT, 'page_name' varchar(25) NOT NULL, 'item_id' int(4) NOT NULL, 'reason' varchar(250) NOT NULL, 'author_id' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=27 ;

simc_inputs intrrile sistemului: numr registru, descriere, numele companiei, date i autorul nregistrrii;
CREATE TABLE IF NOT EXISTS 'simc_inputs' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=12 ;

80

 simc_outputs ieirile sistemului: numr registru, descriere, numele companiei, date i autorul nregistrrii;
CREATE TABLE IF NOT EXISTS 'simc_outputs' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;

simc_contracts contractele realizate n sistem coninnd date despre numrul registrului, descriere, numele persoanei de contact, tipul contractului, data i numele utilizatorului care a ncheia contractul respectiv;
CREATE TABLE IF NOT EXISTS 'simc_contracts' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'person' varchar(50) NOT NULL, 'own' int(1) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;

simc_invoices conine informaii despre facturile din sistem: numrul registrului, descriere, tipul contractului sau numrul registrului contractului asociat, data i numele utilizatorului care a realizat nregistrarea;
CREATE TABLE IF NOT EXISTS 'simc_invoices' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'sum' decimal(12,2) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=7 ;

81

 simc_receipts sau tabela de chitane conine numrul registrului chitanelor, descriere, numrul registrului facturii asociate, suma, data, numele utilizatorului care a emis-o;
CREATE TABLE IF NOT EXISTS 'simc_receipts' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'sum' decimal(12,2) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;

simc_accounting este tabela care se ocup cu nregistrrile casieriei, conine numrul registrului, descriere, tipul nregistrrii, suma, data i numele persoanei care a emis-o;
CREATE TABLE IF NOT EXISTS 'simc_accounting' ( 'id' int(8) NOT NULL AUTO_INCREMENT, 'register' int(11) NOT NULL, 'description' text NOT NULL, 'excerpt' int(11) NOT NULL, 'sum' decimal(12,2) NOT NULL, 'author' int(11) NOT NULL, 'date' date NOT NULL, 'document' int(11) NOT NULL, 'visibility' int(1) NOT NULL DEFAULT '1', PRIMARY KEY ('id') ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=8 ;

5.9 Structura directoarelor i a fiierelor

Orice aplicaie web de dimensiuni medii i mari trebuie s ia n consideraie numrul foarte mare de fiiere cu care lucreaz i s optimizeze structura fiierelor. O structur eficient este cea n care gruparea fiierelor se face dup criterii prestabilite, cum ar fi de exemplu: tipul fiierelor este recomandat ca fiierele de acelai tip s fie localizate n acelai folder, astfel tiindu-se rapid unde se gsete un anumit fiier, atunci cnd se impune o modificare n sistem; n cazul de fa am structurat toate pozele de uz general .bmp, .jpeg, .jpeg, .png, .gif etc. n folderul images;

82

 clasa fiierelor - avem fiiere .js de uz general n folderul javascript, dar i n folderul requests, deoarece cele din urm au o utilizare aparte, i, fiind tratate diferenial, au fost introduse ntr-un folder separat; securitate fiierelor - n funcie de nivelul de acces, putem securiza aplicaia la nivel de folder, eliminnd eventuale vulnerabiliti; aici este cazul folderului includes n care avem date confideniale, spre deosebite de folderul images n care avem doar nite simple poze utilizate la reprezentarea aplicaiei; n continuare este prezentat structura directoarelor i fiierelor folosite:
IMAGES INCLUDES *.jpeg LANGUAGE config.php footer.php menu.php JAVASCRIPT accounting.js contracts.js main.js PAGES accounting.php contracts.php inputs.php invoices.php myaccount.php REQUESTS addInput.php addReceipt.php *.png en.php; content.php functions.php top.php admin.js inputs.js outputs.js companies.php companies.js invoices.js receipts.js] configuration.php *.gif ro.php db_connect.php init.php

delete_requests.php deleted_records.php main.php receipts.php addInvoice.php addUser.php users.php addContracts.php addOutput.php cancelDelete.php

addAccounting.php addCompany.php

confirmDelete.php confirmRecord.php deleteAccounting.php deleteCompany.php deleteContract.php deleteInput.php editAccounting.php editCompany.php editInvoice.php editUser.php editContract.php editOutput.php editInput.php editReceipt.php deleteInvoice.php deleteOutput.php deleteReceipt.php deleteUser.php

loadDeleteRequests.php loadInvoices.php loadUsers.php

loadCompanies.php loadDeletedRecords.php loadContracts.php loadInputs.php loadCompanies.php loadReceipts.php loadAccounting.php STYLES UPLOADS / index.php login.php login.css main.css

83

Capitolul 6

Dezvoltri ulterioare
Aplicaia de fa, Sistem integrat pentru managementul unei Companii, este conceput de aa natur nct s faciliteze dezvoltri ulterioare. Tocmai datorit bunei proiectri aplicaia este relativ uor de ntreinut, modificat i dezvoltat. n partea de proiectare s-a inut cont de urmtoarele aspecte privind viitoarele modificri aduse aplicaiei: evoluia tehnologic, actualizarea codului la cerinele impuse de client; extinderea i personalizarea funcionalitilor; portarea modelului aplicaiei n alte domenii de interes;

6.1 Evoluia tehnologic

Este foarte probabil, i tocmai din acest motiv trebuie luat n considerare, c un client care are experien n folosirea unor anumite medii de dezvoltare s solicite ca unele module sau seciuni ale aplicaiei s fie rescrise dup un specific propriu sau s permit interoperabilitatea cu mediile cunoscute. Acest lucru poate fi realizat realiznd un API, implic un efort substanial de realizare, dar, pe termen lung, este soluia optim pentru problema mai sus menionat. Un alt aspect foarte important este urmrirea evoluiei versiunii limbajelor de programare, i actualizare, acolo unde este cazul, a funciilor i claselor care au devenit obsolete sau au fost dezvoltate alte metode mai eficiente pentru rezolvarea unor probleme. n privina evoluiei tehnologice, orice programator trebuie s in cont de tendinele timpului prezent, un exemplu foarte concret ar fi modul n care sunt realizate interfeele grafice cu utilizatorii - este recomandat ca acestea s fie schimbate la un anumit interval de timp pentru pstrarea atractivitii.

84

6.2 Extinderea funcionalitilor

Chiar dac n momentul actual aplicaia beneficiaz de multe funcionaliti, ntotdeauna se vor gsi lucruri noi care pot fi adugate pentru satisfacerea necesitilor clienilor. Vom vedea n continuare dou aspecte momentan neimplementate, dar care sunt frecvent folosite n aplicaiile majore: implementarea unui sistem de abloane folosind Smarty pentru a uura procesul de personalizare a aspectului aplicaiei de la un client la altul i un modul de pli online, n cazul de fa PayPal.

Lucrul inteligent cu Smarty

Faptul c PHP este simplu i este uor de nceput s lucrm cu el poate fi un dezavantaj n momentul scrierii programului datorit folosirii metodei directe care const n amestecarea instruciunilor PHP cu instruciunile HTML. Amestecarea prii de program PHP cu taguri HTML prezint dou dezavantaje importante: aceast tehnic duce adesea la obinerea unui program lung, complicat i greu de gestionat. Suntem familiari cu acele fiiere surs kilometrice, care cuprind un amestec neplcut de PHP i HTML, greu de suportat pentru ochi i imposibil de neles chiar i dup un timp scurt de la prima implementare; aceste fiiere amestecate fac obiectul muncii programatorilor i proiectanilor software, complicnd colaborarea mai mult dect este necesar. Astfel cresc de asemenea ansele ca designerul s introduc hibe n logica programului n timp ce lucreaz la modificrile estetice. Aceste tipuri de probleme conduc la dezvoltarea motoarelor de abloane, care ofer cadre ce separ partea de prezentare de macheta HTML static. Smarty este cel mai apreciat i mai performant motor de abloane pentru PHP. Scopul su principal este s ofere o cale mai simpl de a separa logica aplicaiei (codul PHP) de codul su de prezentare (codul HTML).

Pli electronice
Pentru mediul business este foarte important existena unei modaliti de a efectua pli online chiar din interfaa aplicaiei. Exist numeroase companii care ofer acest tip de serviciu, alegerea uneia dintre acestea fcndu-se att n funcie de specificul companiei clientului ct i de interoperabilitatea cu aplicaia web.

85

Cel mai comod serviciu din punctul de vedere al programatorilor este PayPal, care este un sistem web bazat pe conturi, permind oricrui utilizator care deine o adres de e-mail s trimit i s primeasc n siguran bani on-line utiliznd cartea de credit sau contul din banc. Astfel, prin intermediul PayPal, vizitatorul, n loc s-i plteasc direct beneficiarului aplicaiei, pltete ctre PayPal, care ulterior vireaz banii ctre destinatar. Dei PayPal ncaseaz comision pentru acest serviciu, el este foarte folosit deoarece este universal acceptat, este extrem de sigur i ofer un foarte bun suport web pentru cele mai folosite limbaje de programare.

86

Capitolul 7

Concluzii
n aceast lucrare am prezentat o aplicaie care realizeaz managementul unei companii. Am identificat necesitatea unei aplicaii care s rezolve n mod foarte simplist i foarte eficient operaiile tipice care apar n cadrul unei companii mici i mijlocii. Datorit cunotiinelor dobndite n programare web am decis c cea mai bun metod de a implementa o astfel de aplicaie este cea de a folosi PHP & MySQL mpreun cu Ajax i CSS. Aceast decizie este susinut de faptul c o astfel de abordare ofer cea mai bun flexibilitate n ceea ce privete evoluia aplicaiei. Urmrirea precis a unui model de dezvoltare, n cazul de fa model incremental, s-a dovedit foarte eficient n ducerea la bun sfrit a proiectului ntr-un timp foarte redus. Dei iniial aplicaia prea s necesite un timp mai ndelungat de implementare, buna specificare a cerinelor i parcurgerea corect a celor trei ciclii de via ai proiectului impui de la bun nceput, a fcut ca implementarea s fie foarte eficient i n anumite etape chiar devansat. Timpul economisit a fost foarte bine venit, fiind folosit pentru realizarea unei interfee cu utilizatorul foarte prietenoas, realiznd un aspect foarte plcut al meniurilor, spaiului de lucru, formulare care se apropie foarte mult de design-ul aplicaiilor desktop. Am reuit s integrez totodat i tehnologii noi care sporeasc i mai mult interaciunea utilizatorului cu aplicaia. Am denumit aceast lucare Sistem integrat pentru managementul unei companii tocmai datorit faptului c aplicaia nglobeaz ntr-un singur loc mai multe module care de cele mai multe ori se regsesc separat n aplicaiile tipice. Un aspect foarte important de care am inut cont nc din etapa de proiectare a fost acela de a asigura posibilitatea extinderii aplicaiei; acest lucru fiind realizat prin crearea unui ablon de creare a modulelor.

87

Realizarea acestui proiect a necesitat un efort considerabil din partea mea, fiind o adevrat provocare, acest lucru datorat i faptului c implementarea a pornit de la zero - nu am folosit nicio bibliotec ce ar fi putut uura munca pe alocuri. Sistemul integrat pentru Managementul unei Companii se remarc prin: robustee - face fa lucrului intens, nu necesit ntreinere off-line, sau altfel spus este dependente funcional doar de arhitectura hardware; performant - codul este gndit, implementat i minimizat cu atenie; ncrcarea serverului este optimizat prin tehnologii specifice; aspect foarte prietenos care necesit un timp extrem de mic de nvare. Aplicaia de fa are i conotaii comerciale fiind o unealt care aduce mbuntiri att la nivel funcional ct i principial unor aplicaii deja existente cu ajutorul cror i desfoar activitatea numeroase companii din Romnia. Acest aspect m poate motiva ca pe viitor s mbuntesc aplicaia i de a o oferi pe pia ca un produs comercial sub form de licen. Pentru realizarea acestui proiect am folosit cunotine dobndite la anumite cursuri din cadrul Facultii de Automatic i Calculatoare: Baze de date; Ingineria Sistemelor de Programe; Management de Proiect; Aplicaii Multimedia; Aplicaii Web; Interfee Grafice cu Utilizatorul; precum i experiena acumulat din proiectele-tem a cror aplicaie a avut o implementare n medii de programare de tip web.

88

Bibliografie
[1] Luke Welling, Laura Thomson, 2008, PHP and MySQL Web Development, a 4-a ediie, s.l., Addison-Wesley Professional; [2] Larry Ullman, 2007, PHP 6 and MySQL for Dynamic Web Sites: Visual QuickPro Guide, s.l., Peachpit Press; [3] Cristian Darie, Mircea Bucic, 2006, PHP 5 i MySQL pentru comer electronic, ghid practic pentru construirea unui magazin virtual, Bucureti, Editura Teora; [4] William Steinmetz, Brian Ward, 2007, Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems, prima ediie, s.l., No Starch Press; [5] Larry Ullman, 2007, Building a Web Site with Ajax: Visual QuickProject Guide, a doua ediie, s.l., Peachit Press; [6] Jeremy Keith, 2007, Bulletproof Ajax, prima ediie, s.l., New Riders Press; [7] David Crane, Eric Pascarellor, Darren James, 2005, Ajax in Action (Illustrated), prima ediie, Manning Publications; [8] Gottfried Vossen, Stephan Hagemann, 2007, Unleashing Web 2.0: From Concepts to Cretivity, prima ediie, s.l., Morgan Kaufmann Press; [9] Gwen Solomon, Lynne Schrum, 2007, Web 2.0: New Tools, New Schools, prima ediie, s.l., International Society for technology in Education;

[10] Tom Funk, 2008, Web 2.0 and Beyond: Understanding the New Online Business Models, Trends and Technologies, s.l., Praeger Press; [11] Andrew King, 2008, Website optimization: Speed, Search Engine & Conversion Rate Secrets, prima ediie, s.l., O'Reilly Media, Inc.;

89

[12] Michael Bowes, 2007, Pro CSS and HTML Design Patterns, prima ediie, s.l., Apress Press; [13] Chris Shiflett, 2005, Essential PHP Security, prima ediie, s.l., O'Reilly Media, Inc.; [14] William Ballad, 2009, Securing PHP Web Applications, prima ediie, s.l., Addison-Wesley Professional Press; [15] Bob Boiko, Duane Nickull, 2004, Content Management Bible, prima ediie, s.l., Willey Press; [16] Roger Baran, Robert Galka, Daniel Strunk, 2007, Principles of Customer Relationship Management, prima ediie, s.l., Sout-Western College Press; [17] Wikipedia.org, Content Management System, http://en.wikipedia.org/ wiki/Content_Management_System, la data de 1 iulie 2009; [18] Wikipedia.org, Customer Relationship Management, http://en.wikipedia. org/wiki/Customer_Relationship_Management, la data de 1 iulie 2009; [19] Avangate, Search Engine Optimization Autdit, http://www.avangate .com/ seo-services/seo-audit.php, la data de 1 iulie 2009; [20] CSS Tricks, CSS Sprites, What They Are And How to Use Them, http://css-tricks.com/css-sprites-what-they-are-and-how-to-use-them/, la data de 1 iulie 2009; [21] CSS Globe, CSS Sprites And Rounded Corners, http://cssglobe.com/ post/3714/css-sprites-rounded-corners, la data de 1 iulie 2009;

90

Index figuri
Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 1. Descrierea unui stil n CSS ................................................................... 8 2. Tabel celebru privind evoluia internetului ........................................... 9 3. Tag cloud: Universul Web 2.0 - cuvinte cheie......................................10 4. Distribuia Web 2.0 n viaa de zi cu zi ...............................................11 5. Structura ierarhic JavaScript .............................................................23 6. Modelul AJAX, cerere-rspuns ............................................................26 7. Diagrama cazurilor de utilizare ............................................................36 8. Modelul incremental de dezvoltare software ........................................38 9. Modelul pipeline de dezvoltare a unui proces.......................................39 10. SIMC nucleu, primul ciclu de via....................................................40 11. SIMC, al doilea ciclu de via ............................................................40 12. SIMC, ciclul de via final .................................................................41 13. ablon realizare module .....................................................................42 14. Autentificare unui utilizator...............................................................44 15. Adugarea unui utilizator ..................................................................44 16. Editarea privilegiilor unui utilizator...................................................45 17. tergerea unui utilizator.....................................................................45 18. Adugarea unui contract....................................................................46 19. Editarea unui contract .......................................................................46 20. tergerea unui contract ......................................................................47 21. Adugarea unei facturi.......................................................................47 22. Editarea unei facturi ..........................................................................48 23. tergere factur..................................................................................48 24. Soluionarea cererilor de tergere .......................................................49 25. SIMC 2.0 - nucleu ..............................................................................50 26. SIMC 2.0 - bilioteca de module ..........................................................51 27. SIMC 2.0 - comunitatea de afaceri.....................................................51 28. Panoul de control phpMyAdmin ........................................................57 29. Primul pas pentru portarea bazei de date ..........................................57 30. Pasul 2 de portare a bazei de date .....................................................58

91

Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura

31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54.

Finalizarea portrii bazei de date.......................................................58 Urcarea fiierelor pe web server..........................................................60 Selectarea arhivelor ce vor fi urcate pe server ....................................60 Dezarhivarea fiierului........................................................................60 Pagina de autentificare ......................................................................62 Mesaje restrictive la autentificare.......................................................63 Modulul de management al utilizatorilor ...........................................64 Operaiile posibile asupra unui utilizator ...........................................65 CSS Sprite (exemplu).........................................................................66 Tabel comparativ CSS/HTML reqeusts .............................................67 Tabel performane CSS ......................................................................67 Ajax loading effect .............................................................................70 SIMC - meniul principal.....................................................................71 SIMC - submeniu administrator.........................................................72 Descrie stiluri cutie formular..............................................................73 Adugarea unei facturi.......................................................................73 Editarea unei facturi ..........................................................................74 tergerea unei facturi .........................................................................74 Adugarea unui contract....................................................................75 Editarea unui contract .......................................................................75 tergerea unui contract ......................................................................76 Exemplu respingere cerere tergere ....................................................76 Anularea unei cereri de tergere .........................................................77 Confirmarea unei cereri de tergere....................................................77

92