Suport Curs UIA

UNIVERSITATEA BABE-BOLYAI, CLUJ-NAPOCA Centrul de Formare Continu i nvmnt la Distan Facultatea de tiine Economice i Gestiunea Afacerilor Specializarea: Informatic
Economic Disciplina: Utilizarea Internetului n Afaceri
SUPORT DE CURS
ANUL III Semestrul 2
ClujNapoca 2010
Informaii generale
Date de identificare a cursului Date de contact ale titularului de curs: Nume: Buchmann Robert Andrei Birou: 436, sediul FSEGA Telefon: 40 + 0264-41.86.52/3/4/5 Fax: 40 + 0264-41.25.70 E-mail: robert.buchmann@econ.ubbcluj.ro Consultaii: Luni 14-16, Mari 14-16
Date de identificare curs i contact tutori: Denumirea cursului: Utilizarea Internetului n Afaceri Tutore: Lect.Dr. Buchmann Robert Andrei E-mail secundar: buchmannr@yahoo.com
Condiionri i cunotine prerechizite Cursul nu are condiionri prerechizite. Cunotinele prerechizite care pot facilita asimilarea materialului sunt legate de proiectarea siteurilor Web i stpnirea limbajelor HTML, JavaScript i CSS la un nivel mediu. Sugerm ca nainte de parcurgerea materialului s se identifice urmtoarele cunotinele prerechizite: Concepte de baz: format, stil, hiperlegtur; Abiliti legate de dezvoltarea Web: creare de stiluri, validare de formulare. Descrierea cursului Cursul prezint tehnologiile ce asigur interoperabilitatea sistemelor informatice pentru afaceri on-line, cu accent pe modelul AJAX, dominant n contextul Web 2.0. n acest scop se urmrete familiarizarea cu tehnologiile ce stau la baza AJAX: JavaScript, DOM; CSS, XML, JSON i o serie de biblioteci de nalt productivitate (Dojo, Prototype, Scriptaculous). Datorit audienei int a cursului, primul modul va asigura fixarea sintaxei XML cu referine la cunotinele prerechizite legate de limbajele de marcare i HTML, apoi se trece la dezvoltarea de deprinderi practice n exploatarea tehnologiilor. Tehnologiile vizate sunt de tip open-source i standarde WWW, fiind accesibile gratuit utilizatorilor i implicit studenilor. Cursul trece n revist i o serie de vocabulare XML strict orientate spre afaceri, precum XBRL. Piaa muncii din Romnia pe domeniul Web indic o tendin de migrare dinspre siteurile clasice, Thin Client, spre siteurile bazate pe AJAX i XML. Primele dou module ale cursului au un caracter puternic tehnic, n timp ce ultimul model ofer o imagine sintetic asupra modelelor de afaceri ce pot avea de ctigat din implementrile prezentate. Organizarea temelor n cadrul cursului Ordinea temelor abordate de curs, conform structurii materialului didactic ce va fi disponibil pe platforma software de nvmnt la distan: https://portal.portalid.ubbcluj.ro/
Modulul I. Limbajul XML 1.1. Marcatori XML 1.2. XML i HTML 1.3. Prelucrarea informaiilor XML 1.4. Validarea informaiilor XML 1.5. Sintaxa XML 1.6.Principiile DOM 1.7. Vocabulare XML orientate spre afaceri Modulul II. Modelul AJAX 2. Paradigma Rich Client i modelul AJAX 2.1.Introducere n AJAX 2.2. Fundaia AJAX 2.3. Platforme i biblioteci AJAX 2.4. Interfaa cu utilizatorul Modulul III. Modele de afaceri pe Internet 3. Categorii de afaceri pe Internet 2
3.1. Concepte de e-afaceri 3.2. Bariere n calea succesului comerului electronic 3.3. Tipologia pieelor electronice globale 3.4. Categorii de tranzacii electronice 3.5. Modele de afaceri electronice 3.6. Caracteristici ale comerului electronic 3.7. Componentele comerului electronic 3.8. Arhitectura de baz 3.9. Managementul relaiei cu clienii 3.10. Managmentul liniei de aprovizionare 3.11. Modaliti de plat - Contul de comerciant Pentru paginarea temelor, recomandm consultarea cuprinsului din partea a doua a materialului de fa. Formatul i tipul activitilor implicate de curs Cursul va fi prezentat prin activiti tutoriale periodice programate conform orarului facultii. Prin adresele de e-mail oferite sau la sediul facultii, titularul i tutorii cursului stau la dispoziia studenilor pentru consultaii on-line sau fa n fa n afara activitilor periodice preprogramate. Se ncurajeaz studiile de caz legate de locul de munc al acelor studeni care sunt deja angajai n domeniu. Activitile tutoriale sunt, pentru studentul la distan, facultative i nu afecteaz nota acestuia, obinut strict prin forma indicat: examen scris, lucrri de control i proiect practic. Totui, ncurajm participarea interactiv la activitile tutoriale n special pentru dezvoltarea incremental a proiectului practic. Materiale bibliografice obligatorii BUCHMANN ROBERT, Conceperea, proiectarea i realizarea afacerilor pe Internet, Ed. Risoprint, Cluj Napoca, 2004; BUCHMANN ROBERT, Rolul XML n interoperabilitatea sistemelor informatice pentru afaceri, Ed. Risoprint, Cluj Napoca, 2007; CRANE DAVE et al., "AJAX in Action", Manning, 2005 CRANE DAVE et al., "Prototype and Scriptaculous in Action", Manning, 2007 PHILIPS L.A., XML, Ed.Teora, 2001 ROCA, GH.I et al., Comer electronic-Concepte, tenologii i aplicaii, Editura Economic, Bucureti, 2004 RUSU L., ARBA R., BREFELEAN P., MUREAN L., BUCHMANN R., VERE O Modele de afaceri pe Internet, Ed. Risoprint, Cluj-Napoca, 2007
Materialele sunt accesibile la biblioteca facultii, la biblioteca catedrei sau pot fi puse la dispoziie de ctre titularul de curs. Materiale i instrumente necesare pentru curs Laborator dotat cu calculatoare i sistem de operare Windows, videoproiector, materialul bibliografic, instrumente software gratuite (browser, Notepad, biblioteci disponibile gratuit pe Internet). Calendar al cursului Sunt estimate 2 ntlniri preprogramate pe semestru, cu datele i locaiile afiate pe site-ul facultii la nceputul semestrului. Premergtor fiecrei ntlniri se recomand parcurgerea materialului de fa, pe module pentru a asigura cursivitatea discuiilor. Coninutul acestor ntlniri va fi, n ordine: Prima ntlnire discuii pe marginea modulului I; A doua ntlnire discuii pe marginea modulului II i III, dezvoltare proiect, lucrare control pe marginea modulului I; Politica de evaluare i notare (orientativ - 1 pagin) Proiect 40% din not: 3
Coninut: Dezvoltarea unui site Web prin 3 metode: Folosind standarde WWW Folosind standarde WWW pe baza modelului AJAX Folosind instrumente comerciale (Frontpage, Dreamweaver) Evaluare teoretic 30% din not Coninut: ntrebri cu rspuns deschis, de dificultate i pondere n not echitabile (1 punct pe ntrebare). Evaluare continu (teme i lucrri de control verificate n timpul semestrului) 30% din not Nivelul minim pentru promovarea examenului este dat de obinerea notei 5 la fiecare din primele dou pri (practic i teoretic) i a mediei 5 pe ansamblu. Primele dou probe vor avea loc la datele programate pentru examen, la sediul facultii. Notele vor fi acordate n aceeai zi, comunicate personal fiecrui student cu posibilitate de contestare imediat. Nu se vor accepta proiecte practice sau participri la examen la alte date dect cele programate. Elemente de deontologie academic Tentativele de fraudare att la examen scris ct i n dezvoltarea proiectului practic vor fi pedepsite prin anularea examenului i aplicarea regulamentului instituional. Nu este admis n timpul examenului utilizarea mijloacelor de comunicaie. Studeni cu dizabiliti E-mail de contact pentru situaii deosebite i suport acordat studenilor cu dizabiliti: robert.buchmann@econ.ubbcluj.ro Se vor recomanda soluiile de asigurare a accesibilitii pentru persoanele cu dizabiliti, oferite de sistemul de operare Windows. Strategii de studiu recomandate Recomandm n ordine: parcurgerea materialului de fa i contactarea tutorilor pentru orice nelmuriri; parcurgerea bibliografiei obligatorii; cercetarea individual pe tema cursului, folosind Internetul; consultarea documentaiei i specificaiilor WWW ale tehnologiilor implicate.
Cuprins
Modulul I. Limbajul XML ............................................................. 7 1. Elemente introductive de XML ............................................... 8
1.1. Marcatori XML .............................................................................................................. 8 1.2. XML i HTML ............................................................................................................. 10 1.3. Prelucrarea informaiilor XML ..................................................................................... 11 1.4. Validarea informaiilor XML ....................................................................................... 13 1.5. Sintaxa XML ................................................................................................................ 15 1.6.Principiile DOM ............................................................................................................ 20 1.7. Vocabulare XML orientate spre afaceri ....................................................................... 22
Modulul II. Modelul AJAX ......................................................... 28 2. Paradigma Rich Client i modelul AJAX ................................ 29
2.1.Introducere n AJAX ..................................................................................................... 29 2.2. Fundaia AJAX ............................................................................................................. 35 2.2.1. JavaScript.............................................................................................................. 35 2.2.2. XML i DOM ....................................................................................................... 39 2.2.3. XML DOM versus HTML DOM ......................................................................... 47 2.2.4. Obiectul XHR ....................................................................................................... 48 2.2.5. Cadrele interne invizibile ...................................................................................... 52 2.3. Platforme i biblioteci AJAX ....................................................................................... 55 2.3.1. Rolul platformelor AJAX ..................................................................................... 55 2.3.2. Comunicarea cu serverul prin pachetul Dojo ........................................................ 56 2.3.3. Comunicarea cu serverul prin biblioteca Prototype ................................................... 69 2.4. Interfaa cu utilizatorul ................................................................................................. 74 2.4.1. Manipularea interfeei cu utilizatorul prin biblioteca Prototype ........................... 75 2.4.2. Manipularea interfeei cu utilizatorul prin biblioteca Script.aculo.us ................... 80
Modulul III. Modele de afaceri pe Internet................................. 87 3. Categorii de afaceri pe Internet ............................................ 88

3.1. Concepte de e-afaceri ................................................................................................... 88 3.2. Bariere n calea succesului comerului electronic ......................................................... 92 3.3. Tipologia pieelor electronice globale .......................................................................... 93 3.4. Categorii de tranzacii electronice ................................................................................ 94 3.5. Modele de afaceri electronice ....................................................................................... 96 3.6. Caracteristici ale comerului electronic ....................................................................... 99 3.7. Componentele comerului electronic .......................................................................... 100 3.8. Arhitectura de baz ..................................................................................................... 100 3.9. Managementul relaiei cu clienii ............................................................................... 101 3.10. Managmentul liniei de aprovizionare ....................................................................... 102 3.11. Modaliti de plat - Contul de comerciant .............................................................. 103
Anexe ..................................................................................... 106

Bibliografie obligatorie ..................................................................................................... 106 Bibliografie opional ........................................................................................................ 106 Glosar ................................................................................................................................ 106
Biografia titularului de curs .................................................... 110
Obiectivele generale ale cursului de fa sunt date de detalierea urmtoarelor aspecte legate de proiectarea Web: Fixarea terminologiei XML i a celei specifice aplicaiilor AJAX; Cunoaterea modelelor consacrate de afaceri pe Internet i a vocabularelor XML orientate spre afaceri; Asimilarea cunotinelor necesare realizrii de pagini Web cu tehnologiile XML, CSS i AJAX; Asimilarea deprinderilor practice n utilizarea depanatorului Firebug
Modulul I. Limbajul XML

Sumar
Modulul I. Limbajul XML 1. Elemente introductive de XML

1.1. Marcatori XML 1.2. XML i HTML 1.3. Prelucrarea informaiilor XML 1.4. Validarea informaiilor XML 1.5. Sintaxa XML 1.6. Principiile DOM 1.7. Vocabulare XML orientate spre afaceri Obiective Fixarea terminologiei specifice limbajelor de marcare Asimilarea elementelor limbajului XML Asimilarea tehnicilor de procesare XML prin modelul DOM Asimilarea de cunotine privind vocabularele XML orientate spre afaceri
Recomandri Angajarea studenilor n verificare de exemple Se recomand analiza studiilor de caz prezentate i identificarea altora n sfera on-line Se recomand discuii pe marginea trend-urilor din proiectarea Web
Rezultate ateptate nelegerea rolului limbajelor de marcare i a metalimbajelor n interoperabilitatea sistemelor informatice pentru afaceri; Identificarea clar a conceptelor cheie din XML; Formarea deprinderilor practice de procesare XML prin DOM.
1. Elemente introductive de XML

1.1. Marcatori XML
Limbajul XML i vocabularele sale i propun s ofere n acelai timp posibiliti de formatare a documentelor, de structurare, de caracterizare semantic a informaiei, precum i de procesare a lor. Astfel, exist o ambiguitate general legat de "care este scopul XML?" Rspunsul cel mai corect este c scopul XML este cel pe care suntem capabili s i-l atribuim n calitate de receptori. XML are posibiliti de exploatare nelimitate datorit faptului c este un metalimbaj. Aceasta nseamn c standardul XML nu ofer un set fix de instruciuni ca limbajele obinuite, ci ofer: un set de reguli sintactice, regulile de bun formare, care trebuie respectate de orice document XML i care impun structura pe care trebuie s o respecte orice marcator XML; un limbaj auxiliar, Document Type Definition (DTD), care permite definirea altor limbaje (vocabulare), prin pentru definirea instruciunilor acestora (marcatori, atribute) i a modului lor de utilizare. Astfel, puterea XML nu este legat de crearea unor documente sau programe, ci de crearea de vocabulare (limbaje de tip XML) cu marcatori i atribute personalizate, cu care apoi se construiesc documentele i programele, n funcie de scopul propus i de potenialii receptori. Dac se urmrete distribuirea de documente XML ctre ali utilizatori sau alte programe, trebuie ca regulile dup care sau construit marcatorii personalizai i semnificaia lor s fie aduse la cunotina tuturor receptorilor 1. Aceasta necesit un efort suplimentar dar asigur posibiliti nelimitate de personalizare i de distribuire ntre diferite platforme hardware i software. Exemple de vocabulare XML consacrate sunt MathML (limbaj de marcare matematic) i CML (limbaj de marcare n chimie), specializate n formatarea i structurarea datelor din domeniile respective (formule matematice, formule chimice), n vederea utilizrii lor de ctre specialiti sau programe specializate n domeniu. Alte exemple eseniale sunt o serie de vocabulare XML destinate chiar manipulrii de documente XML: XSL permite transformarea i formatarea de documente, XLink permite relaionarea marcatorilor din documente XML iar XSDL permite chiar definirea de noi vocabulare XML, ca alternativ la DTD. Nu trebuie s se neleag c orice document XML necesit crearea n prealabil a unui vocabular. Se pot crea documente care respect doar regulile de bun formare, folosind marcatori oarecare, improvizai pentru nevoi imediate, ce nu au fost definii n prealabil de nici un vocabular. n cazul n care documentele sunt de uz intern, fr intenii de distribuire pe scar larg, i atunci cnd se garanteaz faptul c toi receptorii documentelor vor fi pregtii s le prelucreze, se poate evita construirea unui vocabular. n schimb, n contextul interoperabilitii la nivel Web sau al organizaiilor mari, n care documentele XML devin complexe i sunt schimbate automat ntre emitori i receptori care nu se cunosc n prealabil, crearea unui vocabular devine necesar ca baz contractual pentru schimbul de informaii ntr-o manier consistent i fr ambiguiti de interpretare. Spre exemplu, putem construi un document XML cu urmtorii marcatori personalizai:
<ListaPreturiFructe> <Fruct> <Denumire>Mere</Denumire><Pret>10000</Pret> </Fruct> <Fruct> <Denumire>Pere</Denumire><Pret>12000</Pret> </Fruct> </ListaPreturiFructe>
Scopurile acestui document ar putea fi: a. formatarea datelor n vederea afirii, dac atribuim fiecrui marcator un stil 2
1
n mod similar, datele unei baze de date sunt nsoite ntotdeauna de structura sa (capul de tabel) pentru ca sistemele de gestiune a bazelor de date (SGBD) s le poat nelege i prelucra. Reamintim regula general: n comunicarea informaiei, att emitorul ct i destinatarul trebuie s cunoasc regulile dup care marcatorii modific forma, sensul sau utilizarea informaiei. 2 Concept similar stilurilor Word: un stil este o mulime de formatri de diferite nivele font, paragraf, chenare memorate sub un singur nume. Pentru ataarea unor stiluri de formatare datelor XML se folose;te vocabularul XSL. 8
b.
structurarea datelor n vederea stocrii ntr-o baz de date relaional; practic, exemplul de mai sus poate reprezenta tabelul unei baze de date de forma:
Fruct Mere Pere Pret 10000 12000
Avantajul XML fa de forma tabelar, consacrat de bazele de date relaionale, este c marcatorii imbricai pot indica relaii de apartenen/subordonare (relaii tat-fiu ntre datele marcate), n timp ce cmpurile unui tabel se afl doar ntr-o relaie de alturare. c. trimiterea documentului spre programe capabile s trateze documentul ca pe un arbore de date:
ListaFructe
Fruct Denumire Pret
Fruct Denumire Pret
Mere
10000
Pere
12000
Fig. 1. Forma arborescent a unei structuri de date XML Flexibilitatea XML poate fi artat prin faptul c documentul poate suferi transformri. Aceleai date ar putea fi prezentate n urmtoare form, tot de tip XML, dar cu o structur de marcatori diferit:
<ListaPreturiFructe> <Fruct Pret="10000"> Mere </Fruct> <Fruct Pret="12000"> Pere </Fruct> </ListaPreturiFructe>
sau:
<ListaPreturiFructe> <Fruct Denumire="Mere" Pret="10000"> </Fruct> <Fruct Denumire="Pere" Pret="12000"> </Fruct> </ListaPreturiFructe>
Transformarea documentelor XML se poate realiza printr-o serie de operaii de restructurare a marcatorilor, prin programe capabile s manipuleze arbori XML sau cu ajutorul limbajului specific de transformare - XSLT. Raiunile dup care alegem modul de structurare a marcatorilor in de claritatea coninutului pentru utilizatorul uman, de relaiile de subordonare (tat-fiu) ntre date i de optimizarea pentru procesare. n ce privete ultimul aspect, fiierele ar trebui s aib dimensiune ct mai mic, pentru transfer rapid n reea. n plus se tie c majoritatea programelor care proceseaz XML lucreaz mai rapid cu atribute dect cu marcatori, deci transformarea marcatorilor copii ai lui <Fruct> n atribute ale acestuia ar fi o alegere n sensul optimizrii. n ultimul exemplu mai apare un element de noutate, marcatorul vid, care nu are coninut ntre etichetele sale de deschidere i nchidere. Acesta are un echivalent n HTML, la marcatorii care nu au ca rol delimitarea unei poriuni de document (am exemplificat deja <img>,<br>). Pentru a micora efortul i numrul de caractere n document, XML permite scrierea marcatorului vid fr etichet de nchidere, ntr-o form care difer de HTML prin prezena unu slash naintea parantezei de nchidere:
<Fruct Denumire="Mere" Pret="10000"/>
Unitatea fundamental a unui document XML este elementul. Marcatorul d numele elementului, iar coninutul delimitat de etichetele de deschidere i nchidere este considerat valoarea sau coninutul elementului. Aceast terminologie este general adoptat de toate instrumentele de prelucrare XML, deoarece asociaz elemente cu valori de elemente, atribute cu valori de atribute i face mai clar flexibilitatea XML, prin care elementele pot deveni atribute sau invers atta timp ct se pstreaz relaiile de subordonare/ apartenen 3:
<Fruct>Mere</Fruct>
n acest exemplu putem afirma c avem: marcatorul <Fruct> cu coninutul textual Mere elementul cu numele Fruct i valoarea (coninutul) Mere sau, prin construirea unui atribut:
<Fruct Denumire="Mere" />
marcatorul vid (fr coninut) <Fruct>, cu atributul Denumire ce primete valoarea Mere, elementul vid (fr valoare) cu numele Fruct, cu atributul Denumire ce primete valoarea Mere
Pentru a evita confuziile, n materialul de fa se va apela la terminologia: elementul este format din: marcator (care d numele elementului) coninut textual (care reprezint valoarea elementului i poate fi vid) iar marcatorul este format din etichetele de deschidere i de nchidere. Este important de subliniat c n unele cazuri, apar excepii de la aceast terminologie. Spre exemplu programele care trateaz documentul XML ca pe un arbore de date separ conceptele valoarea elementului i coninutul elementului. n astfel de cazuri, coninutul unui element va fi considerat n arbore un nod fiu de tip frunz, care are valoare de tip text i nu mai are nici un nod n subordine. Se va reveni la aceast problem n situaii concrete.
1.2. XML i HTML

O comparaie ntre cele dou limbaje este improprie, datorit scopului mult mai larg pe care i-l propune XML. HTML este destinat construirii de documente, XML este destinat construirii de vocabulare (limbaje) cu care s fie construite documente. HTML pune accent pe modul de prezentare a documentelor i distribuirea formatrilor, XML pune accent pe construirea liber de marcatori i distribuirea structurii / semnificaiei acestora ntre utilizatori sau programe diferite. n particular, XML poate fi folosit pentru construirea unui vocabular de formatare similar cu HTML cu marcatorilor personalizai n acest scop, de aceea se poate afirma c XML poate realiza toate funciile HTML, dar nu se limiteaz la acestea. Vocabularele XML pot defini i marcatori n alte scopuri: instruciuni de procesare, descrieri semantice etc. Desigur, elemente comune exist, avnd n vedere c ambele limbaje sunt specializri ale SGML. Putem chiar afirma c HTML este mai puternic specializat dect XML avnd n vedere c marcatorii lui au o destinaie clar, fix, nealterabil i acceptat la nivel global de orice browser la ora actual. De aici s-ar putea trage concluzia c HTML poate fi considerat un vocabular XML, adic un limbaj n care sensurile marcatorilor au fost deja fixate i acceptate de orice partener care citete documente HTML.
Dac putem afirma c ntr-o imbricare un marcator fiu aparine marcatorului printe, se poate afirma i c atributele unui marcator aparin marcatorului. 10
Aceast afirmaie este din punct de vedere tehnic fals, deoarece cele dou limbaje s-au dezvoltat divergent spre obiective diferite. Motivul pentru care HTML nu este un vocabular XML este c HTML conine reguli pe care sintaxa XML nu le permite n vocabularele sale4: Marcatorii XML obligatoriu trebuie s fie corect imbricai. HTML permite n unele cazuri imbricare incorect, fr a fi considerat eroare:
<b>text boldat <font face=Arial>text arial boldat </b> text arial neboldat</font>
n acest exemplu nu exist o incluziune (imbricare) clar ntre marcatori, acetia doar se intersecteaz pe poriunea central de text. XML nu permite o astfel de construcie. Marcatorii fr coninut se scriu n XML n forma
<br></br>
sau, prescurtat
<br />
n timp ce HTML nu accept aceste forme i accept n schimb

<br>
Valorile atributelor XML se scriu obligatoriu ncadrate cu apostrof sau ghilimele 5, valorile atributelor HTML se pot scrie i fr ghilimele dac nu conin spaii; Marcatorii XML sunt case-sensitive, deci majusculele i literele mici nu sunt echivalente, ca n HTML; Exist o serie de declaraii care apar obligatoriu pe post de antet XML, care identific un document ca fiind de tip XML sau ca aparinnd unui vocabular XML. Aceste diferene ne indic i regulile de baz n construirea de documente sau sublimbaje XML i definesc un concept esenial: buna formare. Documentele bine formate (well-formed) sunt cele care respect aceste reguli sintactice n scrierea marcatorilor, reguli obligatorii n XML indiferent de semnificaia, structura sau utilizarea fiierului. Un fiier XML nu va fi acceptat de ctre nici un program receptor pn cnd nu se asigur c este bine format, de aceea exist fiiere corecte din punct de vedere HTML dar incorect formate dup regulile XML, motiv suficient s putem afirma c HTML nu este un vocabular XML. "Buna formare" este o constrngere special impus de XML, care nu exist n SGML. De aceea un document XML va putea fi considerat corect din punct de vedere SGML, ignorndu-se constrngerea suplimentar, deci putem afirma c XML este un vocabular SGML (cu limitarea amintit privind setul caracterelor). Aadar: XML respect regulile SGML i are reguli n plus (ignorate de SGML), deci XML este vocabular SGML; HTML respect regulile SGML i are reguli n plus (ignorate de SGML), deci HTML este vocabular SGML; HTML nu respect unele reguli XML i are reguli n plus (ignorate de XML), deci HTML nu este un vocabular XML. Totui, eforturi n vederea compatibilizrii s-au realizat, prin construirea unui vocabular XML numit XHTML. Acest limbaj a fost construit n aa fel nct definete marcatorii consacrai n HTML cu semnificaiile lor consacrate, dar le impune regulile de bun formare (obligativitatea imbricrii, a ghilimelelor etc.), astfel nct XHTML poate fi considerat o versiune a limbajului HTML care respect toate regulile XML.
1.3. Prelucrarea informaiilor XML

n cele ce urmeaz se va folosi terminologia consacrat: receptorii documentelor XML poart numele de consumatori. Acetia pot fi utilizatori umani, pentru care are importan deosebit n alt exprimare, HTML nu doar introduce reguli noi, ci permite abateri de la regulile XML Ghilimelele din documentele XML trebuie s fie ghilimelele drepte, din setul de caractere pe care le folosesc mediile de programare i nu ghilimele rotunde, folosite de editoarele de texte, ceea ce cauzeaz adesea o eroare dificil de sesizat.
5 4
11
lizibilitatea, sau programe. Programele care ateapt date de intrare n format XML, n scopul prelucrrii acestora, poart numele de procesoare XML. n vederea utilizrii documentelor XML, nu este suficient ca procesoarele s conin proceduri de prelucrare a marcatorilor i a datelor marcate. nainte de asta trebuie s fie capabile s delimiteze i s extrag marcatorii i coninutul lor, atributele i valorile lor, pentru a le atribui unor variabile de lucru. Astfel, nainte de a fi procesat informaia XML, aceasta trebuie convertit din starea sa nativ (ir de caractere, text brut, plain text) ntr-un model accesibil programelor. Programele care asigur aceast conversie sunt numite parsere XML. Aa cum un browser transform documentul HTML ntr-o form accesibil utilizatorului uman n vederea afirii, un parser transform documentul XML ntr-un model accesibil programelor n vederea prelucrrii datelor. Parserele sunt disponibile n variate sisteme de operare, inclusiv Windows XP, sub forma unor biblioteci de funcii apelabile din variate medii de programare obiectual. S-au consacrat dou astfel de modele, i dou tipuri de parsere corespunztoare: A. D O M ( M o de l o b iect ua l a l do c u me n telo r) Regula de imbricare corect a marcatorilor face ca orice document XML s poat fi tratat ca un arbore n care relaia de incluziune (ntre marcatori imbricai) este transformat ntr-o relaie tatfiu n arbore. Localizarea datelor n iruri de caractere este mult mai anevoioas dect cutarea n arbori, pentru care exist deja algoritmi consacrai. Rezultatul operaiei de parsing DOM este un model obiectual arborescent al documentului: marcatorii i coninutul lor sunt transformai n clase, obiecte i atribute, dup principiile obiectualitii. DOM ofer metode (n sens obiectual) puternice pentru parcurgerea arborilor, convertirea datelor din arbori n diferite tipuri de variabile sau modificarea structurii arborelui (adugare de noduri, modificare, mutare, copiere sau tergere). n urma construciei unui arbore DOM, nodurile arborelui vor corespunde unitilor delimitate din document i vor avea diferite tipuri: un nod element va avea subordonate noduri atribute, noduri de coninut textual, noduri ale elemenetelor fiu i alte tipuri de noduri corespunztoare construciilor auxiliare permise n XML. Dezavantajul DOM este dat de faptul c ntreg documentul XML este ncrcat n memoria intern pentru a fi reprezentat n arbore, deci este un model consumator de memorie intern. B . SA X ( Si mp l e A PI f o r XM L) . Este o metod de parsing promovat pentru medii Java, mai economicoas din punct de vedere al memoriei, dar mai dificil de programat. Documentul XML nu este ncrcat complet, ci caracter cu caracter, n ateptarea declanrii unor evenimente. Exemple de evenimente uzuale sunt: apariia unei etichete de deschidere (startElement), apariia unei etichete de nchidere (endElement), apariia unui coninut textual care nu este marcator (characters). Pentru fiecare eveniment, asociat fiecrui marcator relevant, se pot construi funcii (metode) speciale numite manageri de evenimente (event handler), n care se indic operaiile ce se vor executa la apariia evenimentului. Se poate remarca similitudinea ntre modul de procesare a fiierelor XML i modul de procesare a bazelor de date relaionale. n teoria bazelor de date relaionale, SGBD-ul este programul responsabil cu convertirea fiierelor fizice de pe disc, care conin datele, ntr-un model tabelar/relaional, care este lizibil i accesibil utilizatorului, dar i comenzilor sau programelor executate n cadrul acelui SGBD. Aceasta ne trimite la conflictul clasic ntre bazele de date arborescente i bazele de date relaionale, despre care s-a considerat mult vreme c s-a finalizat cu triumful ultimului model. n prezent, pentru anumite utilizri ale XML, putem considera c fiierele XML devin baze de date arborescente care au multiple avantaje n special n ce privete portabilitatea (i deci distribuirea informaiei pe diferite platforme), dar i n ce privete reflectarea relaiilor tat-fiu ntre date. Aceasta asigur faptul c limbajele de tip XML (vocabularele) pot fi considerate simultan limbaje de programare (care ofer instruciuni executate de consumator) sau modele de date (care ofer structuri de date i nume de cmpuri). Prin asta subliniem nc o dat versatilitatea XML i justificm preferina pentru termenul vocabular n loc de limbaj de tip XML sau model de date XML. Utilizrile documentelor XML, ca succesiune de instruciuni (marcatori) sau ca structur de date, rmne la latitudinea consumatorului n funcie de scopul propus. n concluzie, prin calitatea sa de metalimbaj, XML reuete s anuleze diferenierea ntre text, cod surs i date, grupndu-le pe toate n conceptul general de document.
12
1.4. Validarea informaiilor XML

Validarea XML este un proces de verificare a corectitudinii documentelor superior verificrii regulilor de bun formare. Regulile de bun formare impun doar un numr redus de reguli sintactice (imbricare corect, caractere permise n marcatori etc.). Validarea devine util n oricare din abordrile amintite, deci indiferent dac vedem n documentul XML un cod surs cu instruciuni, o structur complex de date sau un text marcat cu descrieri semantice ori de formatare. n perspectiva tratrii fiierelor XML ca structuri de date, vocabularul devine un model de date iar validarea devine similar cu validarea cmpurilor din baze de date. n teoria bazelor de date, validarea verific datele n raport cu un criteriu, regula de validare. Atunci cnd se introduc, spre exemplu, notele studenilor ntr-un tabel trebuie s se impun regula conform creia nici o not s nu fie din afara intervalului 1-10. Alte exemple de validri sunt preurile i cantitile care trebuie s fie pozitive, intervalele de vrst acceptate n diverse situaii etc. Prezena datelor invalide n bazele de date poate avea efecte grave asupra programelor care folosesc acele date i asupra rezultatelor acestora. n baze de date scopul validrii este s se asigure un coninut valid al tabelelor n raport cu sensul atribuit datelor. n perspectiva tratrii fiierelor XML ca i coduri surs, vocabularul devine setul permis de instruciuni-marcatori iar validarea devin similar cu verificarea sintactic a codului surs, n limbajele de programare tradiionale. n perspectiva tratrii fiierelor XML ca texte, validarea mbin aceste abordri, verificnd deopotriv corectitudinea marcatorilor ct i informaia marcat (intervale de valori, tipuri etc.). Astfel, se pot crea vocabulare XML de variate complexiti, orientate pe tipizarea datelor, pe impunerea unor structuri de marcatori sau variate combinaii ntre cele dou abordri. Odat ce un vocabular a fost creat se pot construi documente pe baza construciilor permise de vocabular. Distribuirea vocabularului permite ca regulile vocabularului s fie aduse la cunotina tuturor utilizatorilor i programelor care ar putea lucra cu acel tip de documente pentru a stabili o consisten n utilizarea marcatorilor personalizai. n momentul n care se transmite un fiier XML de la un utilizator la altul, de la un program la altul, ambele pri trebuie s fie de acord asupra regulilor dup care s-au construit marcatorii, pentru a nelege sensul i posibilitile de utilizare a coninutului. Aceasta se realizeaz prin consultarea vocabularului care devine o baz contractual ntre emitor i receptor. Compararea unui document XML fa de regulile unui vocabular DTD este procesul de validare i se realizeaz cu programe speciale denumite validatoare6. Opiunea de validare este inclus i n unele parsere, dei de multe ori este dezactivat pentru a nu afecta viteza de procesare a documentului din partea programului destinaie. Programul validator trebuie s aib la dispoziie DTDul i documentul XML care se verific. O alt variant n acest sens o reprezint documentele care au diferite poriuni scrise n diferite vocabulare, cu alte cuvinte, fiecare marcator i poate invoca propriul vocabular care s-i guverneze coninutul. n documente XML s-au consacrat dou tipuri de validare: validarea DTD se practic pentru a verifica dac un document anume face parte dintr-un vocabular fr posibiliti de tipizare; validarea XML Schema este mai puternic, aduce n plus tipizarea datelor, deci permite impunerea de reguli att asupra informaiei marcate ct i asupra marcatorilor.
DTD (Definiia tipului de document) conine regulile de construire ale unui vocabular XML pentru date netipizate (numit i tip de document). Folosind o sintax SGML, un DTD precizeaz marcatorii acceptai n vocabular, atributele lor i structurile permise (imbricri, ordine, numr de apariii etc.). DTD-ul poate fi: intern, dac este descris n interiorul unui document XML; extern, dac este descris ntr-un fiier independent, cu extensia .dtd. Ultima metod este recomandat deoarece fiierul extern va putea fi distribuit independent de documentele XML care l invoc. Spre exemplu, HTML este un tip de document SGML: se tie c fiierele HTML i SGML sunt, de fapt, fiiere text (conin un ir de caractere), dar nu orice fiier text este cod HTML valid. Chiar dac se poate folosi orice editor de texte pentru scrierea documentelor XML, se recomand folosirea editoarelor profesionale (XMLSpy, StylusStudio) care permit i construirea de vocabulare, precum i validarea. 13
6
Vocabularul HTML conine un set fixat de marcatori care pot fi folosii i mai conine o serie de reguli la care se supun marcatorii (<tr>, rndul unui tabel, apare obligatoriu ncadrat n <table>, marcatorul pentru crearea unui tabel). Doar fiierele text care respect constrngerile acestui vocabular sunt valide din punct de vedere HTML. Pe scurt, constrngerile DTD indic, de fapt, regulile care definesc un limbaj de tip XML, reguli suplimentare pe lng cele de bun formare impuse de XML dar insuficient de puternice nct s impun restricii de tip asupra informaiei ce va fi marcat n documentele vocabularului. n plus, exist posibilitatea ca un document s respecte regulile mai multor DTD-uri simultan, astfel se va putea afirma c documentul aparine mai multor tipuri de document (vocabulare). De exemplu, orice document XHTML este valid n acelai timp, dup regulile limbajelor XHTML, XML i SGML. XML Schema este un vocabular XML (deci este definit la rndul su printr-un DTD) al crui scop este s defineasc vocabulare XML tipizate (scheme XML), avnd n vedere c DTD nu ofer aceast posibilitate. Prin aceasta, un vocabular XML Schema se apropie de conceptul de schem a bazei de date, impunnd nu doar marcatorii i structura lor, ci i tipurile datelor marcate. Exemplul de mai jos este un fragment scris cu vocabularul XML Schema:
<xs:sequence> <xs:element name="profesie" type="xs:string" minOccurs="0" /> <xs:element name="categorie-varsta" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:minInclusive value="18" /> <xs:maxInclusive value="100" /> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence>
Marcatorul/elementul <xs:sequence> definete regula conform creia toate elementele copil trebuie s apar ntr-un document exact n ordinea precizat de schem: mai nti elementul cu numele profesia, apoi categorie-varsta7. Elementele <xs:element> definesc cele dou elemente permise: unul cu numele profesia i a crui valoare (coninut) va trebui s fie de tip string; n plus, avnd n vedere c numrul minim de apariii posibile este 0 ( minOccurs), nseamn c profesie este un marcator/element opional; unul cu numele (eticheta) categorie-varsta, tot opional; coninutul acestui marcator va fi de un tip de date personalizat (simpleType): o acest tip este definit cu ajutorul elementului <xs:restriction>: folosete ca tip de baz nonNegativeInteger, peste care mai impune intervalul valorilor acceptate 18-100, inclusiv. Acum presupunem c n raport cu acest fragment de schem validm urmtoarele date n format XML:
<categorie-varsta>15</categorie-varsta> <profesie>elev</profesie> <nume>Ion</nume>
Aceste date vor fi considerate invalide n raport cu vocabularul XML Schema, deoarece ncalc trei reguli: ordinea (secvena) celor doi marcatori; intervalul de valori acceptate 18-100; apariia unui element nedefinit n schem. Presupunem validarea coninutului XML:
<categorie-varsta> 25 </categorie-varsta>
Acest element este un descriptor de mulime. Descriptorii de mulime delimiteaz o mulime de elemente XML i stabilete caracterul lor (opional, obligatoriu), precum i ordinea acestora (impus sau liber) 14
De data aceasta datele sunt valide, deoarece respect toate regulile: chiar dac elementul <profesie> lipsete, aceasta respect regula conform creia este un element opional; valoarea 25 respect regula de apartenen la tipul ntreg non-negativ, precum i restricia suplimentar de apartenen la interval. nu apare nici un alt element n afara celor prevzute.
n consecin, validitatea documentelor XML nu se raporteaz la un set absolut de reguli (aa cum este n cazul regulilor de bun formare, impuse de standardul XML) ci relativ la un vocabular. Un acelai document poate fi valid conform cu unele vocabulare (DTD sau scheme) i invalid n raport cu altele. Important este ca atunci cnd documentul este transferat ntre un emitor i un consumator, ambele pri s se pun de acord asupra vocabularului fa de care se valideaz i s aib acces la acesta. Cu ajutorul vocabularelor, XML asigur un nivel de interoperabilitate superior hipertextului, interoperabilitatea structural sau sintactic, ceea ce nseamn c entitile Web pot s schimbe documente XML (coduri surs, structuri de date sau de text) conforme unor reguli sau tipizri comune. n final, rezumm cele dou criterii de corectitudine aplicate documentelor XML: buna formare: un document XML este bine format dac respect sintaxa de bun formare impus de limbajul XML, fr a fi necesar afilierea la un vocabular; buna formare este obligatoriu verificat de ctre orice consumator XML i condiioneaz operaia de parsing; validitatea: un document XML este valid n raport cu un vocabular dac respect regulile i tipizrile impuse de acesta (prin DTD, XML Schema dar i alte soluii asupra crora se va reveni ulterior); validitatea nu condiioneaz operaia de parsing i documentele XML pot fi create sau consumate fr a se verifica afilierea lor la un vocabular.
1.5. Sintaxa XML

Componentele unui document XML sunt: Declaraia XML (Prologul) Elementele i atributele lor Datele de tip caracter Referinele entitilor Instruciunile de procesare Comentariile Invocarea DTD (dac documentul se supune unui vocabular)
Dec la ra ia XM L Este o component poziionat obligatoriu la nceput. Se recomand utilizarea sa pentru ca aplicaiile care citesc documentul s recunoasc formatul XML fr efort suplimentar. Forma sa de baz precizeaz versiunea standardului XML utilizat i este:
<?xml version="1.0"?>
Forma sa extins precizeaz o serie de date opionale:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
Datele opionale sunt setul de caractere folosit n document i dac documentul este independent (nu invoc DTD extern). Alte seturi uzuale de caractere sunt: Unicode extins, pe 16 bii, notat UTF-16, folosit implicit Unicode (8 bit) notat UTF-8 Latin 1 (Western Europe, Latin America) notat ISO-8859-1 Latin 2 (Central/Eastern Europe) notat ISO-8859-2 Latin 3 (SE Europe) notat ISO-8859-3 El e me n t el e Sunt componentele fundamentale, alctuite din: etichetele marcatorilor;
15
coninut (valoarea elementului) - coninutul poate la rndul su s fie constituit din alte elemente (subelemente, elemente imbricate, elemente fiu). Regulile de bun formare privind elementele: S existe exact un element rdcin (elementul document); Toate elementele au etichet de nchidere i de deschidere, inclusiv elementele vide (pentru care se admite notaia prescurtat, cu o singur etichet); Toate elementele s fie corect imbricate (coninuturile s le fie incluse sau disjuncte i nu intersectate); Numele elementelor (etichetele) sunt case-sensitive i pot ncepe cu liter, "_", ":", urmate de un ir de litere, cifre, cratime, puncte, ":", "_" (nu trebuie folosite spaii, acestea fiind considerate delimitatori de atribute); Excepie privind numele: nu pot s nceap cu cuvntul "xml" (majuscule, litere mici sau orice combinaie); se recomand i evitarea caracterului ":" folosit n anumite scopuri specifice (spaiile de nume).
Atri b ut e le Sunt perechi nume=valoare subordonate elementelor. Reguli de bun formare privind atributele: Atributele se ataeaz doar etichetei de deschidere a elementului; Perechile nume=valoare se delimiteaz prin spaii; Valorile atributelor se ncadreaz obligatoriu cu apostrof sau ghilimele drepte ('...' sau "..."); Un nume de atribut nu se poate repeta n acelai element (n timp ce elementele se pot repeta n acelai document sau chiar subordonat aceluiai element-printe!) Atributele nu pot conine caracterele <,&,','' Nu are relevan ordinea atributelor n cadrul elementului. Da te de t i p ca ra ct er Coninutul elementelor XML sau valorile atributelor au un singur tip: caracter. Practic, datele de tip caracter sunt echivalente cu coninutul textual al elementelor (acel coninut care nu reprezint subelemente) sau cu valoarea atributelor. Denumirea de "date de tip caracter" este utilizat n loc de "ir de caractere" pentru a accentua faptul c blocul de text coninut ntr-un element sau ntr-un atribut este tratat de parsere ca unitate, ca o valoare i nu ca succesiune de caractere independente. Reguli de bun formare a datelor de tip caracter: nu pot conine caractere <, &, acestea avnd semnificaie deosebit n XML (nceputul unui marcator); pentru a utiliza aceste caractere se apeleaz la una din soluiile de mai jos: Soluia 1: Seciuni CDATA Aceste seciuni ncadreaz poriunile de coninut textual n care apar caractere nepermise. Spre exemplu, ar putea apare probleme de parsing a urmtorului coninut:
<Paragraf> Forma generala a unei etichete XML este: <eticheta> </Paragraf>
Coninutul textual are o poriune care ar putea fi interpretat ca marcator XML cnd, de fapt, este un text oarecare inclus n elementul Paragraf. Mai mult, se va semnala o eroare de bun formare deoarece <eticheta> nu are etichet de nchidere. Forma corect este:
<Paragraf> <![CDATA[Forma generala a unei etichete XML este: <eticheta>]]> </Paragraf>
n cadrul seciunii CDATA, parserele ignor orice marcatori, pn la ntlnirea simbolurilor de nchidere a seciunii ("]]>"). Se recomand ncadrarea ntregului coninut textual al unui element n seciune CDATA. Parserele nu consider echivalent urmtoarea construcie:
<Paragraf> Forma generala a unei etichete XML este: <![CDATA[<eticheta>]]> </Paragraf>
16
n ultimul exemplu, se consider c elementul conine dou uniti: blocul de text i seciunea CDATA, ceea ce influeneaz modul n care un parser DOM delimiteaz nodurile n document (se vor crea dou noduri fiu pentru nodul Paragraf). Soluia 2: Referine entitate Acestea sunt un tip special de marcatori de forma &NumeEntitate;, utilizai n HTML pentru includerea unor caractere speciale (entitile text), inclusiv a caracterelor nepermise. Exemplul anterior poate fi scris i n forma:
<Paragraf> Forma generala a unei etichete XML este: <eticheta> </Paragraf>
Aici, "<" este referina entitii "<", caracter nepermis. Se poate observa regula de bun formare a acestui tip de marcatori: "&" i ";" sunt etichetele, iar "lt" este numele entitii. n acest caz numele entitii este codul unui caracter, dar n XML entitile capt o funcionalitate mult ma larg. Numele entitilor pot fi cunoscute pe trei ci: pentru caractere speciale exist un set de coduri standard, utilizate i n HTML i recunoscute de parsere: < (<) > (>) & (&) ' (') " ("). entitile HTML sunt un exemplu restrns; n XML, ele nu se reduc la caractere speciale, ci pot lua orice valoare de tip ir de caractere care se declar o dat, n vocabular, apoi poate fi reutilizat nelimitat8. entitile pot fi definite la o adres URL sau n fiiere externe, care se indic parserului pentru consultare. O alt utilizare, mai puin frecvent, a acestui tip de marcator este referirea caracterelor prin cod numeric recunoscut de orice parser: n forma zecimal: & n forma hexazecimal: ( In st ru c i u ni de pro ce sa re Acestea sunt reprezentate de un alt tip de marcatori speciali n care parserele delimiteaz dou iruri de caracter separate cu primul spaiu care apare n marcator, sub forma:
<?predicat parametru?>
Aceste elemente sunt interpretate de procesoarele XML ca indicaii asupra unor prelucrri care se recomand de ctre creatorul documentului, recomandri adresate aplicaiei consumatoare vizate. Consumatorul trebuie s fie dotat cu un mecanism de interpretare a acestor instruciuni, de receptare a parametrului i de efectuare a operaiilor recomandate de document. Parametrul este tratat ca un ir de caractere dar poate conine orice structuri ce pot fi reprezentate prin caractere, inclusiv iruri de interogare, seturi de perechi atribut-valoare etc. Totui, coninutul parametrului nu va putea fi procesat sub form de atribute, aplicaia consumatoare fiind nevoit s foloseasc o metod de extragere a subirurilor pentru a utiliza datele stocate n parametru. n mod similar, orice program ntr-un limbaj oarecare conine o serie de instruciuni care sunt practic recomandri de prelucrare adresate compilatorului. Desigur, nici un compilator nu va ignora setul de instruciuni ale unui limbaj de programare. n cazul documentelor XML, consumatorul poate s interpreteze sau s ignore recomandrile de procesare. Considerm exemplul:
<Student> <?Corectura Legitimatia="101"?> <Nume>Pop Ion</Nume> <LoculNasterii>Cluj Napoca</LoculNasterii> </Student>
n cadrul elementului Student, exist o serie de date care caracterizeaz un student. n mod normal, programele care vor recepiona (consuma) aceste date vor avea implementat, de exemplu, Putem considera c entitile au rolul variabilelor i procedurilor reutilizabile: valoarea lor poate fi o dat, o succesiune de marcatori XML sau orice poriune a unui document XML. Numele lor (mai exact referina) va fi apoi folosit pentru a apela irul de caractere respectiv oriunde este nevoie. 17
8
mecanismul de a le stoca ntr-o baz de date relaional. Primul marcator din cadrul elementului Student este o instruciune de procesare care recomand o procesare de excepie legat de aceste date, de exemplu c ar trebui folosite pentru a corecta datele existente ale studentului cu legitimaia 101. Mai rmne s ne asigurm c programul consumator nelege recomandarea i conine algoritmul care s trateze aceast recomandare. n ciuda aparenelor, instruciunea de procesare nu este un element cu atribute n sens clasic. Din punct de vedere al parserului, nu avem elementul cu numele Corectura i atributul Legitimaia, ci avem dou iruri de caractere: Corectura este predicatul, indicaia de procesare propriu-zis. Legitimatia="101" este un ir de caractere care va trebui convertit n pereche nume-valoare i tratat n programul receptor, deci nu este interpretat implicit ca o pereche nume=valoare dei arat ca un atribut obinuit. De aceea, mai poart i denumiea de pseudoatribut. Indicaia de procesare ar putea arta i astfel:
<?CR 101?>
desigur, cu condiia ca programul consumator s neleag ce nseamn instruciunea CR i ce semnific parametrul 101. Acest detaliu este important deoarece, dup cum se va arta n capitolul Modele de procesare XML, parserele sunt capabile s extrag fiecare atribut dintr-un element, dar dintr-o instruciune de procesare nu pot s extrag dect cele dou iruri de caractere componente: un predicat i un parametru, urmnd ca parametrul s sufere operaii la nivel de stringuri dac stocheaz o structur de date mai complex (vector, atribute etc.). Regul de bun formare a instruciunilor de procesare: nu trebuie s nceap cu irul xml (majuscule, litere mici sau orice combinaie), acestea fiind rezervate pentru declaraia XML de la nceputul documentului. Se poate considera c declaraia XML de la nceputul unui document este o astfel de instruciune, ale crei recomandri, de identificare a versiunii XML i a setului de caractere folosit, sunt nelese de orice parser. Co me nt a ri i Forma comentariilor este urmtoarea:

O problem legat de comentarii este c diferite parsere le trateaz diferit: unele le ignor, altele vor genera noduri de arbore DOM speciale pentru caractere, care pot afecta algoritmul de parcurgere a arborelui. Acest fapt trebuie cunoscut de ctre programele care exploateaz rezultatul operaiei de parsing, pentru o localizare corect a informaiei. Regul de bun formare a comentariilor: nu pot s conin succesiunea "--" care este interpretat ca final de comentariu Inv o ca rea D T D Aceast parte este necesar doar n documentele care au fost construite conform unui vocabular de tip DTD. Aceste documente trebuie s conin o zon n care se face apelul la DTD-ul care conine regulile vocabularului la care se afiliaz documentul. Apelul DTD-ului se realizeaz n diferite moduri: DTD intern: nsoete permanent documentul, caz n care va fi inclus chiar n document, ntrun marcator DOCTYPE, plasat imediat dup declaraia XML:
<!DOCTYPE NumeElementRadacina [descriere DTD intern]>
O soluie mai comod este memorarea sa ntr-un fiier separat, pentru a nu afecta dimensiunea documentelor. n aceast situaie, fiecare document va conine calea sau URL-ul unde este poate fi consultat DTD-ul. Evident, soluia cea mai comod este ca DTD-ul s poat fi consultat de la o adres Web unde s fie permanent disponibil. n aceast situaie avem un DTD extern care se apeleaz cu:
<!DOCTYPE NumeElementRadacina SYSTEM Cale/URL>
18
DTD mixt apare atunci cnd un document invoc un vocabular extern i n acelai timp conine o definiie de vocabular intern; de regul aceast metod se folosete cnd DTD-ul intern i propune s particularizeze o parte din regulile DTD-ului extern invocat; Ultima situaie este atunci cnd un document folosete marcatori din mai multe vocabulare, deci consumatorii care valideaz trebuie s consulte mai multe DTD-uri, de la diferite adrese. n acest caz se folosesc spaiile de nume:
Spaiile de nume ofer o metod de invocare a vocabularelor (de orice tip, DTD sau scheme) prin calificare cu un prefix. Prefixul permite invocarea multipl evitnd coliziunii ntre nume (de elemente i atribute) identice din vocabulare diferite. Exemplu:
<UnElement xmlns:xlink="http://www.w3.org/1999/xlink"> <Legatura xlink:type="simple" xlink:href="fisier.xml" /> </UnElement>
Aceast construcie folosete atributul special xmlns:xlink care este un atribut cu nume i valoare bine formate pentru un parser care nu nelege spaii de nume. Majoritatea parserelor moderne accept ns spaiile de nume i vor da urmtoarea interpretare: Elementul UnElement va fi utilizat conform cu regulile vocabularului XLink i orice construcie din vocabularul respectiv va fi prefixat cu xlink, Regulile XLink sunt disponibile pentru consultare la adresa precizat ca valoare a atributului
xmlns:xlink
9
Toi marcatorii i atributele ale cror nume ncepe cu xlink vor fi validai n raport vocabularul XLink, cu condiia ca acetia s apar n interiorul elementului care a invocat spaiul de nume. Se observ cum n interiorul elementului, fiecare atribut (type, href) este calificat cu numele vocabularului. Cu alte cuvinte, spaiile de nume sunt o metod de calificare 10 a marcatorilor i a atributelor, folosind caracterul ":" pe post de calificator. Textul cu care se face calificarea tuturor numelor din spaiul respectiv poart numele de prefix, n acest caz prefixul fiind xlink. Prefixul este identificatorul local al spaiului de nume, pentru a evita reinvocarea repetat a spaiului de nume, la fiecare element, prin atributul xmlns. Evident, fiecare element al unui document poate s i invoce propriul vocabular, cu propriul spaiu de nume (i prefixul aferent). Marcatorii care nu sunt calificai se consider ca aparin vocabularului de baz al documentului, dac a fost invocat unul. Un exemplu pe care l-am ntlnit deja sunt marcatorii de validare XML Schema care aparin vocabularului XML Schema i trebuie calificai n spaiul de nume xs11. Relum exemplul pentru reamintire:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:sequence> <xs:element name="profesie" type="xs:string" minOccurs="0" /> <xs:element name="categorie-varsta" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:minInclusive value="18" /> <xs:maxInclusive value="100" /> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence>
Nu este obligatoriu ca la adresa respectiv s existe ceva. Important e ca valoarea atributului prefixat cu xmlns s fie un nume unic. Este recomandat ca acest nume s indice spre o resurs util din punct de vedere informativ. 10 Calificare n sensul de "aparine". Marcatorii i atributele calificate cu un nume de vocabular, aparin acelui vocabular. Aceast tehnic este similar cu calificarea obiectual, unde se folosete punctul: Obiect.Atribut este o construcie prin care se arat c Atribut este o component a Obiect. 11 Prefixul este la alegerea creatorului documentelor. xs i xsd sunt prefixe uzuale pentru construcii XML Schema care, aa cum s-a artat, este la rndul su definit ca un vocabular DTD. 19
</xs:schema>
Elementul rdcin n acest exemplu este xs:schema. Prin atributele sale se precizeaz: n interiorul elementului se va folosi vocabularul XMLSchema (denumit prescurtat xs) ale crui detalii descriptive sunt disponibile la adresa indicat; n interiorul elementului orice nume de element va fi calificat (cu xs) datorit atributului elementFormDefault="qualified"; n interiorul elementului orice nume de atribut nu va trebui calificat datorit atributului attributeFormDefault="unqualified". Se poate remarca respectarea ultimelor dou precizri n formarea marcatorilor i atributelor. Se mai observ c vocabularul XMLSchema permite activarea sau dezactivarea calificrilor, avnd n vedere c ntr-o schem XML nu exist de regul marcatori din alte vocabulare. Deoarece un spaiu de nume (i vocabularul aferent) este utilizabil doar n interiorul elementului n care a fost invocat cu atributul xmlns, se recomand ca toate spaiile de nume s fie declarate n rdcina documentului, pentru a fi accesibile oriunde n document.
1.6.Principiile DOM
Modelul DOM este unul din cele dou soluii consacrate pentru extragerea informaiilor dintrun document XML, indiferent c acestea sunt stocate n numele sau valorile elementelor, numele sau valorile atributelor sau n structurile XML auxiliare. DOM nu este o aplicaie n sine, ci un model abstract implementat la nivelul parserelor, ca o colecie de interfee de programare (API) ce folosesc paradigma obiectual pentru a transpune coninutul oricrui document conform cu standardul XML n clase, obiecte i metode. Astfel, DOM este independent de platform i limbajul de programare, fiind considerat un strat ntre parser i aplicaiile consumatoare de XML. Practic, parserul citete date din sursa XML i alctuiete arborele DOM translatnd imbricrile ntre marcatori n relaii tat-fiu i unitile XML n noduri ale arborelui. Tipul de dat fundamental n DOM este DOMstring, un ir format din caractere de 16 bii n care se transpune orice valoare XML nativ. Variate limbaje de programare implementeaz acest n propriile tipuri 16-bit string native, altele (C++) trebuie controlate pentru a nu mapa DOMstring peste un tip de string 8-bit. Nucleul DOM, numit DOM Core, este un set de interfee de programare de uz general la care se adaug module oionale precum cele adaptate pentru manipulare de de stiluri HTML, care nu apar neaprat n toate implementrile i dintre care indicm: DOM Views pentru manipularea unei reprezentri particulare a unui document; DOM Events un sistem de evenimente generice; DOM HTML pentru manipularea de HTML clasic; DOM CSS pentru manipulare dinamic a foilor de stil; DOM Traversal an Range pentru identificarea i parcurgerea unor poriuni de document care nu reprezint neaprat colecii de noduri (fragmente, coninut textual). n modelarea DOM, pornim de la exemplul de mai jos, salvat n fiierul fisier.xml:
<produse> <produs cod="p01">Televizor</produs> </produse>
Un parser DOM va crea din acest exemplu urmtoarea ierarhie de noduri:
20
Document Node
Documentul complet
NodeList
Element Node
<produse>
NodeList
Element Node
<produs>
NodeList
NamedNodeMap
Character Data Text Node

Televizor
AttrNode
ID=p01
Fig. 2. Modelul arborescent creat de un parser DOM Nodul rdcin reprezint ntreg documentul n ansamblu. Este important s se evite confuzia ntre nodul rdcin i elementul rdcin, care este primul element XML din document, dar este un fiu al nodului rdcin, alturi de declaraia XML. Prin aceasta, sugerm c nodurile DOM sunt de diferite tipuri: elemente, atribute, coninut textual, comentarii, instruciuni de procesare etc. Este important de reinut c nodurile atribute sunt tratate ca proprieti ale nodurilor elemente i nu ca noduri fii ale acestora, ceea ce afecteaz rezultatul anumitor operaii de procesare a fiilor unui nod. Node List este o interfa necesar manipulrii coleciilor de noduri ordonate. Faptul c o colecie de noduri poate s apar chiar n subordinea nodului rdcin, indic faptul c acesta poate avea i ali fii dect elementul rdcin: declaraia XML, invocarea DTD, un comentariu etc. Named Node Map este o interfa pentru manipularea coleciilor neordonate de noduri referite prin nume, cum sunt coleciile de atribute. Cele dou interfee sunt specializri care motenesc interfaa generic Node, prin care se manipuleaz toate nodurile DOM. Alte interfee specializate din Node sunt Element, Document, Text, Character Data i Attr al cror rol poate fi intuit. Manipularea arborelui poate avea loc pe dou ci: Generic, prin manipularea interfeei Node; Ierarhic, prin manipularea specializrilor interfeei Node. Manipularea generic, denumit i abordarea aplatizat, este util n lucrul cu documente foarte mari n care performana primeaz. Manipularea ierarhic permite ns un mod de lucru mai facil prin exploatarea unor proprieti redundante. Interfeele nucleului DOM Core sunt descrise n cele ce urmeaz, conform clasificrii n dou categorii. Interfeele fundamentale trebuie s apar n orice implementare, chiar i cele care vor lucra cu documente nonXML (HTML sau CSS). Interfeele extinse trebuie s apar n implementrile care lucreaz cu XML i implicit cu XHTML.
<HTML> <HEAD>
21
<TITLE>DOM Demo</TITLE> <SCRIPT language="JavaScript"> var obiectDOM; obiectDOM = new ActiveXObject("MSXML2.DOMDocument"); obiectDOM.async = false; obiectDOM.load("fisier.xml"); //...procesari diverse </SCRIPT> </HEAD> <BODY> <P>Pagina de test pentru DOM</P> </BODY> </HTML>
Acest exemplu ncarc fisier.xml ntr-o instan ActiveX DOM folosind parserul MSXML2 disponibil pe platforme Microsoft. Printre proprietile i metodele acestei implementri se remarc cea de ncrcare a fiierului (load) i indicaia de ncrcare asincron (async). ncrcarea asincron permite codului surs s se execute n continuare, nainte ca operaia load s se finalizeze.
1.7. Vocabulare XML orientate spre afaceri

Afacerile electronice sunt unul din domeniile cele mai strns legate de cerinele interoperabilitii deci, implicit, de integrarea XML n aplicaiile software. Se poate afirma c n domeniul e-business XML este mai mult dect un limbaj, este un suport al paradigmei sistemelor colaborative. Stephen Mohr (Omicron Consulting), n cadrul uneia din conferinele Wrox, afirm c afacerile electronice sunt exerciiul fundamental n interoperabilitate, de al crui succes depinde dezvoltarea pe scar larg a sistemelor colaborative. Interoperabilitatea afacerilor electronice presupune conectarea i comunicarea fluid n cadrul unei reele de furnizori i parteneri de afaceri, grefat pe o reea de aplicaii i ageni software. XML ca limbaj nu se adreseaz strict problemelor e-business, ci ofer o sintax util n crearea limbajelor (vocabularelor) ce modeleaz probleme economice. Beneficiile principale ale afacerilor electronice sunt costurile reduse i timpii de reacie redui, precum i separarea sarcinilor cu posibilitatea de outsourcing a anumitor activiti spre organizaii partenere. Orice activitate realizat manual anuleaz ntr-o anumit msur aceste caliti i orice punct de interconectare ntre sisteme ce folosesc formate diferite de date produc costuri proprii care risc, n sisteme eterogene s compenseze negativ reducerile de cost dobndite prin virtualizare. Este imperativ implementarea n condiii de cost minim a aplicaiilor e-business pentru ca acestea s nu produc o povar suplimentar asupra organizaiei. La punctele de interconectare ntre aplicaii i sisteme apare problema conversiilor de format deoarece fiecare organizaie are tendina de a-i impune propriul model de date i chiar diferite aplicaii ale aceleiai organizaii folosesc modele diferite. Problema e doar parial rezolvat prin adoptarea standardelor, dar aceasta reduce doar parial eteorgenitatea mediului economic virtual. Contribuie la ameliorarea problemei i adoptarea sistemelor Electronic Data Interchange, dar acestea au succes n companiile mari care i permit achiziia unor platforme orientate EDI. Interoperabilitatea trebuie s poat fi asigurat la orice nivel, chiar i sub nivelul small business, public sau privat, i la orice scar (independent de numrul de parteneri) astfel nct orice dou sisteme ce pot fi conectate hardware s poat schimba date cu efort minim de conversie. n unele cazuri, partenerii de afaceri sunt cei care dicteaz formatul datelor care se schimb ntre organizaii, astfel c organizaiile mici trebuie s fie pregtite s se adapteze la cerinele de format care pot s apar. Investiiile existente, sistemele motenite, sunt nc suficient de mari nct nlocuirea lor definitiv s fie o soluie. Majoritatea sunt adoptate la un nivel profund n organizaie, fr s mai fie necesar antrenarea i adaptarea lor la sistemul informaional. De multe ori interoperabilitatea acestor sisteme este asigurat de intervenii manuale: receptarea unei situaii de ieire i retastarea sa ca set de intrare. n alte cazuri, este implementat o interfa de conversie ntre sisteme. Totui, n contextul efectului de reea, numrul de interfee 1 la 1 ajunge s fie foarte costisitor. Soluia ideal este crearea unui format universal standard, cu valoare de coloan vertebral, la care s fie convertite toate formatele motenite. n aceste condiii, numrul de interfee necesare se reduce drastic. Formatul XML asigur aceste cerine, se preteaz comunicaiilor prin protocoale Internet i se preteaz la conversii dinamice de format. XML se bazeaz pe structuri de text, aadar este independent de platform i de reprezentarea intern a datelor. XML are suport pentru seturi internaionale de caractere i o modalitate 22
de a specifica setul ales chiar n antet. XML nu are nevoie de modificri pentru a fi transferat prin protocoale Internet tradiionale. XML poate fi adoptat ca format nativ de ctre noile aplicaii, dar poate servi i ca format n care s se converteasc datele din alte surse: date din formulare HTML, din tabele relaionale, din fiiere text aplatizate, din aplicaii de mesagerie, din spreadsheet-uri. Indiferent de surs, sunt necesare instrumente de generare i manipulare XML, dintre care cele mai importante au fost deja prezentate n materialul de fa. La acestea mai sugerm cteva cu caracter mai particular. Seturile de nregistrri ADO ofer posibilitatea de a genera XML pe baza acestora. n versiunea 2.1 era vorba de posibilitatea de a salva XML pe disc ntr-un format care echivala nregistrrile cu elementele i cmpurile cu atribute. Versiunea 2.5 a adus posibilitatea de a scrie XML n interfaa IStreamPersist, de a realiza parsing cu MSXML i de a scrie XML n obiectul ASP Response. Suportul ADO a fost urmat n scurt timp de adoptarea suportului XML n majoritatea SGBDurilor, de obicei folosind acelai format XML generat de ADO, cunoscut mai frecvent ca forma canonic XML. Alternativele la forma canonic au fost introduse de SQL Server 2000, prin care interogrile pot stabili modelul de date XML care s fie generat. Astfel, a aprut problema vocabularelor care fixeaz structura n care o aplicaie s exporte sau s genereze date. De asemenea, sa pus problema conversiei XML dintr-un vocabular n altul. Aceste operaii au consacrat limbajele de creare a vocabularelor i limbajul de transformare XSLT, prezentate anterior n lucrarea de fa. Operaiile de validare i transformare au fost adoptate de ctre parsere ca i componente opionale, cu rol contractual i de documentare n cazul unui parteneriat B2B. Validarea a devenit n scurt timp o operaie cu caracter contractual ntre organizaii. Transformarea a cptat acelai rol, de clauz contractual n cazul eecului adoptrii unui vocabular de referin comun la momentul unui schimb de date. Dou vocabulare consacrate n afacerile electronice sunt cXML i XML Common Purchase Order (XML CPO). Rolul lor este s modeleze documente uzuale n derularea afacerilor sub forma unor mesaje cu structura fixat de vocabulare. cXML ncapsuleaz mesajul n elementul cxml, al crui structur intern depinde de tipul de document. Ca alternativ, Microsoft a propus pentru BizTalk Server vocabulare diferite pentru fiecare tip de document. XML CPO este un astfel de vocabular, destinat modelrii comenzilor de cumprare, care corespunde unui mesaj de tip OrderRequest n cXML. Numeroase astfel de vocabulare s-au dezvoltat n timp. O parte pot fi consultate la site-urile creatorilor acestora: www.rosettanet.org, www.xbrl.org i www.biztalk.org fiind dou surse de referin. Un mesaj cXML de tip OrderRequest modeleaz o comand sau o actualizare de comand. Structura acestuia poate fi consultat n exemplul 12:
<cXML payloadID="3223232@ariba.acme.com" timestamp="2007-03-12T10:30:00-08:00"> <Header> <From> .... </From> <To> .... </To> ... </Header> <Request deploymentMode="test"> <OrderRequest> <OrderRequestHeader orderID="c1" orderDate="2007-03-12" type="new"> <Total> <Money currency="USD">33.00</Money> </Total> <ShipTo> .... </ShipTo> <BillTo> .... </BillTo> <Shipping trackingDomain="FedEx" trackingId="1234567890"> <Money currency="USD">0.00</Money> <Description> <ShortName>FedEx 2-day</ShortName> </Description> </Shipping>
12
sursa: Stephen Mohr, Connecting e-commerce to XML, Wrox Conferences, 2002 23
<Tax> .. </Tax> <Payment> .... </Payment> <Contact role="sales"> <Name>Pop Ion</Name> </Contact> </OrderRequestHeader> <ItemOut quantity="2" requestedDeliveryDate="2007-03-12" lineNumber="001"> <ItemID> <SupplierPartID>11111111</SupplierPartID> </ItemID> <ItemDetail> <UnitPrice> <Money currency="USD">25.00</Money> </UnitPrice> <Description> <ShortName>Televizor</ShortName> </Description> ... <ManufacturerPartID>111</ManufacturerPartID> ... </ItemDetail> <ShipTo> .... </ShipTo> ... </ItemOut> </OrderRequest> </Request> </cXML>
Componentele de baz ale documentului sunt OrderRequestHeader, cu antetul comenzii ce specific faptul c e comand nou sau o actualizare, i elementele ItemOut, care modeleaz cte o nregistrare care va fi facturat. XML CPO este o alternativ la comenzile EDI n cadrul BizTalk Server, cu elementul rdcin CommonPO i elementele POHeader, BillTo, ShipTo, apoi o colecie de elemente Item i un element Total. Astfel, o transformare ntre cele dou vocabulare presupune convertirea elementului ItemOut din cXML n Item din XML CPO, Shipping n CarrierDetail i calcularea QuantityTotal i LineItemTotal.
<xsl:template match="cXML"> <CommonPO> <xsl:apply-templates select="Request"/> <FOB ShipPaymentMethod="CC"/> <SpecialCharge Type="X" HandlingMethod="XX"/> <TermsOfSale PaymentMethod="PCard"/> <DateReference Description="XYZ"/> <xsl:apply-templates select="Request/OrderRequest/OrderRequestHeader/Shipping"/>
....
Regula exemplificat scrie elementul CommonPO n cadrul cruia invoc regulile care transform celelalte elemente i creeaz cteva elemente care nu apar n sursa cXML. Dei foile de transformare XSLT se dovedesc eseniale pentru comunicarea ntre vocabulare diferite, crearea unei transformri pentru fiecare contact cu un vocabular partener poate deveni o sarcin anevoioas. Preferabil e ca transformarea s fie generat automat prin compararea documentelor surs i destinaie i eventual s poat gestiona i fiiere text aplatizate sau alte formate text. n acest scop exist numeroase produse software dedicate domeniului B2B pentru gestionarea mesajelor, cum este cazul BizTalk Server produs de Microsoft. Prin interfee prietenoase, acest instrument permite crearea de vocabulare de afaceri i mapri generatoare de transformri automate, cu posibilitatea de implementare a unui flux de auditare care s verifice fluxul de transformri prin care trec mesajele. 24
BizTalk Mapper este una din componentele fundamentale n acest scop. Este capabil s preia specificaiile unor mesaje originale (ca XML Schema sau descrieri de mesaje text plate) i s ofere o interfa grafic pentru modelarea personalizat a componentelor acestor mesaje. Procesri intermediare ntre modelul surs i modelul destinaie sunt posibile prin crearea unor intermediari speciali numii functoizi. E vorba de procesri care nu sunt suportate de XSLT, cum sunt manipulri complexe la nivel de caracter i acces la baze de date relaionale. BizTalk include nativ specificaiile XML CPO i permite ncrcarea specificaiilor altor vocabulare, cum este cXML. Functoizii pot fi utilizai pentru obinerea valorilor calculate, ori se poate apela la elemente xsl care permit ncapsularea de scripturi n seciuni CDATA. Exist un numr mare de functoizi pentru calcule uzuale, care genereaz codul respectiv automat n Visual Basic. BizTalk Management Desk este componenta prin care se pot defini organizaii virtuale asociate vocabularelor surs, porturi ce indic vocabularul destinaie i locaia destinaie i canale ce permit negocierea vocabularului cu porturile. Portul este punctul la care are loc transformarea vocabularelor i care livreaz mesajul final la o destinaie dorit. Canalul poate fi personalizat n funcie de protocolul i specificaiile de securitate dorite. Activitile B2B uzuale implic adesea i o sincronizare a unui flux de mesaje de tipuri diferite. BizTalk permite definirea unui astfel de flux n mod grafic la nivelul serverului prin definirea documentelor de orchestrare. Acestea sunt formate dintr-o serie de aciuni i noduri decizionale care implic porturile i canalele definite anterior, pot defini fluxuri concurente sau procese condiionate. Documentul de orchestrare este n format XML i poate fi invocat de aplicaiile care vor s se alinieze la fluxul respectiv. Comunicarea cu partenerii B2B necesit i crearea unui portal n care s aib loc agregarea vocabularelor. Biztalk.org este un astfel de depozit de vocabulare pentru mesaje BizTalk. RosettaNet.org este un depozite de fluxuri standard de mesaje. Un numr important de organizaii impun astfel de portaluri ca i condiie contractual pentru alinierea la vocabularele proprii. XBRL13 este un vocabular XML standardizat pentru domeniul afacerilor, pentru a permite raportarea n format XML. Standardul este gestionat de XBRL International 14, un consoriu nonprofit susinut de jurisdicii naionale din diferite ri, care activeaz n interesul adoptrii standardelor pentru aplicaiile contabile, generatoarele de raportri financiare, auditare etc. Eforturile pe marginea XBRL se ndreapt spre unificarea structurilor de raportare financiar, mai nti la nivel naional, prin modele locale numite taxonomii (create de jurisdiciile naionale), apoi i la nivelul interoperabilitii internaionale. Succesul XBRL este demonstrat de numeroasele proiecte europene de implementare a formatului n aplicaiile financiare i de proiectul american lansat de U.S. Federal Deposit Insurance Corporation pentru agregarea raportrilor ctorva mii de bnci americane 15. Standardul XBRL prevede crearea de documente cu detaliile raportate ale unei afaceri (business facts) nsoite de un model taxonomic care asigur descrierea semantic a detaliilor raportate. Pentru aceasta, XBRL implic standardele XML Schema, XLink i XPointer. Documentele cu date financiare sunt considerate instane ale vocabularului XBRL, cu urmtoarele componente: Datele raportate ale afacerii, n dou forme: o Item, un element XML cu coninut textual; o Tuplu, un element XML cu subelemente imbricate; Contextul, care indic entitatea care a raportat datele, perioada de raportare i informaii opionale care indic dac raportul este o previziune, o constatare, o planificare bugetar etc; Unitile de msur; Note de subsol; Referine la taxonomie. Taxonomia XBRL referit de instane este o colecie de definiii XML Schema mpreun cu o baz de legturi XLink. Definiiile XML Schema stabilesc practic vocabularul de baz fa de care se valideaz documentele instan. Aceasta presupune definirea conceptelor de Item i Tuplu ca elemente XBRL, fiecare cu modelul su de coninut i o serie de atribute ce asigur identificarea prin nume i tipizarea
Limbaj extensibil de raportare n afaceri, Extensible Business Reporting Language v. http://www.xbrl.org 15 Rezultatele proiectului sunt sintetizate de articolul disponibil la http://www.xbrl.org/us/us/FFIEC%20White%20Paper%2002Feb2006.pdf
14
13
25
datelor financiare din documentele XBRL. Vocabularul de baz poate fi specializat de jurisdiciile naionale pentru a deservi formatele de raportare financiare cu specific naional. Baza de legturi este o colecie de legturi extinse XLink, cu arce i locatori. Rolul su este de a stabili relaii ntre conceptele XBRL sau ntre acestea i resurse Web concrete sau ntre marcatorii XBRL. Baza de legturi imprim un caracter semantic conceptelor structurate cu XML Schema, de aceea o colecie de documente XBRL nu poate fi validat complet numai fa de un vocabular, ci trebuie validat fa de taxonomie pentru a testa relaionrile semantice. Practic, taxonomia este un set de minivocabulare conectate semantic. Urmtorul exemplu16 este un fragment XBRL prin care se stabilete c o companie declar sume n dolari Hong Kong cu precizie de 4 cifre, pentru anul 2000:
<numericContext id="rg.cy00.hkd" cwa="false" precision="4"> <entity> <identifier scheme='http://www.gov.hk'>rg</identifier> </entity> <period> <startDate>2000-01-01</startDate> <endDate>2000-12-31</endDate> </period> <unit> <measure>iso4217:hkd</measure> </unit> </numericContext>
Acest fragment este relaionat prin atributul ID cu o raportare efectiv a costurilor de operare:
<?xml version="1.0" encoding="UTF-8"?> <gaap:opc numericContext="rg.cy01.hkd">-3583000000.</gaap:opc>
Perspectivele XBRL sunt legate de integrarea standardelor contabile ale Uniunii Europene, ceea ce reprezint o schimbare cu costuri de implementare masive i dificil de suportat chiar i la nivelul marilor corporaii. Scopul schimbrii este alinierea raportrilor financiare la un standard transparent i este una din prioritile organismelor de auditare financiar internaional n urma incidentelor la scar mare precum cazul Enron. Criticii indic faptul c XBRL va ajunge la o complexitate mult prea mare pentru ca integrarea sa s fie fezabil, alii indic faptul c, aa cum se ntmpl n XML, complexitatea documentelor este proporional cu complexitatea fenomenului modelat. n concluzie, rolul XML n domeniul afacerilor este asigurat de urmtoarele beneficii: Standardizarea domeniilor B2B i B2C, cu caracter independent de platform i de proprietar. Toate componentele pe care se bazeaz XML (sintaxa SGML, identificarea prin URI, setul de caractere Unicode) sunt standarde; Flexibilitatea indus de independena de platform, separarea formei de coninut i posibilitatea de a transforma documentele; efectele apar n eficien i izolarea facil a erorilor; Longevitatea XML depete longevitatea sistemelor pe care le alimenteaz, ceea ce nu e cazul formatelor proprietare sau binare. Datele XML pot persista i fi transferate la trecerea dintr-o versiune n alta a sistemului; Vocabularele i transformrile asigur comunicarea ntre parteneri B2B fr ca acetia s fie informai asupra detaliilor de platform intern; Scalabilitatea conversiilor la XML este superioar scalabilitii interfeelor 1 la 1; Extensibilitatea XML este dat de posibilitatea de a crea noi vocabulare orientate pe probleme specifice folosind principii sintactice comune, uor de asimilat; Simplitatea XML induce simplitate n implementarea parserelor i interfeelor de programare independente de vocabular; Transferul efortului de procesare dinspre server spre client, cu o parte important de procese efectuate n browser; Indicaii semantice asupra datelor prin caracterul lizibil; Anularea diferenelor conceptuale ntre date i text, prin generalizarea conceptului de document;
16
Exemplul este preluat dup http://www.xml.com/pub/a/2004/03/10/xbrl.html 26
Internaionalizarea este un factor esenial n interpretarea documentelor cu specific local n contextul unui mediu de afaceri global; Personalizarea formatelor i accesibilitate din partea consumatorilor; Eficientizarea metodelor de cutare prin dezvoltarea Semantic Web i a bazelor de cunotine pe fundaia asigurat de XML (fenomen care va fi detaliat n ultimul capitol); Posibilitatea de a integra sisteme considerate neintegrabile din punctul de vedere al costurilor; XML vzut ca ir de caractere ofer o form serializat a datelor, care se grefeaz uor pe serializarea pachetelor transferate n mediile distribuite Bibliografie modul BUCHMANN ROBERT, Conceperea, proiectarea i realizarea afacerilor pe Internet, Ed. Risoprint, Cluj Napoca, 2004; BUCHMANN ROBERT, Rolul XML n interoperabilitatea sistemelor informatice pentru afaceri, Ed. Risoprint, Cluj Napoca, 2007; PHILIPS L.A., XML, Ed.Teora, 2001 Teste de verificare a cunotinelor Care sunt interfeele fundamentale DOM? Care sunt regulile de bun formare XML? Care sunt diferenele ntre analizorul XML i validatorul XML? Ce reprezint termenul DTD? Care sunt caracterisicile vocabularului XBRL? Care e rolul spaiilor de nume?
27
Modulul II. Modelul AJAX

Sumar
Modulul II. Modelul AJAX 2. Paradigma Rich Client i modelul AJAX

2.1.Introducere n AJAX 2.2. Fundaia AJAX 2.3. Platforme i biblioteci AJAX 2.4. Interfaa cu utilizatorul Obiective Familiarizarea cu tehnologiile care stau la baza AJAX Familiarizarea cu biblioteca Dojo Familiarizarea cu biblioteca Prototype Familiarizarea cu biblioteca Scriptaculous Cunoaterea modelului AJAX i mecanismelor de comunicare asincron Aplicarea cunotinelor n realizarea de pagini Web folosind strict standarde WWW i bibliotecile aferente
Recomandri Realizarea unui site Web Rich Client Studiu comparativ ntre cele trei biblioteci studiate Studiu comparativ ntre mecanismele de comunicare asincron
Rezultate ateptate Formarea deprinderilor practice de implementare AJAX Asimilarea cunotinelor privind tehnologiile de la baza AJAX nsuirea proprietilor modelelor Rich Client i Thin Client Recapitulare Modulul anterior a prezentat sintaxa XML, rolul acestuia n interoperabilitate i tehnica de procesare XML prin intermediul modelului DOM i a interfeelor de programare aferente. De asemenea, s-au trecut n revist aspecte legate de XBRL i alte vocabulare XML orientate strict spre modelarea afacerilor. n cele ce urmeaz se prezint tehnologiile care definesc modelul AJAX, precum i o serie de exemple relevante prin care se subliniaz deosebirile dintre modelul AJAX brut i bibliotecile Dojo, Prototype i Scriptaculous.
28
2. Paradigma Rich Client i modelul AJAX

2.1.Introducere n AJAX
AJAX este un termen care promoveaz paradigma Rich Client n domeniul aplicaiilor Web. Aplicaiile Web au evoluat n timp dinspre paradigma Thin Client, n care rolul clientului se reducea la a formata un document, spre modelele ncadrate n aa numita generaie Web 2.0, printre care Rich Client, ce promoveaz transferul efortului de procesare dinspre server spre client, pentru a micora efortul distribuit al serverului i pentru a minimiza latenele provocate de comunicarea intermitent ntre client i server (refreshul redundant de pagin) acestea ducnd, n final, la o mbuntire a fluiditii experienei utilizatorului care apropie regimul de utilizare a aplicaiilor Web de regimul de utilizare al aplicaiilor desktop (n care interfaa cu utilizatorul i baza de date se afl n aceeai memorie, deci latena reelei i refreshul interfeei nu exist). De-a lungul timpului au existat numeroase tehnologii care s promoveze modelul Rich Client, majoritatea orientndu-se ns spre aplicaii Internet non-Web (programe tip Messenger, gestionare local de e-mail - vezi Outlook, diverse aplicaii desktop consumatoare de date on-line etc.), toate acestea fiind aplicaii ce necesit un efort prealabil de instalare i configurare. Dezvoltarea Web spre aceast direcie a presupus gsirea de soluii care s elimine necesitatea instalrii modulelor client. n acest sens, modelul a fost promovat iniial de appleturile Java i scripturile client (JavaScript), apoi de produsele Shockwave (Flash) i, n prezent, de AJAX i o serie de variaiuni ale sale. Astzi se consider c tehnologiile lider n domeniu sunt AJAX i Flash, aflate n competiie: Flash ca produs comercial: optim pentru prezentri multimedia i interfee vizuale, scalabil raportat la suprafaa de aviare de la monitor la PDA - i portabil, dar dezavantajat n ce privete manipularea textului (n siteuri Web orientate spre text); Flash necesit pentru creare mediul de programare Flash (oferit n prezent n cadrul unor produse Adobe) iar pentru vizualizare un plugin pentru browser (disponibil gratuit tot prin intermediul Adobe); AJAX ca soluie necomercial, bazat strict pe standarde WWW (XML, CSS, HTML, JavaScript): optim pentru manipulare de pagini cu text masiv, cu capabiliti multimedia rezonabile, dar dezavantajat n ce privete scalabilitatea pe suprafee de afiare de dimensiuni variabile i n ce privete portabilitatea (datorit diferenelor din modul n care browserele implementeaz standardele Web); AJAX necesit pentru creare doar un editor de texte iar pentru vizualizare orice browser modern (acestea incluznd implicit interpretoarele CSS-HTMLJavaScript i parserul XML). Termenul AJAX a fost fixat de Jesse James Garrett (Adaptive Path) ca acronim pentru Asynchronous JavaScript and XML. Aceasta sugereaz faptul c nivelul logic n AJAX e asigurat de JavaScript i nivelul datelor de XML. Accesul la datele serverului e gestionat asincron pe diferite ci, cele consacrate fiind obiectul XMLHttpRequest (XHR) sau cadrele invizibile. Nivelul prezentrii e asigurat de HTML (structura paginii) i CSS (formatul paginii), att elementele HTML ct i stilurile CSS fiind manipulate dinamic de JavaScript prin intermediul modelului DOM. Partea de server nu mai trebuie s asigure generare dinamic de cod HTML, ci alimentarea modulului Rich Client AJAX cu date n format text (inclusiv XML). Modelul AJAX e astzi adoptat pe scar larg de majoritatea actorilor din scena Web, succesul su fiind demonstrat de pionieratul celor de la Google prin Google Maps (http://maps.google.com). Trebuie remarcat c Google Maps nici mcar nu este o aplicaie AJAX 100%, deoarece nu exploateaz transferul asincron de date elementul care leag tehnologiile Web amintite sub denumirea AJAX. Indicm n continuare o comparaie ntre aplicaiile tradiionale i cele de tip AJAX: Web tradiional: o Datele se trimit de la client spre server cu ajutorul formularelor sau a hiperlegturilor (variabile GET sau POST), aadar prin decizia contient a utilizatorului (n urma unui clic); rspunsul se returneaz de la server sub form de cod HTML; o Starea iniial a aplicaiei e determinat de transferul dinspre server a primei pagini (homepage);
29
o o o
o AJAX: o Datele pot fi trimise de la client spre server la orice moment, JavaScript putnd declana transferuri HTTP oricnd, cu sau fr notificarea utilizatorului; rspunsul se returneaz de la server n format text, fie brut, fie structurat (XML, JSON), pentru a fi prelucrat prin funcii JavaScript; o Starea iniial a aplicaiei e determinat de transferul dinspre server a ntregului modul client, cu toate strile sale posibile (deci are loc un transfer iniial masiv care e totui suportat de calculatoarele moderne i nu necesit instalare, toate interpretoarele necesare fiind ncorporate n browser); o Fiecare stare a aplicaiei e obinut prin modificarea la nivel de client a structurii interfeei cu utilizatorul (structura DOM), pe baza unor date primite de la server (trecerea dintr-o stare n alta nu presupune ncrcare de pagin nou, deci mecanismele Back/Forward i Bookmark nu funcioneaz); o Nu are loc refresh redundant, deoarece dup ncrcarea strii iniiale serverul livreaz doar datele necesare aplicaiei, nu toate elementele interfeei; o Cererile asincrone de date nu blocheaz funcionarea interfeei cu utilizatorul (aa cum face refreshul de pagin) interfaa continu s funcioneze n acele stri care nu au nevoie de datele ateptate de la server; aceasta asigur o fluiditate rezonabil a experienei de utilizare, apropiat de cea a aplicaiilor desktop; o Experiena de utilizare i utilizabilitatea sunt mult mbuntite, nefiind foarte afectate de schimbul intermitent de date cu serverul; n plus, gama de evenimente la care reacioneaz suprafaa interfeei utilizatorului e apropiat de cea a aplicaiilor desktop (ex: se poate declana un transfer de date la trecerea cursorului peste o anumit zon a paginii care nu trebuie s fie neaprat un buton sau o imagine, deci schimbul de date cu serverul poate fi parial ascuns fa de utilizator); o Browserul execut o aplicaie JavaScrip cu interfa HTML. Modelul AJAX are i o serie de dezavantaje dintre care cele mai importante sunt: Aplicaiile AJAX nu respect mecanismul Back/Forward al browserului aceste operaii vor trece la un nou site, nu la o alt pagin a site-ului AJAX (altfel spus, ntregul site AJAX este o pagin unic modificat dinamic la nivelul clientului); Aplicaiile AJAX nu pot fi marcate cu Add Bookmark sau Add Favorites din motivul descris anterior, un semn de carte va marcha doar aplicaia AJAX n ansamblul su, nu poate marca diferite stri ale sale (aa cum se pot marca paginile de interes ale unui site); Aplicaiile AJAX sunt afectate de diferenele de implementare n diferite browsere a tehnologiilor componente (HTML, JavaScript,XHR, CSS); n acest sens recomandm studiul site-ului http://www.quirksmode.org care ncearc s pstreze o eviden la zi asupra acestor incompatibiliti, oferind totodat suport prin tutoriale (inclusiv o funcie de detectare a browserului clientului); o parte din aspectele cross-browser sensibile vor fi detaliate n materialul de fa; Formularele AJAX nu pot realiza nativ ncrcare de fiiere pe server (prin cmpuri de tip FILE n formulare) - aceasta se datoreaz faptului c JavaScript, din raiuni de securitate, nu are acces la fiierele de pe discul clientului.
Fiecare stare a aplicaiei are asociat o nou pagin generat dinamic (deci strile aplicaiei sunt pagini diferite din punct de vede al operaiilor Back/Forward i Add Bookmark/Favorites); Fiecare pagin generat dinamic implic un refresh complet al paginii curente, de cele mai multe ori redundant (implic i rencrcarea elementelor nemodificate de pe pagin); Fiecare refresh sau ncrcare de pagin nou blocheaz temporar aplicaia, pn cnd noua pagin sosete de la server, ceea ce afecteaz fluiditatea experienei de utilizare (comparativ cu aplicaiile desktop unde durata dintre clic i reacia la clic e de regul insesizabil); Experiena de utilizare i utilizabilitatea las de dorit, nu doar datorit comunicrii intermitente cu serverul care suspend utilizarea, ci i datorit gamei reduse de evenimente la care reacioneaz pagin (de obicei doar clic-uri); Rolul browserului e de a formata o pagin (thin client);
30
S-au fcut eforturi pentru a depi toate aceste limitri, o parte din soluii bazndu-se pe cadrele invizibile. Vom atrage atenia asupra soluiilor existente n materialul de fa, la momentul potrivit. Exemple: Considerm formularul:
<html> <head></head> <body> <h1>Introduceti datele</h1> <form method=get action=scriptoarecare.php> <table> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal onblur="date(this.value)"></td> </tr> <tr> <td>Adresa</td> <td><input type=text id=TXadresa size=50></td> </tr> <tr> <td>Oras</td> <td><input type=text id=TXoras ></td> </tr> <tr> <td>Judet</td> <td><input type=text id=TXjudet ></td> </tr> <tr> <td></td> <td><input type=submit value=Trimite ></td> </tr> </table> </form> <p id=Eroare></p> </body> </html>
La sfritul formularului s-a introdus un marcator p, care definete un paragraf vid, fr coninut textual. Rolul su este de a afia ulterior eventuale mesaje de eroare, prin modificarea dinamic a coninutului marcatorului (se poate considera c, n mod implicit, mesajul de eroare este vid). Rolul atributului id este de a identifica n mod unic paragraful respectiv, pentru a fi ulterior accesat de JavaScript. n acelai scop, s-au folosit atribute id pentru fiecare cmp al formularului (atributul id se poate aplica oricrui marcator din pagin). Scopul exerciiului este de a construi, prin tehnici AJAX, posibilitatea ca oraul, judeul i strada s fie completate automat de ctre server, imediat dup ce utilizatorul a tastat codul potal. Pentru aceasta, se asociaz o funcie handler cmpului CodPostal, care se va executa ca reacie la evenimentul blur (ndeprtarea cursorului de pe cmp prin Tab, Enter sau cu ajutorul mouseului):
<input type=text id=TXcodpostal onblur="date(this.value)" >
Funcia respectiv va fi responsabil cu obinerea datelor de la server prin intermediul obiectului XHR, capabil s gestioneze cereri HTTP (codul funciei se scrie n antetul paginii).
<script> var xhr; function date(cod) { xhr=new XMLHttpRequest()
31
} </script>
xhr.open("GET","script.php?CodPostal="+cod) xhr.send(null)
Funcia creeaz o instan XHR (clasa folosit e disponibil n Mozilla, pentru Internet Explorer vom reveni ulterior cu metoda de instaniere necesar), care definete o conexiune la script.php transfernd ca variabil GET codul potal. Funcia send() este responsabil cu trimiterea de date prin metoda POST la server 17 i cu crearea unei stri de ateptare pentru client (ateptarea rspunsului). n acest caz singura informaie trimis e variabila GET concatenat la adresa scriptului php. Aadar, rolul lui send() rmne cel de a activa conexiunea cu serverul i de a crea starea de ateptare (care va fi testat ulterior) motiv pentru care primete un argument null. Pentru a nu complica exemplul, nu vom folosi o baz de date cu codurile potale, ci vom programa scriptul server s recunoasc un singur cod potal, 400451, corespunztor datelor "Cluj Napoca, Cluj, Aleea Azuga". Urmtorul cod surs va fi stocat pe server n fiierul script.php (n acelai folder cu pagina HTML client), apelat anterior de obiectul XHR:
<?php if ($_GET["CodPostal"]==400451) print "Cluj Napoca,Cluj, Aleea Azuga...(completati detaliile)"; else print "cod incorect, cod incorect, cod incorect"; ?>
Aadar, scriptul recepioneaz variabila GET CodPostal, care conine chiar valoarea tastat n cmpul TXcodpostal. Dac valoarea acestei variabile este chiar cea ateptat (400451), scriptul returneaz sub form de text brut, cele trei valori, separate prin virgul. Dac s-a primit orice alt cod potal, se returneaz valoarea "cod incorect" de trei ori. ntr-un exemplu pragmatic, variabila GET nu va fi comparat cu 400451, ci va fi cutat n baza de date a codurilor potale apoi, instruciunea print va returna clientului datele corespunztoare extrase din baza de date. Revenind la modulul client, o alt funcie va procesa rezultatul obinut:
function procesare() { var datestring=xhr.responseText var datevect=datestring.split(',') document.getElementById("TXoras").value=datevect[0] document.getElementById("TXjudet").value=datevect[1] document.getElementById("TXadresa").value=datevect[2] }
Reamintim c rspunsul primit de la server are forma unui ir de valori text delimitate de virgul, chiar i n condiii de eroare (cod potal incorect). Din acest ir se extrag datele ntr-un vector cu ajutorul metodei split, iar valorile vectorului se atribuie celor trei cmpuri din formular. Se observ c JavaScript trateaz formularul (de fapt ntreaga pagin HTML) ca pe un document XML accesat prin intermediul modelului DOM (ce modeleaz ntregul document ca un arbore n memoria intern a clientului). Astfel, document e obiectul ce reprezint ntreaga pagin, iar metoda getElementById caut un marcator dup atributul su id. Proprietatea value a marcatorului gsit este chiar valoarea cmpului respectiv, deci n urma celor trei atribuiri, cele trei cmpuri vor fi completate cu datele obinute de la server. Faptul c AJAX este un model asincron de comunicare cu serverul este evideniat de faptul c nu e posibil procesarea datelor de la server imediat dup transmiterea cererii XHR:
function date(cod) { xhr=new XMLHttpRequest(); xhr.open("GET","script.php?CodPostal="+cod);
Metoda POST necesit cteva operaii suplimentare la definirea conexiunii HTTP asupra crora vom reveni n cadrul unei prezentri detaliate a obiectului XHR. 32
17
xhr.send(null); procesare();
Acest exemplu e incorect - apelul funciei procesare() nu va avea nici un efect, deoarece proprietatea xhr.responseText nu este accesibil la momentul respectiv. Pentru a implementa comunicarea asincron, cererea i rspunsul serverului sunt procesate pe fire de execuie diferite. Modelul AJAX prevede ca procesarea rspunsului s aib loc ntr-o funcie de tip handler, apelat automat atunci cnd datele de la server au sosit. Chiar dac din punct de vedere al codului surs construcia de mai sus pare comod i intuitiv, aceasta ar fi corect doar pentru comunicare sincron. Din punct de vedere al funcionrii comunicarea asincron aduce principalul avantaj al modelului AJAX - faptul c execuia codului nu se ntrerupe ntre formularea cererii XHR i receptarea rspunsului responseText. Mecanismul asincron se implementeaz, dup modelul handlerelor, printrun eveniment, deci forma corect va fi:
function date(cod) { xhr=new XMLHttpRequest(); xhr.onreadystatechange=procesare; xhr.open("GET","script.php?CodPostal"+cod); xhr.send(null); }
Aadar, e vorba de evenimentul readystatechange cruia i se asociaz funcia handler definit. Handlerul poate fi asociat imediat dup crearea obiectului, deoarece execuia sa nu va avea loc pn la obinerea unui rspuns de la server. n paralel, orice alte instruciuni care ar apare dup xhr.send (sau n alte funcii dect date()) vor fi executate atta timp ct nu depind de rspunsul serverului. Toate operaiile care depind de acest rspuns vor fi ncadrate n funcie procesare(). Evenimentul readystatechange este asociat proprietii readyState cu valorile posibile: 0 funcia send() nu a fost nc apelat (nu s-au trimis date spre server); 1 funcia send() a fost apelat dar nu s-a recepionat rspunsul; 2 funcia send() a fost apelat, rspunsul s-a recepionat dar nu a fost convertit n tipul de dat ateptat (nu a avut loc parsingul dac se ateapt, de exemplu, XML); 3 funcia send() a fost apelat, rspunsul a fost recepionat, are loc procesul de parsing; 4 funcia send() a fost apelat, rspunsul de gata de utilizare.
Deoarece evenimentul readystatechange va apela funcia handler de cte ori se schimb valoarea readyState, exist riscul ca procesarea datelor s nceap nainte ca acestea s fie complet disponibile clientului. n acest scop, funcia de procesare a datelor trebuie s verifice dac s-a ajuns n starea 4 nainte de a ncepe operaiile:
function procesare() { if (xhr.readyState == 4) { var datestring=xhr.responseText; var datevect=datestring.split(','); document.getElementById("TXoras").value=datevect[0]; document.getElementById("TXjudet").value=datevect[1]; } }
Trebuie totui remarcat faptul c XHR permite i implementarea de comunicri sincrone, dac metoda open() primete un al treilea argument cu valoarea false. Aadar, este posibil procesarea imediat a datelor n exemplul:
function date(cod) { xhr=new XMLHttpRequest(); xhr.open("GET","script.php?CodPostal="+cod, false); xhr.send(null); procesare(); }
33
Din pcate n acest caz avantajele modelului asincron dispar, execuia este ntrerupt ntre ultimele dou linii de cod pn la receptarea complet a rspunsului i avantajul esenial al modelului AJAX dispare. De fapt, n aceste condiii nici nu se mai poate folosi acronimul AJAX, fiind vorba doar de o form evoluat a modelului Dynamic HTML (care permitea nc din anii 90 accesarea structurii documentului HTML prin JavaScript i CSS). ntreruperea execuiei este cauzat de latena de reea aplicaiile Web se particularizeaz fa aplicaiile desktop prin aceea c interfaa utilizatorului i datele necesare se afl n memorii diferite (a clientului i a serverului) i devin foarte frecvente apelurile de tip RPC (apel de proceduri la distan cnd apelul de procedur i execuia procedurii au loc pe calculatoare diferite). Chiar dac n multe cazuri latena de reea e insesizabil (mai ales c n AJAX care nu face refresh de pagin integral ci transfer doar un set redus de date), aceasta afecteaz ntotdeauna performana aplicaiei i fluiditatea experienei utilizatorului. Latena de reea afecteaz evident i comunicarea asincron, iar codul AJAX trebuie s prevad i s trateze situaiile de posibil ntrziere a datelor de la server. n exemplul de fa e posibil ca o ntrziere excesiv s l fac pe utilizator s tasteze oraul i judeul fr s mai atepte completarea lor automat. Apoi, la sosirea acestora de la server, datele completate de utilizator vor fi nlocuite de funcia procesare(), ceea ce poate produce confuzii utilizatorului. Avantajul AJAX st n faptul c, chiar n condiii de laten sesizabil a conexiunii, utilizatorul poate utiliza alte poriuni ale aplicaiei pn cnd datele sosesc de la server (aplicaia nu nghea). Una din problemele spinoase ale modelului AJAX este compatibilitatea cu browsere diferite sau versiuni ale aceluiai browser. Problemele apar att la modul n care browserele implementeaz limbajele implicate, ct i la instanierea obiectului XHR. Din acest motiv, instanierea se realizeaz ntr-o structur try-catch, prin care se ncearc mai multe instanieri corespunztoare diferitelor tipuri de browsere:
function createXHR() { var x try { x=new ActiveXObject("Msxml2.XMLHTTP") }catch (e) { try { x=new ActiveXObject("Microsoft.XMLHTTP") }catch (e) {x=false} } if (!x&&typeof XMLHttpRequest!='undefined') {x=new XMLHttpRequest()} return x; }
Aceast funcie implementeaz trei tipuri alternative de instaniere XHR, disponibile pe diferite platforme: primele dou corespund browserului Internet Explorer; dac ambele eueaz (x=false) i dac exist clasa XMLHttpRequest, abia atunci se instaniaz aceasta. Funcia de creare a obiectului XHR va fi apelat din funcia date(), n locul instanierii. O alt situaie care trebuie prevzut este posibilitatea ca serverul s rspund cu o eroare HTTP tradiional XHR folosete HTTP i recepioneaz codurile de diagnosticare clasice (404 n caz de resurs indisponibil, 200 n caz de succes). n acest sens, funcia de procesare a rspunsului ar trebui s prevad situaiile de eroare HTTP, verificnd proprietatea status a obiectului XHR:
function procesare() { i f ( xh r . r e a d y S t a t e = = 4 ) { i f ( xh r . s t a t u s = = 2 0 0 ) { v a r d a t e s t r i n g = x h r . r e s p o n s e T e xt var datevect=datestring.split(',') d o c u m e n t . g e t E l e m e n t B y I d ( " T Xo r a s " ) . v a l u e = d a t e v e c t [ 0 ]
34
d o c u m e n t . g e t E l e m e n t B y I d ( " T Xj u d e t " ) . v a l u e = d a t e v e c t [ 1 ] d o c u m e n t . g e t E l e m e n t B y I d ( " T Xa d r e s a " ) . v a l u e = d a t e v e c t [ 2 ] d o c u m e n t . g e t E l e m e n t B yI d ( " E r o a r e " ) . i n n e r H T M L = " " } e l s e d o c u m e n t . g e t E l e m e n t B yI d ( " E r o a r e " ) . i n n e r H T M L = " < f o n t c o l o r = r e d > E r o a r e d e c o n e c t a r e l a s e r v e r !< / f o n t > " } }
Acesta este momentul la care se apeleaz la paragraful vid cu id=Eroare. n caz de eroare, se genereaz coninut textual pentru paragraful respectiv, cu ajutorul proprietii innerHTML. Pe aceast cale, practic se genereaz marcatori noi n structura paginii (coninutul textual atribuit lui innerHTML poate fi orict de complex).
Not: Insistm asupra ideii ca pachetul Firebug s fie instalat n Firefox nc de la primele exemple testate. n timpul execuiei scripturilor, consola Firebug afieaz datele care se schimb ntre client i server, ceea ce ofer un ajutor semnificativ n localizarea erorilor care pot s apar la tastarea codului surs. Struc tura datelor schimbate ntre client i server poate indica dac o eventual eroare apare n modulul client sau n scriptul server. Imaginea de mai jos afieaz datele schimbate prin metoda GET, n cele trei rubrici ale consolei: Params (datele trimise de l a client) Response (raspunsul serverului) Headers (antetul HTTP) Firebug este disponibil gratuit ca pachet add -on Firefox.
Clic pe adresa scriptului server pentru afiarea datelor transferate
Butonul de deschidere a consolei Firebug
2.2. Fundaia AJAX 2.2.1. JavaScript

JavaScript este un limbaj dedicat scripturilor client (interpretate i executate direct n browser, deci nsoesc codul HTML fiind integrate n marcatorul SCRIPT). n cadrul tehnologiilor Web limbajul a avut dintotdeauna o reputaie proast, datorit lipsei tipizrii datelor, a naturii dezorganizate a codului
35
surs integrat cu HTML i a implementrilor inconsistente n diverse browsere. AJAX a revigorat semnificativ rolul JavaScript, oferindu-i n sfrit un cadru de exploatare matur. Lipsa tipizrii datelor nseamn c variabilele JavaScript nu au tip fixat i nu trebuie declarate. Variabilele se creeaz la prima atribuire iar tipul unei variabile se schimb dup tipul valorii care i se atribuie. Erorile de tip type mismatch sunt n general evitate prin mecanismul de conversie implicit a datelor din expresii. Aceasta poate fi un avantaj (comoditatea) dar i un dezavantaj detectarea erorilor devine mai dificil. Limbajele puternic tipizate atrag atenia asupra erorilor de tip. De exemplu tastarea greit a numelui unei variabile genereaz o eroare datorit faptului c variabila cu numele greit nu e declarat. n JavaScript, tastarea greit a numelui unei variabile nu va genera eroare, ci va crea o nou variabil (cu numele greit). Disciplina JavaScript recomand ca variabilele s fie declarate formal cu instruciunea var (dei nu li se indic tipul) pentru a face depanarea codului surs mai facil, mai exact pentru a separa mai clar variabilele create intenionat i cele create neintenionat (prin erori de tastare a numelui). Mecanismul conversiei implicite din expresii e exemplificat de atribuirea:
a=2 b="a" c=a+b
Un limbaj tipizat genereaz o eroare type mismatch datorit tentativei de adunare ntre o variabil numeric i o variabil string. n JavaScript, rezultatul va fi "2a", numrul 2 fiind convertit automat la tipul variabilei b, iar operaia efectuat nu va fi adunarea, ci concatenarea. Din nou, aceast situaie devine convenabil sub aspectul comoditii (nu sunt necesare conversii explicite) dar poate face dificil detectarea unor erori de tip (conversii implicite neintenionate). Tipurile datelor cu care lucreaz JavaScript sunt boolean, numeric, string, referine la obiecte i funcii. La acestea se adaug tipul undefined, ce caracterizeaz o variabil declarat (cu var) dar creia nu i s-a atribuit nc valoare. Tipul pe care l are la un moment dat o variabil poate fi aflat cu ajutorul funciei typeof(). Datorit faptului c o variabil e creat ad-hoc la prima sa atribuire, fr o declarare prealabil, se poate deduce c acelai comportament l suport i proprietile obiectelor. O simpl atribuire obiect.proprietatenoua=valoare va crea o nou proprietate n obiect, fr a fi necesar declararea noii proprieti n clasa (prototipul) obiectului. Mai departe, constructorii de obiecte sunt funcii obinuite care preiau argumente i le ofer proprietilor obiectului this:
function Obiect(arg1,arg2,...) { this.proprietate1=arg1 this.proprietate2=arg2 ..... return this } a=Obiect(valoare1,valoare2) alert("prima proprietate a obiectului are valoarea:"+a.proprietate1) a.proprietatenoua=valoarenoua alert("obiectul a primit o noua proprietate!")
Funciile JavaScript sunt similare cu alte limbaje (se declar prin cuvntul cheie function, pot avea 0 sau mai muli parametri, returneaz o valoare la apelul acestora). Datorit lipsei tipizrii, spre deosebire de C sau Java, nici la funcii nu se declar tipul valorii returnate naintea cuvntului cheie function. Aadar, o funcie va putea returna alternativ (pe diferite ramuri de execuie), valori de diferite tipuri (inclusiv nici o valoare, adic valoare de tip undefined). O alt diferen fa de limbajele obiectuale clasice este faptul c JavaScript nu suport supradefinirea (polimorfismul) funciilor. Considerm exemplul:
function f1(a) {...........} function f1() {..........} a=f1("aaa")
36
Intr-un limbaj care suport polimorfismul funciilor, funcia f1 ar exista n dou forme diferite, difereniate prin apelul funciei cu un argument sau fr argumente (altfel spus, identificarea funciei ce trebuie executat la un apel se face att prin nume ct i prin argumente). In JavaScript, a doua definire a funciei f1 o va nlocui pe prima (identificarea funciei de executat se face doar prin nume). Dup cum am sugerat anterior, funciile sunt considerate n JavaScript tipuri de date. Altfel spus, definirea unei funcii are ca efect crearea unei variabile cu numele funciei i valoarea dat de nsui blocul de execuie al funciei (typeof va indica tipul function pentru aceast variabil, iar afiarea variabilei va afia n format text definiia funciei, fiind vorba practic de un pointer n sens clasic). Aceasta are drept consecin un alt comportament care contribuie la reputaia de limbaj "dezorganizat" pe care o are JavaScript.
function f() {......} f=10; a=f();
Majoritatea limbajelor vor accepta o astfel de secven, neexistnd nici un conflict ntre variabila f i funcia f(). n JavaScript se obine o eroare, deoarece pe ultima linie, f nu mai este o funcie, ci o variabil cu valoarea 10. Aadar, dac exist o variabil i o funcie cu acelai nume, cele dou sunt considerate a fi aceeai variabil, care i poate schimba valoarea ntre tipul function i orice alt tip. Exemplul urmtor creeaz o astfel de variabil de tip function (pointer spre o definiie de funcie):
v1=function() {return 2+3} a=v1() b=v1
n acest exemplu, v1 este o variabil de tipul function, a va primi valoarea returnat de funcie 5 (de tip ntreg), iar b va primi valoarea "function(){return 2+3}" (de tip function). Prin urmare, variabila b preia blocul funciei i nu valoarea sa, devenind la rndul su o funcie apelabil prin construcia b(). Cu alte cuvinte, b devine pointer al aceleiai funcii ca i v1. Prezena sau absena parantezelor indic dac e vorba de valoarea returnat de funcie sau de blocul definiiei funciei (accesat prin pointer). Una din caracteristicile cele mai neplcute ale JavaScript este legat de vizibilitatea variabilelor locale din funcii. n majoritatea limbajelor, exemplul urmtor va provoca o eroare:
function f() { local=2 x=local/2 return x } a=f() b=local alert(b)
Majoritatea programatorilor se ateapt ca ultima linie de cod s provoace o eroare de vizibilitate a variabilei local. n mod normal, o variabil creat ntr-o funcie este accesibil doar n interiorul acelei funcii i se distruge dup execuia funciei. n JavaScript n schimb, variabilele locale ale unei funcii nu sunt distruse dup execuia sa. Se spune c apelul unei funcii creeaz o nchidere (closure), adic o stare a memoriei interne (incluznd variabilele locale funciei) care rmne accesibil dup execuia funciei. Insistm asupra faptului c nchiderea e creat de apelul funciei, i nu de declaraia sa. Deci urmtorul exemplu va provoca eroare de vizibilitate chiar i n JavaScript (lipsete apelul care creeaz nchiderea):
function f() { local=2 x=local/2 return x } b=local alert(b)
37
nchiderile sunt un aspect problematic, vzut adesea ca un pericol de securitate i de depire de memorie n schimb programatorii avansai vd n aceasta o oportunitate, un nou mod de a gndi codul surs al algoritmului de exemplu, o funcie poate avea acces la valorile variabilelor locale ale altei funcii18. Combinnd nchiderile cu faptul c orice funcie poate fi tratat ca o variabil, devin posibile: definirea de funcii n funcii:
function f() { a=2 functielocala=function () { b=a+a return b } } v=f() function f3() { alert(functielocala()) } f3()
n acest caz funcia functielocala, vzut ca variabil local a funciei f() rmne accesibil (datorit nchiderii) chiar i n blocul funciei f3(). Aadar o funcie poate ncapsula mai multe funcii ce vor deveni accesibile codului surs dup execuia funciei printe. funcii care returneaz funcii:
function f() { a=2 functielocala=function () { b=a+a return b } return functielocala } v1=f()() v2=f() v3=v2()
n acest caz, v1 primete rezultatul rezultatului funciei f, deci valoarea 4, iar v2 primete rezultatul funciei f, deci blocul funciei functielocala (return functielocala nu are paranteze, deci se returneaz blocul funciei i nu valoarea sa). v3 preia mai departe rezultatul acestui bloc, deci valoarea 4. Acest exemplu e elocvent pentru a diferenia cazurile n care e vorba de rezultatul unei funcii fa de cazurile n care e vorba de blocul su de execuie (deci de o valoare de tip function). Interaciunea JavaScript-HTML e posibil pe dou ci: prin ncadrarea scripturilor n marcatorul SCRIPT sau prin ncadrarea scripturilor direct n valorile unor atribute HTML. Exemple:
<script type="text/javascript"> function functie() {alert("mesaj")} </script> <input type=button onclick="functie()" >
este echivalent cu:

<input type=button onclick="alert('mesaj')" >
Exist i lmbaje de programare ce permit, prin sintaxe diferite, att creare de funcii ct i creare de nchideri (vzute ca funcii cu stare persistent) 38
18
Lansarea n execuie a scripturilor JavaScript se poate realiza independent de pagina HTML fiind un limbaj interpretat, codul JavaScript se execut instruciune cu instruciune, n ordinea n care acestea apar n codul surs, pn la final sau pn la ntlnirea unei erori. Legarea cu pagina HTML se realizeaz de obicei prin intermediul evenimentelor - declanarea unui eveniment pe suprafaa documentului se asociaz unui apel de funcie sau unui grup de instruciuni JavaScript. n exemplul anterior, evenimentului clic al unui buton HTML i s-a asociat instruciunea / funcia care afieaz un mesaj. Una din probleme spinoase JavaScript, motenite i de AJAX, este faptul c diferite tipuri de browser recunosc diferite seturi de evenimente (dei setul de baz, definit n standardul HTML 4.0, este recunoscut azi de toate browserele).
2.2.2. XML i DOM

XML este o paradigm, un model pentru limbajele ce folosesc marcatori. Rolul modelului XML este s garanteze o structur intern arborescent pentru documente. Structura arborescent este garantat prin impunerea aa-numitelor reguli de bun-formare. Cele mai importante reguli sunt c orice marcator trebuie s aib etichet de nchidere i orice marcator trebuie s fie corect imbricat n altul, deci nu se permit construcii precum:
<img> <li>........... <b>...<i>...</b>...</i>
...acestea trebuind convertite la

<img></img> <li>............</li> <b>....<i>....</i>....</b>
Este evident c, datorit imbricrii corecte, a doua variant genereaz o structur arborescent pornind de la ideea c marcatorul I este inclus (subordonat) marcatorului B (aa cum posibilitatea de a include un folder n altul genereaz structura arborescent a directoarelor de pe un disc). Dac toi marcatorii unei pagini Web sunt nchii i imbricai corect, pagina poate fi reprezentat printr-un arbore de marcatori, avnd ca rdcin marcatorul HTML, cu nodurile fiu HEAD i BODY, care la rndul lor au alte noduri subordonate (ali marcatori imbricai). n scopul alinierii paginilor Web la acest model, s-a definit limbajul XHTML care nu este altceva dect o variant HTML care respect regulile de bun-formare. Aceste reguli nu se refer doar la imbricare, ci i la alte aspecte de compatibilizare cu modelul XML, cum ar fi: sintaxa XHTML este case-sensitive, cu litere mici; marcatorul rdcin este unul singur (deci nu se poate neglija marcatorul HTML, care ar face ca pagina s conin doi marcatori pe primul nivel: HEAD i BODY); orice marcator trebuie nchis, chiar dac nu are coninut ntre etichetele sale; pentru marcatorii fr coninut, pentru a nu scrie eticheta de dou ori, se permite forma prescurtat cu o singur etichet ncheiat cu un slash, n forma <img .../> (n loc de <IMG ...>, cum e n cazul HTML clasic)19; identificarea marcatorilor se face cu atributul id care capt rol de cheie primar nu pot exista doi marcatori cu aceeai valoare ID; atributele XHTML au obligatoriu valorile cuprinse ntre ghilimele (n timp ce HTML permite construcii cu atribute fr ghilimele sau prescurtate precum <INPUT TYPE=CHECKBOX CHECKED>, XHTML permite doar <input type="checkbox" checked="checked"/>); codul surs trebuie s nceap cu un antet de instruciuni care s confirme c documentul este de tip XML:
<?xml ?> <!DOCTYPE ...> <html> ...... </html>
19
n continuare vom utiliza forma XML pentru marcatorii cu etichet unic 39
Instruciunea xml indic faptul c documentul respect regulile XML. Instruciunea DOCTYPE are rolul de a particulariza acest lucru, indicnd faptul c e vorba de un document XHTML - adic respect regulile XML i n plus folosete vocabularul de instruciuni HTML 20. Este recomandat ca paginile Web s se conformeze regulilor de bun-formare XML. Totui, browserele moderne sunt capabile s converteasc la XML orice cod HTML clasic, motiv pentru care n majoritatea exemplelor nu vom respecta ntru totul regulile XHTML 21. Dac pagina are cod surs bine-format (sau a fost convertit de browser la un cod bine-format), acesta poate fi reprezentat n memoria intern a clientului sub forma unui arbore cu noduri - fiecare nod corespunznd unui marcator, cu un nod rdcin unic i cu nodurile-frunte corespunznd coninutului textual al marcatorilor:
<html> <head></head> <body> Text1 <font face=arial>Text2</font> <img src=..../> </body> </html>
Va duce la un arbore de forma:

html
head
body
Text1
Font
Img
Text2
Arborele poate fi accesat de JavaScript prin intermediul funciilor, capabile s parcurg arborele i s manipuleze nodurile acestuia pe cale obiectual (fiecare nod e un obiect care conine nodurile subordonate). Modificnd prin DOM arborele paginii, practic se manipuleaz structura documentului orice poriune de document va putea fi mutat, tears, modificat, se pot crea poriuni noi n document (adugnd noduri noi n arbore). Poriunile documentului sunt identificate cu ajutorul marcatorului care le ncadreaz (i a atributului id pe care acesta l are). Modelul arborescent al paginii mai poart i denumirea de model DOM sau arbore DOM (preferabil fa de denumirea mai general de "arbore XML"). Toate componentele arborelui sunt subordonate obiectului ce reprezint pagina n ansamblu (deci conine ntregul arbore) e vorba de obiectul document. Acesta conine obiecte de tip element (corespunztoare marcatorilor) i fiecare obiect-element are o serie de proprieti ce stocheaz atributele i coninutul textual al marcatorului. Manipularea prin DOM poate fi aplicat chiar i ca nlocuitor pentru handlerele de evenimente. Aadar, legarea unei funcii JavaScript la evenimentul clic al unui buton, ar putea arta, prin intermediul DOM, astfel: XHTML nu este singurul limbaj al paradigmei XML, oricine i poate defini propriul limbaj XML n msura n care asigur un mecanism de interpretare a instruciunilor acestuia. n cazul XHTML, semnificaia instruciunilor este cea oferit de HTML. 21 n special vom neglija pentru simplificare antetul XHTML, dar se vor putea remarca i alte abateri care nu afecteaz funcionarea exemplelor n principalele browsere Internet Explorer 7 i Firefox 2. 40
20
<input id="b1" type="button" /> <script type="text/javascript"> function functie() {.........} document.getElementById('b1').onclick=functie(); </script>
Avantajul n acest exemplu este o separare mai clar ntre codurile JavaScript i HTML, aspect important atunci cnd designul paginii i programarea paginii sunt asigurate de persoane diferite (care vor trebui s-i comunice reciproc doar identificatorii elementelor). Altfel spus, designerul nu va mai fi nevoit s tie cum se numete funcia handler de care are nevoie (programatorul va trebui oricum s tie cum se identific elementele paginii). Dezavantajul metodei este c marcatorul SCRIPT nu mai poate apare n HEAD, codul JavaScript trebuind s apar dup definirea elementului cu atributul ID, altfel funcia getElementById nu va detecta nimic. Acest dezavantaj poate fi ndeprtat prin ascultarea de evenimente: funcia attachEventListener() asociaz un eveniment cu o funcie (sau chiar mai multe). Pentru evitarea acestor complicaii, vom apela n continuarea la asocierea tradiional a evenimentelor prin atribute HTML precum onclick. Exemplu:
<html> <head> <script type="text/javascript"> function modificaPagina() { var v1 = document.documentElement var vector = v1.childNodes var nodbody for (i = 0; i < vector.length; i++) if (vector[i].nodeName == "BODY") { nodbody = vector[i] break; } vector = nodbody.childNodes var noddiv for (i = 0; i < vector.length; i++) if (vector[i].nodeName == "DIV") { noddiv = vector[i] break; } var nodtext=document.createTextNode("Text nou") noddiv.replaceChild(nodtext, noddiv.childNodes[0]) noddiv.setAttribute("align","right") } </script> </head> <body> <div>Text vechi</div> <button onclick="modificaPagina()">Apasa pentru modificare text</button> </body> </html>
n acest exemplu, coninutul vizibil al paginii este un buton care reacioneaz la clic i un text marcat cu marcatorul div. Efectul clic-ului pe buton este nlocuirea textului cu un alt text i modificarea formatului (alinierea la dreapta a textului). Spre deosebire de majoritatea marcatorilor HTML care au rol de formatare sau definire a unor componente de pagin, exist doi marcatori cu rol strict de delimitare: div i span. Rolul lor este s delimiteze poriuni ale documentului n vederea accesrii lor ulterioare prin JavaScript (prin atribute id) sau n vederea formatrii cu stiluri CSS (prin atribute class). Poriunile de document ncadrate n div sau span pot s aib orice complexitate de la un caracter pn la coninutul integral al corpului
41
paginii, cu condiia s respecte regulile de bun-formare XML (deci nu se permit construcii ca <div><table></div>...</table>). Diferena ntre div i span e c blocul definit cu div ocup toat limea paginii, deci are un efect vizual similar cu un paragraf (coninutul din faa i de dup div apare pe rnduri diferite). Marcatorul span nu are nici un efect vizual, blocul span nu ocup toat limea paginii, ci doar suprafaa ocupat de caracterele ncadrate, de aceea e frecvent folosit pentru a face delimitri mai fine, la nivel de caracter. Un document HTML poate conine oricte blocuri div i span n orice combinaie dar, pentru AJAX, imbricarea acestora trebuie s respecte regulile de bun formare XML. Cu alte cuvinte, cei doi marcatori nu se folosesc din raiuni de format, ci din raiuni de structur se folosesc pentru a mpri documentul n uniti structurale care s devin n memoria intern noduri ale arborelui DOM (deci vor putea fi accesate direct i manipulate independent unele de altele). Structurarea documentului are un rol important i n ce privete formatarea prin stiluri CSS. Fiecare bloc div sau span poate fi asociat unui stil CSS pentru a fi formatat (atributul class). Apoi, prin intermediul JavaScript, asocierea div-CSS sau span-CSS poate fi modificat pentru a modifica n mod dinamic formatul paginii. Pentru a nelege mai uor diferena ntre div i span, recomandm afiarea n browser a urmtorului exemplu, n care un bloc div i un bloc span sunt asociate unor stiluri CSS ce le formateaz fundalul:
<html> <head> <style type=text/css> .S1 {background:red} .S2 {background:blue} </style> </head> <body> Text oarecare care conine <div class=S1> un <br> bloc <br> div </div> Text oarecare care conine <span class=S2> un <br> bloc<br> span </span> </body> </html>
Ambele blocuri delimiteaz o poriune din fraza afiat. S-au inserat marcatori br pentru a sugera c un bloc div sau span se poate ntinde pe mai multe rnduri i poate conine orice combinaii de marcatori permise de regulile de sintax XML. Culoarea fundalului indic poriunea de document afectat de cele dou blocuri. Se observ c blocul div ocup toat limea paginii iar blocul span doar suprafaa ocupat de caracterele ncadrate. Se va remarca ulterior c n modelul AJAX blocurile div n special joac un rol esenial, motiv pentru care paginile HTML n AJAX nu au, la prima vedere, o structur tradiional. n paginile HTML clasice, documentul arat ca un text marcat cu marcatori de formatare - H1 pentru titluri, P pentru paragrafe, FONT pentru aplicare de font etc. n paginile HTML AJAX, documentul e o colecie de blocuri div (i mai rar span) nsoite de stilurile CSS care le definesc formatarea i atributele id necesare accesrii lor rapide. Prin acest mecanism se separ clientul AJAX pe nivelele: structura documentului (dat de blocurile div) formatul (dat de stilurile CSS i asocierile div-CSS) comportamentul (dat de modul n care JavaScript manipuleaz asocierile div-CSS i structura arborelui de blocuri div) datele ce determin comportamentul (oferite de obiectul XHR). Evident c aceast separare asigur o modularizare superioar a aplicaiilor Web cele 4 nivele pot fi gestionate de persoane diferite, cu un minim de interferen ntre acestea iar depanarea aplicaiei se realizeaz mult mai uor, odat ce se identific pe care nivel au aprut eventualele erori. Funcia din exemplul anterior nlocuiete coninutul textual al marcatorului div cu un alt text. n acest scop, se caut n arbore (stocat n obiectul document) marcatorul body, apoi n acesta se caut marcatorul div. Cutarea are loc prin parcurgerea tuturor nodurilor fiu (a tuturor marcatorilor imediat subordonai). Odat ce blocul div a fost identificat i stocat n variabila noddiv, coninutul su textual este nlocuit prin metoda DOM replaceChild() iar alinierea sa se modific prin crearea atributului
42
align=right. Se observ c din punct de vedere DOM, coninutul textual al unui element este considerat nod fiu al acestuia i nu valoarea acestuia. Proprietile i funciile DOM folosite au fost: documentElement stocheaz nodul rdcin al paginii; childNodes stocheaz un vector cu toate nodurile fiu ale obiectului curent, numerotate ncepnd cu 0; pentru parcurgerea arborelui, DOM mai ofer o firstChild i lastChild acces la primul i ultimul nod fiu, o hasChildNodes() - testeaz existena nodurilor fiu, o parentNode acces la nodul printe, o nextSibling i previousSibling acces la urmtorul i precedentul nod frate; nodeName stocheaz numele nodului curent (eticheta marcatorului); pentru obinere de informaii despre un nod, DOM mai ofer: o nodeValue - util la noduri de tip text), o nodeType - tipul nodului: 1 pentru element, 3 pentru text, 9 pentru document, 8 pentru comentarii etc., createTextNode() creeaz un nod de tip text (coninut textual); pentru creare de noduri, DOM mai ofer createElement() (creeaz un nod de tip element); replaceChild() nlocuiete un nod fiu al obiectului curent cu un alt nod (n acest exemplu noul nod va fi chiar nodul de tip text); pentru manipulare de noduri, DOM mai ofer: o insertBefore() insereaz un nod fiu, o appendChild() adaug un nod fiu la sfritul listei fiilor, o cloneNode() copiaz un nod; o removeNode() terge un nod fiu; setAttribute() atribuie o valoare unui atribut al nodului curent (dac nu exist, e creat); pentru atribute, DOM mai ofer: o getAttribute - citete valoarea unui atribut, o removeAttribute() - terge atribut, o createAttribute() creeaz un atribut, o hasAttribute() -testeaz existena unui atribut, la acestea mai adugm o serie de funcii pentru manipularea irurilor de caractere, utile n modificarea coninutului textual al marcatorilor: o appendData () adaug caractere la coninutul textual, o data similar cu nodeValue pentru nodurile de tip text, o deleteData() terge caractere din coninutul textual, o insertData() insereaz caractere n coninutul textual, o replaceData() nlocuiete un subir al coninutului textual cu altul, o subStringData() citete un subir al coninutului textual, o normalize() concateneaz coninuturi textuale adiacente, pentru a obine un unic nod fiu de tip text, o splitText() separ un nod de tip text n dou noduri de tip text (inversul funciei normalize). n continuare se vor indica o serie de diferene ntre codul AJAX din acest exemplu fa de exemplul precedent, al formularului cu codul potal. 1.Definirea poriunilor de document ce urmeaz a fi manipulate n exemplul precedent, dac s-a dorit generarea de marcatori noi n pagin (mesajul de eroare colorat cu rou), s-a rezervat zona respectiv sub forma unui paragraf vid cu identificator unic. n exemplul actual, zona ce s-a dorit a fi manipulat s-a definit ca un bloc div avantajul fiind c acesta poate ncadra o poriune orict de complex i nu interfereaz cu formatul documentului (P definete un paragraf, deci las un rnd gol naintea i dup coninutul su textual). 2.Localizarea poriunii de document de manipulat n exemplul cu formularul, localizarea zonei de modificat s-a realizat cu ajutorul atributului id i a metodei getElementById. n exemplul actual, blocul div nu are un atribut de identificare (nu nseamn c nu ar putea avea), aadar e localizat prin parcurgerea arborelui DOM ncepnd de la rdcin: mai nti se caut, printre fiii rdcinii, acel fiu cu numele BODY, apoi se caut ntre fiii nodului BODY, primul fiu cu numele DIV. Aceasta implic dou cicluri de parcurgere i reprezint un dezavantaj, nu doar sub aspectul complexitii codului. Mai exact, browserele care convertesc cod 43
HTML n cod compatibil XML apeleaz la diferite metode de conversie. Unele browsere convertesc caracterele albe n noduri de tip text. Mai exact, marcatorul body din exemplul de mai jos va avea trei noduri fiu i nu unul, cum ar dicta intuiia:
<body> <b>xxxxxxx</b> </body>
Cele trei noduri vor fi, n ordine, un nod de tip text (caractere albe din faa lui b), un nod de tip element (marcatorul b) i un al doilea nod de tip text (Enterul de dup nchiderea lui b) generarea acestor noduri poate fi verificat cu instrumente DOM Inspector. Aadar, chiar dac rolul caracterelor albe este de a indenta codul surs pentru o citire mai facil, exist riscul ca acestea s fie convertite n noduri DOM. Pentru a nu obine astfel de noduri inutile, codul surs ar trebui s arate ca n exemplul
<body><b>xxxxxxx</b></body>
...ceea ce, evident, nu este convenabil. Crearea nodurilor "albe" are efecte asupra operaiilor de parcurgerea a arborilor DOM (de exemplu, afecteaz lungimea vectorului childNodes). Un alt exemplu similar este faptul c prin conversie la XML, unele browsere adaug n mod forat marcatori noi: de exemplu e posibil ca n cadrul unui tabel s se adauge forat marcatorii thead i tbody (antet i corp de tabel, o separare neglijat de muli designeri HTML care se rezum la a descrie rndurile tabelului prin tr)! Dac parcurgerea arborelui DOM se face pe baz de poziie (de exemplu parcurgerea vectorului childNodes sau cu nextSibling) este posibil ca numrul nodurilor fiu s nu fie exact cel la care se ateapt programatorul, problema fiind agravat de faptul c nu toate browserele aplic acelai tratament codului HTML. n acest caz, recomandm metoda getElementById, deci folosirea atributelor id pentru blocurile div i pentru orice marcator ce urmeaz a fi accesat de JavaScript. Exist i alte alternative de localizare a componentelor paginii HTML: getElementsByTagName este o metod ce identific marcatorii prin eticheta lor. Dezavantajul n acest caz este c e posibil ca documentul s conin mai muli marcatori similari (mai multe paragrafe, mai multe blocuri div), caz n care metoda returneaz un vector al tuturor nodurilor gsite. Vector care, evident, va trebui parcurs n cutarea blocului dorit. Totui, aici nu mai avem pericolele parcurgerii vectorului childNodes, ci avem efectiv un vector cu toi marcatorii cu aceeai etichet, n ordinea apariiei lor n document. Desigur, rmne incomod necesitatea de a cunoate poziia marcatorului cutat. n unele situaii, n care se dorete manipularea simultan a tuturor marcatorilor cu aceeai etichet, getElementsByTagName devine soluia ideal (spre exemplu, dac se dorete manipularea identic a tuturor cmpurilor unui formular, a tuturor paragrafelor sau blocurilor div dintr-un document). Mai mult, getElementsByTagName devine necesar atunci cnd getElementById nu se poate folosi (exemplu: atunci cnd se manipuleaz ali arbori XML dect arborele paginii). 3.Generarea de coninut nou n zona de document localizat O alt diferen ntre cele dou exemple este mecanismul prin care se creeaz coninut nou n pagin (marcatori i/sau coninut textual). n exemplul cu codul potal, mesajul de eroare i formatul su sunt create cu ajutorul proprietii innerHTML a marcatorului localizat (al paragrafului). n exemplul actual, coninutul blocului div e generat prin construirea unui nod nou de tip text (createTextNode) i plasarea sa n locul nodului text existent n blocul div (replaceChild). Proprietatea innerHTML a fost introdus n Internet Explorer dar a fost ulterior adoptat i de Mozilla. Este, evident, mai comod dect apelarea metodei replaceChild (sau addChild) pentru fiecare nod modificat/creat deoarece poate crea un subarbore XML din coninut HTML orict de complex. Proprietatea innerHTML este nrudit cu metodele innerText i outerHTML Rolul lui innerText e similar, dar irul de caractere atribuit e tratat ca text i nu e convertit n noduri DOM. n exemplul cu codul potal, atribuirea textului "<font color=red>...</font>" nu a avut ca efect doar inserarea de text, ci chiar crearea unui nod-element nou, la rndul su cu propriul nod fiu de tip text. n schimb, innerText are performane superioare, de aceea e frecvent folosit pentru adugare de coninut textual, iar innerHTML pentru adugare de coninut complex, ce include marcatori;
44
n timp ce innerHTML nlocuiete coninutul marcatorului/nodului curent, outerHTML nlocuiete complet marcatorul/nodul curent, deci etichetele i coninutul/fiii acestuia! Avnd n vedere c datele serverului sunt cele care determin modificri precum innerHTML i outerHTML, putem spune c outerHTML confer o putere mai mare serverului n a restructura pagina, n timp ce innerHTML confer responsabilitatea structurii clientului, serverul manipulnd doar coninutul.
La enumerarea proprietilor DOM, am sugerat i alte ci de a accesa i manipula coninutul marcatorilor. 4.Manipularea de atribute Exemplul cu codul potal acceseaz i modific atributul value al marcatorilor input prin calificarea proprietii value:
document.getElementsById("idcamp").value="valoarea noua a campului"
Al doilea exemplu acceseaz i modific (creeaz) atributul align al blocului div prin metoda setAttribute:
noddiv.setAttribute("align","right")
Metoda setAttribute este nrudit cu getAttribute, care citete valoarea unui atribut. n consecin exemplul actual poate fi scris ntr-o form mai comod astfel:
<html> <head> <script type="text/javascript"> function modificaPagina() { var noddiv=document.getElementById("bloc1") noddiv.innerHTML="Text nou" noddiv.align="right" } </script> </head> <body> <div id=bloc1>Text vechi</div> <button onclick="modificaPagina()">Apasa pentru modificare text</button> </body> </html>
Ambele variante de acces la atribute sunt acceptabile pentru majoritatea atributelor deoarece, n general, pentru fiecare atribut al unui marcator din pagin se genereaz n DOM o proprietate a obiectului (nodului) corespunztor marcatorului. Aceast afirmaie are un caracter general, dar nu unul absolut exist cazuri n care numele atributului nu este acelai cu numele proprietii. n general la acest capitol apar diferene suprtoare ntre browsere. Probabil cele mai importante excepii sunt atributele class i style, care asociaz marcatorilor stiluri CSS. Mozilla Firefox permite o construcie precum
<html> <head> <style type="text/css"> .stil1 {background:blue} .stil2 {background:red} </style> <script type="text/javascript">
45
function modificaPagina() { var noddiv=document.getElementById("bloc1") noddiv.setAttribute("class","stil2") } </script> </head> <body> <div id=bloc1 class=stil1>Text vechi</div> <button onclick="modificaPagina()">Apasa pentru modificare text</button> </body> </html>
Noua form a exemplului are ca efect faptul c, la clic, se modific formatul blocului div, prin aceea c asocierea div-stil1 e nlocuit cu asocierea div-stil2 (diferena ntre cele dou stiluri e culoarea de fundal, dup cum arat descrierile de stil din antetul paginii). Acesta e mecanismul de baz prin care paginile AJAX capt dinamic din punct de vedere vizual modificarea atributelor class pot avea efecte majore asupra modului n care arat interfaa iar legarea acestor modificri la evenimentele utilizatorului confer o interactivitate mrit documentelor HTML. Totui, modificarea atributului class n acest mod funcioneaz doar n Firefox! Mai mult, nici n Firefox, nici n IE, NU funcioneaz modificarea atributului de stil prin cealalt metod: noddiv.class="stil2" nu are nici un efect! n schimb, Internet Explorer permite modificarea atributului de stil prin modificarea proprietii className:
noddiv.setAttribute("className","stil2")
Pe de alt parte, aceast metod nu e tolerat de Firefox! n ciuda ignorrii acestei incompatibiliti de ctre productorii de browsere, s-au gsit soluii de compromis: -soluia 1: prezena ambelor metode n acelai script (neelegant)
noddiv.setAttribute("class","stil2") noddiv.setAttribute("className","stil2")
-soluia 2: folosirea ambelor metode alternativ, n funcie de existena unui obiect specific unuia din browsere:
noddiv.setAttribute(document.all?"className":"class","stil2")
(obiectul document.all e un un obiect care exist doar n Internet Explorer; dac valoarea sa e true, se folosete argumentul pentru IE, altfel, cel pentru Firefox; acest gen de verificri poart denumirea de browser sniffing i nu sunt foarte fiabile e posibil ca n noi versiuni ale browserelor situaia existenei sau inexistenei unui astfel de obiect s se schimbe 22) - soluia 3, recomandat:
noddiv.className="stil2"
Aceast construcie va funciona n ambele browsere: className exist ca proprietate a unui obiect-element n ambele browsere, n timp ce class exist ca proprietate doar n Firefox, iar className exist ca atribut doar n IE. O problem similar apare la folosirea celuilalt atribut de aplicare a stilurilor CSS, style prin care stilul se descrie direct n marcator i nu se apeleaz din antetul paginii. Pentru style, metoda care funcioneaz n ambele browsere este: http://www.quirksmode.org/js/detect.html ofer o funcie complex pentru detectarea precis a browserului i platformei clientului 46
22
noddiv.style.cssText="background:red"
Mai mult, JavaScript are acces direct la oricare din proprietile stilurilor CSS23. Aadar, ultimul exemplu ar putea arta i astfel, n ambele browsere:
noddiv.style.background="red"
Unul din cele mai frecvente mecanisme n manipularea paginii AJAX este controlul vizibilitii unor poriuni de document (de obicei blocuri div). Aceasta se obine printr-o funcie care comut un bloc div ntre strile vizibil i invizibil, prin modificarea atributului de stil display:
function vizibilitate() { noddiv=document.elementById("blocdiv") if (noddiv.style.display=="none") noddiv.style.display="" else noddiv.style.display="none" } Not:Pentru mai multe detalii legate de browsere n ce privete manipularea http://www.quirksmode.org/dom/w3c_core.html incompatibilitile dintre atributelor, recomandm
2.2.3. XML DOM versus HTML DOM

S-a demonstrat pn aici c accesul la elementele paginii prin intermediul modelului DOM poate avea loc pe mai multe ci. Aceasta se datoreaz pe de o parte versatilitii modelului DOM, dar i faptului c acesta e disponibil n dou variante: XML DOM, modelul fundamental, ce poate fi folosit pe orice tip de cod XML (inclusiv codul XHTML al paginii AJAX); acesta ofer metodele de parcurgere a arborelui din nod n nod (childNodes, nextSibling, parentNode etc.) i cele de extragere a datelor (nodeValue,setAttribute,getAttribute etc.); funciile XML DOM pot fi utilizate att asupra arborelui paginii ct i asupra altor arbori XML (date primite prin proprietatea responseXML). Modelul XML DOM este suportat de majoritatea limbajelor de programare ce permit prelucrare de cod XML; HTML DOM, o versiune DOM optimizat pentru paginile XHTML, ce ofer, n plus fa de XML DOM, versiuni prescurtate sau metode mai directe dect cele generale; funciile HTML DOM pot fi folosite asupra arborelui paginii AJAX, dar nu pot fi folosite asupra altor arbori XML, cum ar fi rspunsul serverului n format XML (proprietatea responseXML a obiectului XHR). Detaliem o parte din facilitile suplimentare pe care le ofer HTML DOM i care nu sunt disponibile prin XML DOM: accesarea a numerose atribute prin calificare: nod.atribut n loc de getAttribute() i setAttribute(); accesarea coninutului unui marcator prin innerHTML i a marcatorului mpreun cu coninutul su prin outerHTML; XML DOM impune s se foloseasc n acest scop nodeValue sau metodele de acces la fiii nodului curent (replaceChild, appendChild etc.); obiectul document este proprietate a obiectului window, ce reprezint fereastra browserului i ofer acces la funcionalitatea browserului (istoricul paginilor vizitate, butoanele Back i Forward, etc.); prescurtarea accesului la o serie de marcatori unici sau frecvent ntlnii, cum ar fi: o document.body n loc de document.getElementsByTagName("body")[0] o document.forms[ ] un vector ce stocheaz toate formularele paginii (getElementsByTagName("form")[ ] n XML DOM); o document.images[ ] un vector ce stocheaz toate imaginile paginii (getElementsByTagName("img")[ ] n XML DOM);
Prin acces direct ne referim la faptul c orice proprietate CSS devine proprietate JavaScript i accesul la acestea nu mai trebuie intermediat de cunoaterea numelui stilului (deci problema atributului class e ocolit). 47
23
o o o o o
document.links[ ] un vector cu toate hiperlegturile i hrile de imagini (marcatorii area) ale paginii; document.form[0].elements[ ] un vector cu toate elementele din primul formular al paginii (getElementsByTagName("form")[0].childNodes[] n XML DOM, cu evitarea "nodurilor albe"); document.anchors[ ] un vector cu toate ancorele (marcatorii a cu atributul name); tabel.rows[] un vector cu elementele tr ale obiectului tabel (creat anterior); tabel.rows[0].cells[] un vector cu celulele primului rnd al obiectului tabel.
la
Not: Referina oficial HTML DOM complet poate fi consultat adresa: http://www.w3schools.com/HTMLDOM/dom_reference.asp
La aceste diferene adugm o excepie deosebit: getElementById poate fi folosit doar n arborele DOM al paginii, dei teoretic este definit i n modelul XML DOM. Explicaia st n faptul c un atribut de identificare este definit printr-un vocabular XML (deci nu prin numele atributului care poate s fie sau nu "id"). Un vocabular XML nsoete un document XML i descrie pentru acesta lista marcatorilor permii, a imbricrilor permise i eventual a semnificaiei lor. E un caz particular faptul c vocabularul XHTML (vocabularul XML care reglementeaz utilizarea marcatorilor HTML), definete atributul id ca avnd rol de identificator ntr-o pagin HTML. La modul general, pachetele de date structurate prin marcatori XML trebuie s fie nsoite de vocabularul aferent. Operaia prin care un document XML este comparat cu regulile unui vocabular este similar cu cea prin care un document HTML este interpretat conform sintaxei HTML i poart numele de validare. Validarea HTML (fa de vocabularul XHTML) este integrat implicit n browsere dar nu i validarea de cod XML generic (fa de diverse vocabulare). Aadar browserul nu are cum s determine, n lipsa vocabularului aferent, care atribut are rol de identificator ntr-un cod XML non-HTML, ceea ce face ca getElementById s nu funcioneze pe rspunsul obiectului XHR!
Not: getElementById funcioneaz n alte medii de programare, ce includ valid are i gestiunea vocabularelor XML. n general validatoarele XML sunt instrumente off -line - o validare aplicat la fiecare transfer XHR ar afecta grav performana aplicaiei (ar presupune un dublu transfer al datelor XML i al vocabularului fa de care se valideaz, la care se adaug efortul de validare). Extensia Firefox numit XML Developer Toolbar ofer instrumente de validare n browser i poate fi descrcat gratuit de pe site -ul oficial al browserului. Acestea sunt ns validatoare off -line, inaccesibile obiectului XHR.
2.2.4. Obiectul XHR

Detaliile legate de mecanismul de transfer al datelor ntre clientul AJAX i server vor fi discutate pe un exemplu simplificat din cele anterioare:
<html> <head> <script type="text/javascript"> var xhr function modifica() { try { xhr = new ActiveXObject("Msxml2.XMLHTTP") } catch (e) { try { xhr = new ActiveXObject("Microsoft.XMLHTTP") } catch (e) { xhr = false } } if (!xhr && typeof XMLHttpRequest !="undefined") {
48
xhr = new XMLHttpRequest() } xhr.open("GET","script.php") xhr.onreadystatechange=function() { if (xhr.readyState != 4) return; document.getElementById("mesaj").innerHTML = xhr.responseText } xhr.send(null) } </script> </head> <body> <div id="mesaj"></div> <button onclick="modifica()">Click Me</button> </body> </html>
Pagina conine un bloc div gol, care este completat la apsarea unui buton cu textul primit de la server. Sintetizm n continuare componentele mecanismului XHR: 1. Crearea obiectului XHR - are loc prin trei tentative de instaniere, datorit faptului c diverse browsere implementeaz sub denumiri diferite clasa XMLHttpRequest. 2. Trimiterea de date spre server - e asigurat de metodele open (dac se trimit variabile GET) i send (dac se trimit variabile POST); n exemplul de fa open nu trimite nici o variabil, send trimite caracterul null, aadar tot ce se transmite spre server e o solicitare a unui script PHP. 3. Generarea datelor de ctre server - scriptul PHP nu primete date de la client, aa c exemplul poate fi verificat cu un script simplu care genereaz un ir de caractere:
<?php ?> print "textul mesajului";
4. Recepionarea datelor de la server - are loc doar cnd proprietatea readyState capt valoarea 4 (condiie care poate fi completat cu status != 200 dac se dorete prevenirea erorilor de conexiune); n exemplul de fa, datele sunt preluate de proprietatea responseText sub form de text brut, pe care se pot aplica operaii de manipulare a irurilor de caractere; n alte situaii, pe care le vom exemplifica n alte contexte, datele pot fi preluate prin proprietatea responseXML, direct ca arbore DOM, pe care se pot aplica operaii de manipulare DOM; n ultimii ani, adepii AJAX au promovat i un al treilea format de date, JSON, care se preia din responseText i se convertete n obiect JavaScript prin funcii specifice de conversie; JSON are fa de XML avantajul simplitii iar fa de textul brut avantajul complexitii structurilor de date capitolele ce urmeaz vor prezenta i exemple n acest sens;
Not: Nu toate funciile i proprietile DOM cu care se lucreaz asupra paginii HTML pot fi folosite i asupra pachetului de date responseXML. Rspunsul serverului va fi prelucrat obligatoriu prin XML DOM, metodele HTML DOM re turnnd erori. n paragraful XML DOM vs. HTML DOM s-au detaliat o parte din diferene.
5. Utilizarea datelor de la server
49
- are loc prin utilizarea datelor extrase din responseText; n acest caz, valoarea sa este atribuit coninutului textual al marcatorului cu id=mesaj - fiind vorba de comunicare asincron (metoda open nu a folosit argumentul false), momentul la care are loc citirea lui responseText este declanarea evenimentului readystatechange cu readyState=4 6. Reacia paginii HTML la datele serverului - blocul div anterior definit n pagin ca o zon vid a documentului e completat cu datele serverului; acest proces e declanat de evenimentul click pe butonul paginii. n plus fa de acest mecanism de baz obiectul XHR poate trimite i recepta date direct prin antetul HTTP (care n mod normal e construit de ctre protocol, att n browser ct i la server, pentru a descrie mediul de comunicare dintre cele dou pri). Manipularea antetului HTTP poate fi realizat prin metodele setRequestHeader(), getResponseHeader() i getAllResponseHeader(). Exemplul de mai jos altereaz numele browserului din antetul HTTP al cererii, astfel nct serverul s nu mai poat extrage din variabile de mediu identitatea browserului:
xhr.setRequestHeader("User-Agent","Browserul meu!")
"User-Agent" este cmpul din antetul HTTP care indic tipul de browser care a trimis cererea, folosit adesea de ctre scripturile server pentru a returna coninut diferit n funcie de browser. "Browserul meu!" este valoarea pe care o inserm forat n antetul HTTP. Linia de cod de mai sus se va insera n exemplul anterior, ntre apelurile xhr.open i xhr.send, adic ntre definirea cererii HTTP i efectuarea sa. Pentru verificare, se va modifica scriptul php destinatar nct s returneze valoarea cmpului User-Agent din antetul HTTP:
<?php ?> print $_SERVER["HTTP_USER_AGENT"];
n urma modificrilor, exemplul anterior va afia n blocul div textul "Browserul meu!" la apsarea butonului. Dac tergem apelul metodei setRequestHeader, textul afiat n blocul div va fi identitatea browserului.
Not: Pentru lista cmpurilor antetului HTTP, recomandm consultarea adresei http://www.w3.org/Protocols/rfc2616/rfc2616 -sec14.html. De asemenea, o multitudine de instrumente de tip HTTP Header Vi ewer sunt disponibile pentru descrcare gratuit, pentru a permite vizualizarea antetului HTTP direct n browser. Exemple de astfel de instrumente sunt Tamper Data extensie add-on instalabil de pe site -ul oficial Mozilla Firefox sau HTTP Watch (www.http watch.com) pentru Internet Explorer gratuit n versiunea Basic Edition.
Exemplul cu completarea codului potal declana un schimb de date cu serverul fr ca utilizatorul s fie neaprat contient de asta. n aplicaiile Web tradiionale, schimbul de date cu serverul e declanat prin aciuni contiente ale utilizatorului: clic pe un buton submit sau pe o hiperlegtur. Obiectul XHR permite, dup cum s-a vzut, ca schimbul de date s aib loc la orice moment n moduri mult mai subtile i care nu interfereaz cu experiena utilizrii aplicaiei. Totui, aplicaiile AJAX trebuie i pot s implementeze transferul complet al datelor unui formular prin apsarea unui buton de trimitere. Obiectul XHR poate fi utilizat pentru a trimite datele unui formular prin metoda POST, operaiune frecvent n aplicaiile Web. n acest caz, modificrile n procedura de trimitere a datelor vor fi: formularul nu va mai avea un buton submit, ci un buton oarecare de tip button, cruia i se va asocia funcia de trimitere a datelor ca handler onclick; folosirea unui buton submit ar realiza un transfer de date n sens clasic, sincron, cu refresh sau ncrcare de pagin nou! formularul nu va mai avea atributele method i action, deoarece acestea sunt fixate de obiectul XHR; datele se preiau una cte una, prin intermediul DOM, din atributele value ale cmpurilor formularului; datele se concateneaz ntr-un ir de interogare similar cu cel trimis prin metoda GET; se recomand ca valorile concatenate s fie transformate prin funcie encodeURIComponent(), 50
pentru a conserva anumite caractere speciale care ar putea fi tastate n formular i ar putea induce confuzii n interpretarea irului de interogare (=, +, &); se modific o serie de cmpuri ale antetului HTTP (care, n aplicaiile tradiionale, se modific automat la apsarea butonului Submit) - obligatoriu se modific tipul coninutului postat, opional se pot modifica numrul de variabile i tipul conexiunii (dac scriptul server are nevoie de astfel de informaii); se trimit datele ca argument al funciei send(). Exemplu:
<html> <script type="text/javascript"> function creareXHR() { ................// instantierea xhr } function trimite() { creareXHR() valori=new Object() valori["nume"]=document.getElementById("TXnume").value valori["codpostal"]=document.getElementById("TXcodpostal").value valori["adresa"]=document.getElementById("TXadresa").value valori["oras"]=document.getElementById("TXoras").value valori["judet"]=document.getElementById("TXjudet").value sir="" for (cheie in valori) { sir=sir+cheie+"="+encodeURIComponent(valori[cheie])+"&" } xhr.open("POST","script.php") xhr.setRequestHeader ("Content-Type", "application/x-www-form-urlencoded") xhr.onreadystatechange=procesare xhr.send(sir) } function procesare() { if (xhr.readyState!=4) return alert("serverul a raspuns cu:"+xhr.responseText) .................//procesarea raspunsului serverului } </script> </head> <body>
<h1>Introduceti datele</h1> <form> <table> <tr> <td>Nume</td> <td><input type=text </tr> <tr> <td>CodPostal</td> <td><input type=text </tr> <tr> <td>Adresa</td> <td><input type=text </tr> <tr> <td>Oras</td> <td><input type=text </tr> <tr>
id=TXnume ></td>
id=TXcodpostal></td>
id=TXadresa size=50></td>
id=TXoras ></td>
51
</tr> <tr>
<td>Judet</td> <td><input type=text id=TXjudet ></td> <td></td> <td><input type=button value=Trimite onclick="trimite()" ></td>
</tr> </table> </form> </body> </html>
Scriptul server:
<?php print "datele primite la server sunt:".$_POST["nume"]. ",".$_POST["codpostal"].",".$_POST["adresa"].",".$_POST["oras"].",".$_POST["judet"]; ?> Not: Avertizm c n timpul testrii metodei POST, consola Firebug nu afieaz o eroare atunci cnd scriptul server nu primete variabilele POST ateptate (de exemplu pentru c s-a tastat greit numele lor). n schimb, rubrica Response din Firebug afieaz mesajul "Loading..." care semnific faptul c serverul se afl ntr -o stare de ateptare.
2.2.5. Cadrele interne invizibile

Cadrele interne invizibile sunt folosite ca alternativ de comunicare cu serverul, atunci cnd obiectul XHR nu este instalat n browser 24. Cadrele interne s-au folosit frecvent nainte apariiei obiectului XHR pentru a schimba date cu serverul i sunt chiar i n prezent preferate de unii dezvoltatori AJAX. Acestea prezint totui o serie de dezavantaje: Cadrele interne nu au fost create n acest scop; rolul lor este, asemeni cadrelor normale, s afieze o pagin Web n interiorul altei pagini diferena fa de cadrele normale este c cele interne nu se definesc prin mprirea ferestrei browserului pe orizontal sau vertical (cu FRAMESET), ci prin definirea unei suprafee dreptunghiulare n interiorul paginii (cu IFRAME). Cadrele interne devin invizibile dac sunt create cu dimensiunea 0x0, ceea ce permite ca pagina ncrcat de cadru s nu fie o pagin HTML propriu-zis, ci un set de date invizibil utilizatorului. Acest set de date poate fi apoi accesat prin JavaScript, din proprietile cadrului intern; mprosptarea coninutului unui cadru, fie i unul invizibil, genereaz un sunet n unele browsere care poate deveni iritant pentru utilizator; Accesul la coninutul unui cadru intern e mai dificil dect accesul la rspunsul XHR; browserul presupune c un cadru intern, fie i invizibil, conine o pagin HTML complet (cu head, body etc.). Chiar dac pagina respectiv este doar un ir de caractere cu datele serverului, acesta se acceseaz prin proprietatea innerHTML a marcatorului BODY al paginii coninute n cadru; Un cadru intern poate stoca doar iruri de caractere interpretabile ca HTML. Cadrul intern nu aplic parsing DOM implicit la pachete XML, aa cum face obiectul XHR prin proprietatea responseXML. n consecin, dac aplicaia trebuie s gestioneze date XML, trebuie s instanieze explicit un arbore DOM n care s salveze rspunsul XML. Instanierea unui arbore DOM se realizeaz n JavaScript prin dou metode, ce vor trebui incluse ntr-o structur trycatch:
arbore=new document.implementation.createDocument() pentru Firefox arbore=new ActiveX("Microsoft.XMLDOM") pentru Internet Explorer arbore.load(raspuns) variabilei raspuns in prealabil i-a fost atribuit coninutul
cadrului
Not: n timpul depanrilor n Firefox cu extensia Firebug, opiunea Console nu mai poate fi folosit pentru monitorizarea schimburilor ntre client i server (ac easta monitorizeaz doar cererile XHR). n schimb, se poate folosi opiunea Net care monitorizeaz schimburile
Poate fi vorba de browsere ce nu suport XHR dar i de browserul Internet Explorer cu obiectele ActiveX dezactivate. 52
24
client-server indiferent de calea pe care sunt realizate, inclusiv prin cadre.
Cadrele interne invizibile au i un alt rol, deosebit de important, pe care obiectul XHR nu l poate ndeplini. Cu ajutorul cadrelor se pot depi limitrile AJAX cu privire la upload-ul de fiiere i mecanismul Back/Forward al browserului. Modelul AJAX implementat prin cadre invizibile difer categoric de modelul bazat pe XHR. Unii autori consider c folosirea cadrelor invizibile nu ar trebui ncadrat n modelul AJAX, fiind mai degrab o simulare a sa. Ali autori consider c nu este nimic n denumirea Asynchronous JavaScript and XML care s exclud cadrele interne i s impun obiectul XHR. ntr-adevr, acronimul AJAX nglobeaz elementele: Comunicare asincron cu serverul (schimb de date care nu ntrerupe aplicaia i experiena de utilizare); JavaScript, ca limbaj de programare; XML poate s se refere la obiectul XHR (proprietatea responseXML), dar poate s se refere i la faptul c pagina HTML e tratat de JavaScript ca arbore XML (DOM). Cadrele interne respect toate aceste cerine. Ultimele dou sunt utilizate similar, diferena apare doar la modul n care e implementat comunicarea asincron: ntr-un site cu dou cadre, funcionarea unui cadru nu este afectat de faptul c al doilea cadru sufer un refresh sau o rencrcare de pagin. Acest al doilea cadru poate fi folosit pentru a schimba date cu serverul, n timp ce utilizarea aplicaiei se desfoar nentrerupt n primul cadru. Relum exemplul cu codul potal, n versiunea cu cadre:
<html> <head> <script type="text/javascript"> function trimite(cod) { cadru=document.getElementById("cadruint") cadru.src="scripturi.php?CodPostal="+cod } function citestedate(cdr) { documentcadru=cdr.contentWindow.document raspuns=documentcadru.body.innerHTML procesare(raspuns) } function procesare(rasp) { vector=rasp.split(",") document.getElementById("TXoras").value=vector[0] document.getElementById("TXjudet").value=vector[1] document.getElementById("TXadresa").value=vector[2] } </script> </head> <body> <iframe id=cadruint width=400 height=50 src="" onload="citestedate(this)"> </iframe> <h1>Introduceti datele</h1> <form > <table> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal onblur="trimite(this.value)"></td> </tr> <tr> <td>Adresa</td>
53
</tr> <tr> </tr> <tr> </tr> <tr>
<td><input type=text id=TXadresa size=50></td> <td>Oras</td> <td><input type=text id=TXoras ></td> <td>Judet</td> <td><input type=text id=TXjudet ></td> <td></td> <td><input type=submit value=Trimite ></td>
</tr> </table> </form> </body> </html>
Se remarc: n interiorul paginii s-a definit un cadru intern, identificat prin id. Dimensiunile iniiale ale cadrului vor permite, n scopul testrii exemplului, s se observe direct n cadru rspunsul serverului. Dup ce exemplul se dovedete funcional, dimensiunile cadrului se pot modifica la valoarea 0 pentru a obine un cadru invizibil, ce nu interfereaz cu experiena utilizrii aplicaiei; Alt atribut esenial al cadrului este src, ce indic pagina pe care trebuie s o afieze cadrul. Iniial, atributul este vid, aadar cadrul va fi gol n prima faz. Apoi, dup completarea codului potal, n cadrul funciei trimite(), datele sunt trimise prin modificarea valorii src a cadrului. Desigur, metoda nu este foarte intuitiv (acesta fiind unul din motivele optrii pentru varianta XHR). Teoretic, rolul cadrului este de a afia pagina indicat de src. Practic, acea pagin poate fi un script server a crui adres conine variabile GET concatenate! Aadar, trimiterea de date prin metoda cadrelor are loc de cte ori JavaScript modific valoarea atributului src; Rspunsul sosete n format text, ca rezultat al scriptului server a crui adres s-a trecut n atributul src. Rspunsul este imediat afiat n cadru. n paginile Web clasice, acest rspuns este chiar o pagin generat dinamic n scopul afirii. n AJAX, acest rspuns este un ir de caractere care va fi ascuns atunci cnd cadrul devine invizibil. Scopul acestui ir de caractere nu mai este s fie afiat, ci s fie accesat prin JavaScript, ceea ce se ntmpl imediat dup sosirea rspunsului (prin handlerul onload al cadrului); Rspunsul este capturat de JavaScript n handlerul onload pentru a avea garania c datele au sosit nainte s nceap procesarea lor. n timpul receptrii datelor, pagina principal poate fi utilizat fr ntrerupere, ceea ce asigur caracterul asincron al schimbului de date. Extragerea datelor a fost mult vreme aspectul cel mai problematic n modelul AJAX cu cadre, deoarece fiecare tip de browser folosea alte metode pentru a accesa coninutul unui cadru. n prezent se pot folosi dou tehnici n acest scop: o tehnica pull (extragerea datelor din cadru): coninutul cadrului se acceseaz din pagina principal prin nodcadru.contentWindow.document.body.innerHTML, dup cum se remarc n funcia citestedate(); o tehnica push (mpingerea datelor dinspre cadru): codul surs cu care serverul alimenteaz cadrul va conine cod JavaScript care apeleaz funcia de prelucrare a rspunsului din pagina principal. Modificarea prin DOM a atributului src al cadrului nu e singura metod de a ncrca date (sau documente) ntr-un cadru. n acelai scop se pot folosi orice operaii care permit ncrcarea unei pagini ntr-un cadru int (prin atributul target): <a href=script.php?variabila=valoare target=cadru>....</a> - o hiperlegtur a crei pagin int va fi afiat n cadrul indicat prin target; ca i n exemplul anterior, pagina int poate fi un script server la a crui adres se pot concatena variabile GET; <form action=script.php target=cadru>....</form> - un formular ale crui date vor fi trimise spre un script al crui rspuns va fi afiat n cadrul indicat prin target; aceasta este, dealtfel, metoda prin care modelul AJAX bazat pe cadre interne permite trimiterea de variabile POST sau uploadul de fiiere. Totui, cele dou metode sunt replici ale metodelor tradiionale prin care utilizatorul decide, prin clic-uri, cnd are loc trimiterea de date spre server. Modificarea dinamic a atributului src confer
54
o dinamic superioar i o subtilitate a schimburilor de date mai apropiat de cea promovat de modelul AJAX. Se poate remarca o oarecare simplitate comparativ cu metoda XHR. Totui, pentru a se asigura compatibilitatea cross-browser, funcia citestedate() devine mult mai complicat, pentru a garanta faptul c se extrage coninutul cadrului indiferent de browser. Ca i n cazul XHR, aceasta se obine printr-o structur try-catch.
2.3. Platforme i biblioteci AJAX 2.3.1. Rolul platformelor AJAX

Modelul AJAX a dus inevitabil la apariia unor platforme de dezvoltare a aplicaiilor cu instrumente i componente de nivel nalt, uor de integrat i reutilizabile. Pe scurt, e vorba de instrumente menite s accelereze procesul de producie a unui site AJAX. Exemplele anterioare au demonstrat nucleul oricrei aplicaii AJAX de la instanierea prin tentative i excepii a obiectului XHR pn la recepionarea datelor de la server. Deoarece acest mecanism e folosit de majoritatea aplicaiilor AJAX n mod identic, dezvoltatorii Web au definit funcii de nivel mai nalt care s ncapsuleze acest mecanism, mascnd detaliile sale. Mai mult, s-au creat componente care s compenseze i s mascheze neajunsuri AJAX precum imposibilitatea de a face upload de fiiere sau de a crea semne de carte pentru stri diferite ale aplicaiei. Aceast tendin a dus la apariia unei multitudini de "platforme" AJAX bazate pe pachete ce implementeaz diverse funcionaliti ale modelului, asigurnd nivele de abstractizare i o separare a sarcinilor echipelor de lucru chiar mai puternic dect cea sugerat de structura intern a codului AJAX (structur cu blocuri div, formatri cu CSS, manipulare cu JavaScript, conectare la server cu XHR) . Majoritatea platformelor AJAX sunt construite pe nivelele: Nivel 0: mecanisme de nivel sczut, reutilizabil, de conectare asincron la server: obiectul XHR sau cadrele interne; Nivel 1: instrumente de nivel nalt de comunicare cu serverul (ce mascheaz detaliile nivelului 0) Dojo, JSON-RPC, Prototype, Direct Web Remoting; Nivel 2: instrumente de nivel nalt de construire a interfeei cu utilizatorul (construite peste nivelul 1) Dojo ofer instrumente i la acest nivel, SmartClient, Script.aculo.us (bazat pe Prototype); Nivel 3: medii de dezvoltare a aplicaiilor AJAX: Rails, Tapestry, AJAX.NET, SAJAX. Instrumentele de nivel 1 nu sunt altceva dect biblioteci de funcii sau interfee de programare (API) care mpacheteaz instanierea i comunicarea asincron prin obiectul XHR (sau prin alternativ cadrele interne, folosite pentru browserele care nu suport nici una din tentativele de instaniere XHR). Majoritatea instrumentelor de nivel 1 sunt create independent fa de tehnologia folosit de server. Unele, precum Direct Web Remoting, instaleaz i o component Java pe server pentru ascultarea i gestionarea la un nivel mai nalt a cererilor HTTP prin XHR. Altele, precum JSON-RPC, exploateaz modelul ORB (Object Request Broker) pentru a permite accesarea obiectelor server direct din scripturi client. Instrumentele de nivel 2 sunt medii de generare a interfeei cu utilizatorul componente GUI, cu funcionaliti, animaii preprogramate i chiar suport pentru operaii desktop tradiionale precum drag-and-drop. Unele instrumente extind gama de componente GUI pentru a o apropia ct mai mult de cea a interfeei formularelor Windows sau Mac. Instrumente precum Backbase sunt de fapt limbaje de marcare (limbaje XML) ce folosesc proprii marcatori, superiori celor din HTML, mpreun cu funcii cu rol de interpretor. Instrumentele de nivel 3 sunt medii de dezvoltare complexe bazate pe generatoare de cod JavaScript (Ruby on Rails genereaz cod i funcii Prototype la nivelul 1, WebWork2 genereaz cod pentru Dojo); componente (AJAX.NET pe.ntru .NET, Tapestry pentru Java).
Sub aspect istoric, platformele i bibliotecile AJAX constituie cel mai recent pas n evoluia mediilor de programare Web, asigurnd o productivitate nalt i minimiznd efortul conceperii i 55
scrierii codului surs pentru funcionaliti frecvent reutilizate. Se afirm c istoria AJAX a parcurs etapele: pionieratul corespunde apariiei celor dou soluii convergente, aprute iniial independent: o paginile DHTML ce permiteau manipularea coninutului i formatului unei pagini accesnd stiluri CSS primitive prin JavaScript; o mecanismele de comunicare asincron cadrele interne invizibile utilizate frecvent i obiectul XHR, disponibil ncepnd cu anul 2000 i versiunea 5 a browserului Internet Explorer. perioada entuziast corespunde promovrii acronimului AJAX i reunirii sub acesta a mecanismelor definite n perioada anterioar; perioada productiv - axat pe crearea instrumentelor reutilizabile, adic a platformelor i bibliotecilor AJAX; aceast perioad se caracterizeaz prin scderea rolului limbajului JavaScript propriu-zis i creterea rolului funciilor i obiectelor JavaScript oferite de bibliotecile AJAX n efortul de programare Web. Bibliotecile cu cea mai puternic adopie sunt cele de tip open-source: Prototype (niv.1), Script.aculo.us (niv.2), Dojo (niv.1 i 2) i Rails (niv.3).
2.3.2. Comunicarea cu serverul prin pachetul Dojo

Pachetul Dojo e rezultatul unui proiect open-source i poate fi descrcat gratuit la www.dojotoolkit.org. Pachetul include instrumente de nivel 1 i 2 pentru facilitarea dezvoltrii de aplicaii AJAX scalabile, precum i o serie de faciliti ce mascheaz aspectele problematice din AJAX upload de fiiere, creare semne de carte i altele. Componentele pachetului Dojo sunt biblioteca Dojo Core pentru gestiunea comunicrii cu serverul i gestiunea evenimentelor (nivelul 1), biblioteca de animaii, efecte i gestiune drag and drop Dijit (nivelul 2) i biblioteca de extensii DojoX cu instrumente diverse, experimentale i extensibile, pentru ambele nivele. n continuare relum exemplul cu formularul n care se completeaz automat oraul, judeul i strada la completarea de ctre utilizator a codului potal. Codul surs al exemplului este:
<html> <head> <title>Formular</title> <script type="text/javascript"> function createXHR() { var a try { a=new ActiveXObject("Msxml2.XMLHTTP") }catch (e) { try { a=new ActiveXObject("Microsoft.XMLHTTP") }catch (e) {a=false} } if (!a&&typeof XMLHttpRequest!='undefined') {a=new XMLHttpRequest()} return a; } function procesare() { if (xhr.readyState == 4) { if (xhr.status == 200) { var datestring=xhr.responseText var datevect=datestring.split(',') document.getElementById("TXoras").value=datevect[0] document.getElementById("TXjudet").value=datevect[1]
56
} }
} else document.getElementById("Eroare").innerHTML="<font color=red>Eroare de conectare la server!</font>"
document.getElementById("TXadresa").value=datevect[2] document.getElementById("Eroare").innerHTML=""
function date(cod) { xhr=createXHR() xhr.onreadystatechange=procesare xhr.open("GET","script.php?CodPostal="+cod) xhr.send(null) } </script> </head> <body> <h1>Introduceti datele</h1> <form> <table> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal onblur="date(this.value)"></td> </tr> <tr> <td>Adresa</td> <td><input type=text id=TXadresa size=50></td> </tr> <tr> <td>Oras</td> <td><input type=text id=TXoras ></td> </tr> <tr> <td>Judet</td> <td><input type=text id=TXjudet ></td> </tr> <tr> <td></td> <td><input type=submit value=Trimite ></td> </tr> </table> </form> <p id=Eroare></p> </body> </html>
Pentru convertirea paginii la platforma Dojo, pachetul trebuie descrcat de la site-ul www.dojotoolkit.org.25 Arhiva obinut se extrage ntr-un folder din rdcina serverului Web (presupunem c numele acestui folder este dojoroot), apoi biblioteca dojo.js se include n pagin prin:
<script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script>
Apoi, structura codului surs se modific pentru a separa operaiile de prelucrare a datelor n dou funcii: cea care proceseaz datele i cea care proceseaz erorile serverului: La momentul redactrii acestui material, pachetul Dojo se afl la versiunea 1.1.0, sub care au fost testate toate exemplele. Avertizm asupra faptului c modificrile de la o versiune la alta pot fi majore (funcii noi, funcii cu nume schimbate) i c exist numeroase tutoriale Dojo on-line sau n literatur care sunt depite i pot produce confuzii. n acest sens, recomandm consultarea documentaiei oficiale de pe siteul www.dojotoolkit.org pentru a sesiza eventualele modificri care ar putea s apar fa de exemplele din acest material. 57
25
function procesare(raspuns,obiectDojo) { var vect=raspuns.split(',') document.getElementById("TXoras").value=vect[0] document.getElementById("TXjudet").value=vect[1] document.getElementById("TXadresa").value=vect[2] document.getElementById("Eroare").innerHTML="" } function proceroare(raspuns,obiectDojo) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+raspuns+"</font>" }
Se observ c ambele funcii primesc obligatoriu dou argumente primul reprezentnd rspunsul serverului (date sau mesaj de eroare26), al doilea reprezentnd o referin a obiectul Dojo ce gestioneaz conexiunea cu serverul, pentru a permite acces la o serie de proprieti ale sale din interiorul acestor funcii. Pentru comunicarea cu serverul, Dojo ofer funciile xhrGet i xhrPost, corespunztoare metodelor GET i POST. Ambele funcii ncapsuleaz instanierea i utilizarea obiectului XHR (inclusiv testarea strii rspunsului). Noua form a funciei date(), pentru transfer GET, va fi:
function date(cod) { dojo.xhrGet ({ url: "script.php?CodPostal="+cod, handleAs:"text", load: procesare, error: proceroare }) }
Ascunznd partea de instaniere, funcia xhrGet() solicit precizarea argumentelor: url singurul argument obligatoriu, adresa scriptului server solicitat; load funcia ce preia datele de la server pentru prelucrare n caz de succes (nregistrarea evenimentului, testarea strii i codului de eroare sunt mascate de funcia bind()); error funcia ce gestioneaz erorile privind receptarea datelor; handleAs formatul n care se ateapt datele de la server (aici, text brut). n plus fa de aceste argumente, se mai accept i alte argumente, dintre care amintim: content (pentru enumerare de valori de transmis); form (pentru transmiterea tuturor cmpurilor unui formular. n cazul de fa nu a fost nevoie s apelm la ultimele argumente, datele fiind concatenate ca variabile GET la url. Aadar, forma final a antetului de pagin folosind biblioteca Dojo, va fi (corpul paginii rmne neafectat, nu l mai reproducem nc o dat):
<head> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { var datevect=raspuns.split(',') document.getElementById("TXoras").value=datevect[0] document.getElementById("TXjudet").value=datevect[1] document.getElementById("TXadresa").value=datevect[2] document.getElementById("Eroare").innerHTML="" } function proceroare(raspuns,obiectDojo)
Mesajul de eroare e explicitat (text i cod de eroare) doar n Firefox, IE l trateaz ca pe o referin la un obiect-eroare. 58
26
{ }
document.getElementById("Eroare").innerHTML= "<font color=red>Eroare de conectare la server!</font>"+raspuns
function date(cod) { dojo.xhrGet ({ url: "script.php?CodPostal="+cod, handleAs:"text", load: procesare, error: proceroare }) } </script> </head>
Nici unul din aceste exemple nu a exploatat argumentul secund al celor dou funcii handler, obiectDojo. Acesta permite ca din interiorul funciilor s se acceseze proprietile argumentului xhrGet prin construcii de forma:
adresa=obiectDojo.url
Una din proprietile acestui obiect este chiar obiectul xhr, deci accesul direct la rspunsul serverului poate avea forma:
date=obiectDojo.xhr.responseText
n continuare oferim i un exemplu de transfer a datelor prin metoda POST:

<head> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { document.getElementById("confirmare").innerHTML=raspuns } function proceroare(raspuns,obiectDojo) { document.getElementById("confirmare").innerHTML= "<font color=red>Eroare de conectare la server!</font>"+raspuns } function date() { dojo.xhrPost ({ url: "script.php", handleAs:"text", load: procesare, error: proceroare, form: "formular" }) } </script> </head> <body> <h1>Introduceti datele</h1> <form id=formular method=get action=scriptoarecare.php> <table> <tr> <td>Nume</td> <td><input type=text id=TXnume name=nume></td> </tr> <tr>
59
</tr> <tr>
<td>CodPostal</td> <td><input type=text id=TXcodpostal name=cp onblur="date()"></td> <td></td> <td><input type=submit></td>
</form> <p id=confirmare></p> </body> </html>
</tr> </table>
Am simplificat formularul pentru claritate. La testare, se va completa n formular numele i codul potal. La evenimentul blur (prsirea cmpului) pentru TXcodpostal, are loc un transfer spre server a tuturor datelor formularului. Pentru verificare, modificm scriptul PHP astfel nct s testeze dac au ajuns la server dou variabile POST corespunztoare celor dou cmpuri:
<?php ?> print "La server au ajuns numele ".$_POST['nume']. " si codul postal ".$_POST['cp'];
Observaii: S-a folosit dojo.xhrPost n loc de xhrGet; n argumentul funciei xhrPost s-a adugat proprietatea form, cu identificatorul formularului; Formularul a primit un atribut id, pentru a fi identificat de funcia xhrPost; Atributele method i action ale formularului sunt ignorate! Acestea sunt valabile doar pentru evenimentul submit (apsarea butonului submit sau o funcie handler pentru onsubmit). Ori n cazul nostru, obiectul XHR realizeaz transferul la evenimentul blur, folosind un alt script server i o alt metod dect cele declarate de formular (proprietatea url e preferat atributului action, funcia xhrPost e preferat atributului method!). Practic, dup cum s-a observat i n exemplele precedente, prezena atributelor method i action e redundant; Scriptul server recepteaz datele de la XHR n variabile POST; Rspunsul serverului este stocat direct n paragraful cu ID=confirmare; Variabilele POST la server i primesc numele din atributele name ale cmpurilor de formular corespunztoare, motiv pentru care s-a adugat, alturi de id (cu rol de identificare n DOM) i atributul name (cu rol de generare a variabilelor POST). Se poate comenta faptul c e prima dat cnd apelm la atributul name. n exemplele anterioare, acestea nu au fost necesare deoarece variabila GET CodPostal fusese construit pe alt cale: onblur="date(this.value)" prelua valoarea cmpului i o transmitea ca argument funciei, care o concatena la adresa scriptului server, odat cu numele variabilei GET "script.php?CodPostal="+argument. Acest mecanism de transmitere a variabilelor GET direct n adresa scriptului server e facil i uzual cnd nu se transmite un numr mare de date. Dac dorim s transmitem ntreg formularul prin GET, singura modificare necesar la ultimul exemplu este nlocuirea lui xhrPost cu xhrGet (care accept la rndul su proprietatea form n argument).
O alt sintax pentru transmiterea datelor (indiferent c folosim GET sau POST), este cea bazat pe proprietatea content:
dojo.xhrGet ({ url: "script.php", handleAs:"text", load: procesare, error: proceroare, content: {v1: "valoare1", v2: dojo.byId("camp").value} })
Aceast funcie va transmite prin metoda GET dou variabile, una creat ad-hoc (v1 cu valoarea "valoare1") i una cu numele v2 i valoarea preluat dintr-un cmp de formular cu id=camp. Scriptul server care va confirma acest lucru are forma:
60
<?php ?>
print "La server au ajuns ".$_GET['v1']. " si ".$_GET['v2'];
Am amintit anterior c uzual serverul returneaz rspunsul n dou forme: text sau XML, difereniate n proprietile responseText i responseXML ale obiectului XHR. Folosind Dojo, tipul rspunsului e fixat prin argumentul handleAs. Mai mult, Dojo accept i alte dou formate puternice drept rspuns: cod JavaScript pentru execuie imediat sau date n format JSON (JavaScript Object Notation). Relund exemplu cu completarea automat a formularului la introducerea codului potal, scriptul server ar putea arta astfel:
<?php if ($_GET["CodPostal"]==400451) print ' document.getElementById("TXoras").value="Cluj Napoca"; document.getElementById("TXjudet").value="Cluj"; document.getElementById("TXadresa").value="Aleea Azuga..." ' else print ' document.getElementById("TXoras").value="cod incorect"; document.getElementById("TXjudet").value="cod incorect"; document.getElementById("TXadresa").value="cod incorect" '
?>
Acum, scriptul PHP nu mai returneaz date n format text, ci cod surs JavaScript. Deoarece codul returnat e un ir de caractere ce conine multiple instruciuni, acestea au fost delimitate prin punct-virgul (caracter care e obligatoriu n JavaScript doar dac mai multe instruciuni apar pe aceeai linie aa cum e cazul irului trimis de server). n aceste condiii, funcia dojo.xhrGet poate fi configurat pentru a recepta datele n format JavaScript i a le executa imediat, cu ajutorul argumentului handleAs:
<head> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function proceroare(raspuns,obiectDojo) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare de conectare la server!</font>"+raspuns } function date(cod) { dojo.xhrGet ({ url: "script.php?CodPostal="+cod, handleAs:"javascript", error: proceroare }) } </script> </head>
Se observ simplificarea major a codului surs comparativ cu varianta iniial i un acces mai direct din codul PHP direct asupra paginii HTML. Este important de remarcat faptul c argumentul funciei xhrGet este de fapt un obiect, ale crui proprieti (url, handleAs, load, error etc.) sunt definite n mod inline, direct n parantezele funciei. Acest lucru este permis de sintaxa JavaScript, dar nu este obligatoriu. Forma n care e iniializat argumentul funciei xhrGet poart de numirea de format JSON.
61
Formatul JSON27 pentru transferul de date este o alternativ tot mai popular i mult simplificat fa de XML. Att XML ct i JSON sunt, la baz, iruri de caractere, difer doar structura intern a acestor iruri. n timp ce XML impune ca datele s fie definite ntr-o structur de marcatori ce respect regulile de bun formare, JSON permite gruparea datelor n manier obiectual (seturi de proprieti ncapsulate pe mai multe nivele) modelul JSON este inspirat chiar de modalitatea de iniializare a variabilelor masive:
A[2][3]=[[1,2,3][4,5,6]]
Pentru definirea de obiecte, iniializarea folosete acolade i perechi nume:valoare separate prin virgul:
obiect={proprietate1:valoare1, proprietate2:valoare2}
...unde fiecare valoare poate fi la rndul su un obiect sau un masiv. De fapt, sintaxe de tip JSON au fost deja folosite n situaiile: descrierea argumentului funciei xhrGet, unde s-au enumerat url, handleAs, load i error toate fiind proprieti iniializate ale obiectului ce servete ca argument pentru xhrGet. Alternativa ar fi fost o descriere precum:
obiect={url:....,handleAs:....,load:....,error:.....} dojo.xhrGet(obiect)
descrierea valorile transmise serverului prin proprietatea content. Alternativa:
obiecttrimis={v1:...., v2:.....} obiectargument={url:....,handleAs:....,load:....,error:...., content: obiecttrimis} dojo.xhrGet(obiectargument)
descrierile de stil CSS sunt foarte asemntoare irurilor JSON:
.stil1 {proprietatecss1: valoare1; proprietatecss2: valoare2;....}
Diferena e caracterul de delimitare punct-virgul. Similar cu irul JSON, descrierea CSS e convertit implicit n obiect JavaScript pentru a avea acces direct la proprietile CSS prin construcii de forma nod.style.proprietatecss;
Not: Revenim cu cteva explicaii asupra unor detalii de sintax Dojo. Am artat c argumentul unor funcii ca xhrGet sunt obiecte ce pot fi descrise prin JSON. Aceasta explic motivul pentru care funciile handler sunt indicate doar prin numele lor, nu i prin argumente: obiect={url:....,handleAs:....,load: procesare ,error:proceroare} n loc de obiect={url:....,handleAs:....,load: procesare() ,error: proceroare() } Explicaia const n faptul c la construirea unui obiect definit prin sintax JSON fiecare proprietate a obiectului devine o variabil care primete o valoare evaluat de interpretorul JavaScript. Dac valoarea uneia din aceste proprieti are forma functie(), aceasta va fi chiar valoarea returnat de funcie, deci funcia va fi apelat i executat chiar la construirea obiectului. Ori, scopul unui handler e s fie executat doar la declanarea evenimentului asociat! n schimb, dac proprietatea primete valoarea functie, aceasta va deveni o variabil de tip function ce va stoca blocul de exe cuie a funcie i nu valoarea sa! Pentru clarificare, reamintim modul n care JavaScript difereniaz o funcie de valoarea sa prin absena sau prezena argumentelor i parantezelor: a=f() b=f
27
http://json.org 62
n urma acestor atribuiri, a va primi valoarea returnat de funcie, iar b devine la rndul su funcie (e o variabil de tip function) i va putea fi apelat cu b(). n concluzie, funciile handler din argumente de tip JSON nu vor putea primi argumente explicite, ci doar pe cele implicite (raspunsul i obiectul Dojo).
n cele ce urmeaz vom realiza o comparaie ntre formatele JSON i XML aplicate asupra datelor trimise de server. Prezentm n continuare acelai set de date n format XML i n format JSON: XML:
<produse> <produs denumire=Televizor pret=100 /> <produs denumire=Calculator pret =200 /> </produse>
Valoare JSON atribuit unei variabile:

produse=[ {denumire:Televizor, pret:100},{denumire:Calculator,pret:200}]
Obiect JSON de transferat (de exemplu generat de un serviciu Web sau de server):
{ produse: [{denumire:Televizor, pret:100},{denumire:Calculator,pret:200}] }
Astfel, produse devine un vector de dou elemente, fiecare element fiind un obiect cu cte dou proprieti. Insistm asupra faptului c valorile masive se enumer ntre paranteze ptrate, iar proprietile obiectelor ntre acolade, fiind posibil orice combinaie de imbricare ntre acestea (ex: vector de obiecte, obiect cu proprieti vectori, obiect cu proprieti obiect, vector cu elemente vector 28 etc.). Dup unii autori, obiectul JSON nu este dect o variabil masiv de tip asociativ (care folosete nume de proprieti n loc de numr de ordine pentru identificarea elementelor sale). Se observ c ambele modele (XML i JSON) transpun n format text serializat (ir de caractere) structuri de date arborescente conversia de la irul serializat la arbore fcndu-se pe baza imbricrilor. Relaia tat-fiu n arbore e implementat astfel: XML prin imbricarea marcatorilor sau prin subordonarea atributelor la un marcator; JSON prin imbricarea parantezelor. Relaia frate-frate e implementat astfel: XML: elemente fiu ale aceluiai printe sau atribute separate prin spaiu ale aceluiai element; JSON: iruri de perechi nume:valoare separate prin virgul sau elemente de vector separate prin virgul; Avantajele JSON sunt: performana, atunci cnd se transfer strict seturi date (n schimb XML devine esenial atunci cnd se transfer poriuni de documente ce vor fi manipulate prin DOM); compatibilitatea cu obiectele JavaScript Dojo ofer chiar o serie de funcii de conversie facil ntre iruri de caractere JSON i obiecte JavaScript; accesul facil la proprietile JSON prin sintaxa JavaScript, comparativ cu accesul mai dificil la XML prin DOM n exemplul JSON, al doilea pre poate fi accesat prin produse[1].pret, n timp ce n exemplul XML ar fi necesar parcurgerea vectorilor getElementsByTagName sau childNodes pentru nodul rdcin, urmate apoi de solicitarea atributului pret cu getAttribute. Din aceste exemple se poate remarca de ce suporterii JSON promoveaz acest model ca fiind "the fat-free XML", adic un format similar cu XML dar redus la strictul necesar pentru reprezentarea structurilor de date. Dei creat pe baza modului n care JavaScript iniializeaz variabile complexe, JSON se dorete a fi un format universal pentru transferul datelor independent de platforma prilor ntre care are loc transferul. Aadar, e vorba de un veritabil concurent pentru XML n acest sens, dei renun la conceptele XML avansate (vocabular, instruciuni de procesare, spaii de nume). Suporterii
28
Practic o matrice nu este altceva dect un vector cu elemente vectori. 63
JSON susin c oricum conceptele XML sunt inutile: spaiile de nume devin inutile dac nu se mai folosesc marcatori iar validarea prin vocabulare e considerat o delegare inutil a responsabilitiilor: Principiul XML este c aplicaiile trebuie s fie restrictive la receptarea datelor (datele fiind validate sau transformate conform regulilor unui vocabular predefinit de destinatar) i permisive la generarea lor (fiecare aplicaie poate genera orice structur de date XML); Principiul JSON este c orice aplicaie trebuie s fie permisiv la receptarea datelor i restrictiv la generarea lor, adic s poat prelucra orice structuri de date primite i s fixeze nite reguli stricte pentru structurile de date generate; Aa cum sunt necesare programe de tip parser pentru a converti un ir de caractere XML ntrun arbore de obiecte DOM, parserele JSON convertesc iruri de caractere JSON n obiecte. Site-ul http://json.org ntreine o list la zi cu site-urile de la care pot fi procurate parsere JSON pentru diverse limbaje de programare. Pentru JavaScript, parsingul se poate face n mod nativ funcia eval() convertete un ir de caractere ntr-o expresie sau un bloc de instruciuni JavaScript, aadar prin aplicarea funciei asupra unui ir JSON stocat n responseText se obine chiar un obiect JavaScript, mult mai facil de accesat dect un arbore DOM. Exist i parsere avansate pentru JavaScript, cu metode complexe de manipulare a structurii JSON, dar acestea trebuie instalate i invocate ca biblioteci de funcii JavaScript (vezi biblioteca http://json.org/json2.js). Conversia unui ir JSON n obiect se realizeaz n JavaScript astfel:
obiect=eval('('+xhr.responseText+')') sau eval('obiect='+xhr.responseText)
Aceasta se realizeaz n mod nativ29. Folosirea funciei eval ridic probleme de securitate datorit faptului c argumentul funciei va fi evaluat i executat chiar dac este un bloc de instruciuni JavaScript n locul unui ir JSON. Atunci cnd sursa datelor din responseText nu e de ncredere (ex: responseText conine informaii tastate de un vizitator ntr-un formular), se recomand folosirea parserelor JSON propriu-zise, disponibile gratuit ca biblioteci de funcii invocate cu SCRIPT SRC. Aceste parsere realizeaz naintea evalurii o verificare a structurii argumentului, astfel nct s se asigure c e o structur JSON i nu un cod surs potenial maliios. Biblioteca json2, propus de David Crockford, promotorul modelului JSON, ofer funciile:
obiect=xhr.responseText.JSON.parse() conversie din ir JSON sir=obiect.JSON.stringify() coversie din obiect n ir JSON
n obiect
Aa cum exist protocoale orientate pe transferul de date XML (SOAP, XML-RPC), exist i protocoale de transport JSON (JSON-RPC). Mai mult, comunitatea JSON a propus nlocuirea obiectului XHR cu un obiect similar, JSONRequest, optimizat pentru transferuri JSON (la adresa http://json.org exist legturi spre instrumente de acest gen, inclusiv o extensie add-on pentru Firefox ce implementeaz obiectul JSONRequest). n contextul nlocuirii XML cu JSON ca format de transfer al datelor structurate, susintorii JSON arat c pn i litera X din acronimul AJAX i pierde semnificaia. Dei exist o tendin de migrare a modelului AJAX spre structuri de date JSON, XML rmne un standard puternic cnd nu e vorba de structuri de date, ci de documente spre exemplu, atunci cnd serverul genereaz marcatori XML ce trebuie integrai n arborele DOM al paginii. Pachetul Dojo include un suport puternic pentru formatul JSON, incluznd protocol JSONRPC i parser (proprietatea handleAs poate lua valoarea "json" n funciile xhrGet i xhrPost, pentru ca rspunsul serverului s nu fie tratat ca simplu text, ci s fie tratat ca i JSON i convertit automat n obiect). Versiunea 5 a limbajului PHP include la rndul su funcii pentru procesare i generare de iruri JSON. Relum exemplul cu completarea automat a formularului pe baza codului potal. De data aceasta, datele sunt mpachetate de server n format JSON, sub forma:
{adresa:....., oras:...., judet:......}
Necesitatea concatenrii parantezelor n prima variant e dat de prezena acoladelor n irul JSON. Funcia eval interpreteaz acoladele ca fiind delimitatori ai unor blocuri de instruciuni i provoac o eroare dac n loc de instruciuni ntlnete valori JSON. ncadrarea n paranteze rotunde anuleaz acest comportament. 64
29
irul JSON sunt convertite automat n obiect de ctre parserul JSON inclus n Dojo. Scriptul server care genereaz irul JSON este:
<?php if ($_GET["CodPostal"]==400451) $date=array("oras"=>"Cluj Napoca","judet"=>"Cluj","adresa"=>"Aleea Azuga...(completati detaliile)"); else $date=array("oras"=>"cod incorect","judet"=>"cod incorect","adresa"=>"cod incorect"); print json_encode($date); ?>
Se observ utilizarea funciei json_encode(), care convertete un vector asociativ (sau un obiect PHP) ntr-un ir de caractere JSON30. Funcia este membr a extensiei JSON disponibil implicit ncepnd cu PHP 5.2.0. Funcia pereche este json_decode(), care convertete un ir de caractere JSON n obiect sau vector.
Not: Mai multe detalii despre extensia JSON pentru PHP sunt disponibile la http://www.php.net/manual/en/book.json.php. Informaii despre extensii JSON pentru alte limbaje (i despre extensii JSON PHP alternative celei instalate implicit) sunt disponibil e la site-ul oficial JSON: http://json.org
Pagina AJAX va fi modificat pentru a accesa proprietile obiectului JSON primit de la server (nu mai reproducem corpul paginii):
<head> <title>Formular</title> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { // se elimina linia - var vect=raspuns.split(',') deoarece raspunsul nu mai e de tip text // ci de tip obiect document.getElementById("TXoras").value=raspuns.oras document.getElementById("TXjudet").value=raspuns.judet document.getElementById("TXadresa").value=raspuns.adresa document.getElementById("Eroare").innerHTML="" } function proceroare(raspuns,obiectDojo) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+raspuns+"</font>" } function date(cod) { dojo.xhrGet({ url: "script.php?CodPostal="+cod, handleAs:"json", load: procesare, error: proceroare }) } </script> </head>
Urmtorul exemplu primete aceleai date n format XML, sub forma:

<detalii adresa=......>
Utilizarea funciei nu e obligatorie n exemplul de fa. irul JSON e un ir de caractere simplu, deci putea fi returnat de server direct sub form de string cu structura cerut de JSON. Am dorit totui s exemplificm funciile PHP care convertesc date din i n iruri JSON. 65
30
<oras>...</oras> <judet>....</judet> </datepersonale> Not: Flexibilitatea XML permite ca datele s fie stocate n orice combinaie de atribute, coninut textual i elemente imbricate. Din raiuni de performan, se prefer ca, de cte ori e posibil, datele s fie stocate n atribute ale unui element vid (fr nchidere), caz n care datele exemplului vor avea forma <detalii adresa=.... oras=..... judet=.... / >. n situaia dat am preferat o form mai complicat pentru a exemplifica att accesul la atribute ct i accesul la elemente imbricate i coninutul lor textual.
Datele pot fi returnate din PHP ca un ir de caractere cu structura indicat, sau mpachetate n obiect XML printr-un script ce exploateaz aceleai funcii DOM ca i cele folosite la nivelul clientului (modelul DOM e suportat de majoritatea limbajelor de programare moderne, inclusiv PHP, prin clasa DOMDocument):
<?php header("Content-Type","text/xml") if ($_GET["CodPostal"]==400451) { $oras="Cluj Napoca"; $judet="Cluj"; $adresa="Aleea Azuga...completati detaliile"; } else { $oras="cod incorect"; $judet="cod incorect"; $adresa="cod incorect"; } $xml=new DOMDocument(); $radacina=$xml->createElement("detalii"); $fiu=$xml->createElement("oras"); $fiu=$radacina->appendChild($fiu); $continut=$xml->createTextNode($oras); $continut=$fiu->appendChild($continut); $fiu=$xml->createElement("judet"); $fiu=$radacina->appendChild($fiu); $continut=$xml->createTextNode($judet); $continut=$fiu->appendchild($continut); $atribut=$radacina->setAttribute("adresa",$adresa); $radacina=$xml->appendChild($radacina); print $xml->saveXML(); ?>
La nivelul serverului se remarc: obligativitatea de a declara rspunsul serverului ca fiind de tip xml, altfel obiectul XHR nu va aplica parsing XML i modelul DOM nu se va obine la client 31; folosirea clasei DOMDocument pentru a instania o structur de date XML; faptul c metodele appendChild, createElement, createTextNode, setAttribute returneaz nodul/atributul pe care l-au creat, pentru referire ulterioar; penultima linie adaug nodul rdcin ca fiu al obiectului $xml; aceasta sugereaz c rdcina arborelui i documentul XML nu sunt echivalente: documentul mai conine, alturi de rdcin, cel puin instruciunea-antet <?xml...?>, care se adaug automat (mai poate conine i apeluri de vocabular);
Aspectele discutate aici rmn valabile i atunci cnd datele XML se obin direct prin xhr.responseXML, nu doar la transferurile gestionate de funciile Dojo. 66
31
n final, obiectul XML e convertit n ir de caractere cu metoda saveXML(), pentru a putea fi returnat cu print.
n cazul receptrii datelor n format XML reamintim faptul c obiectul XML primit de la server e mai restrictiv dect modelul XML al paginii. Nu toate funciile DOM folosite la manipularea paginii pot fi folosite la manipularea arborelui DOM al obiectului XML. Nu sunt posibile, printre altele: - getElementById (se va folosi getElementsByTagName sau navigare de arbore cu childNodes, firstChild, lastChild etc.); - calificarea atributelor n forma nod.id (se va folosi nod.getAttribute(), setAttribute()); - innerHTML sau outerHTML (se va folosi nodeValue i funciile de manipulare la nivel de nod fiu replaceChild, appendChild etc. ). n consecin, modulul client exemplificat mai jos nu se bazeaz pe localizarea datelor prin atributele id (nu s-a mai trecut corpul paginii, nemodificat fa de exemplele anterioare):
<head> <title>Formular</title> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { oras=raspuns.getElementsByTagName("oras") document.getElementById("TXoras").value=oras[0].firstChild.nodeValue judet=raspuns.getElementsByTagName("judet") document.getElementById("TXjudet").value=judet[0].firstChild.nodeValue radacina=raspuns.documentElement document.getElementById("TXadresa").value=radacina.getAttribute("adresa") } function proceroare(raspuns,obiectDojo) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+raspuns+"</font>" console.error("HTTP status code: ",obiectDojo.xhr.status) // linia de mai sus nu e obligatorie: transmite codul de eroare al serverului spre // consola Firebug n Mozilla Firefox } function date(cod) { date={CodPostal:cod} obiect={ url: "script.php", handleAs: "xml", load: procesare, error: proceroare, content: date } dojo.xhrGet(obiect) } </script> </head>
n exemplul de fa se remarc: receptarea datelor de la server ca arbore DOM prin handleAs:"xml"; folosirea getElementsByTagName care, spre deosebire de getElementById, returneaz un vector motiv pentru care se folosesc oras[0] i judet[0] (cei doi vectori au cte un singur element); se observ c getElementById s-a folosit doar pe arborele paginii iar getElementsByTagName i firstChild pe arborele XML generic;
67
folosirea proprietii firstChild pentru a accesa coninutul textual al marcatorilor XML, deoarece acetia sunt considerai noduri fiu; n cazul arborelui XML construit n PHP nu exist pericolul nodurilor cu "caractere albe" despre care am discutat la convertirea paginii HTML n arbore DOM, aadar childNodes i proprietile aferente nu dau rezultate imprevizibile; "caracterele albe" apar doar atunci cnd codul XML e tastat (de exemplu, dac pachetul XML n loc s fie construit n PHP ar fi fost receptat direct dintr-un fiier de tip xml cu cod surs indentat prin tastare de Tab-uri i Enter-uri); folosirea proprietii documentElement care conine rdcina arborelui DOM recepionat, n scopul extragerii atributului su; folosirea metodei getAttribute n condiiile n care forma raspuns.adresa nu e utilizabil pe cod XML generic; folosirea proprietii nodeValue n condiiile n care innerHTML nu e utilizabil pe cod XML generic.
Not: Pentru mai multe detalii legate de manipularea DOM n PHP, consultai adresa http://www.php. net/manual/en/refs.xml.php. Pachetul DOM Extension conine clasa DOMDocument utilizat n acest exemplu i e specific versiunilor PHP mai noi de 5. Pentru versiunile PHP mai vechi d e c t 5 , s e u t i l i z e a z p a c h e t u l D O M X M L 32. P a c h e t u l S i m p l e X M L e s t e o alternativ la DOM mult simplificat. Mai exact, SimpleXML ncearc s apropie metodele de acces la date de formatul JSON. De exemplu, coninutul textual al unui marcator e accesibil direct prin calificarea printelui (nodparinte->nodfiu), n loc s foloseasc met odele DOM (nodparinte->firstChild->nodeValue). Dei simplific mult codul surs, SimpleXML are performane mai reduse dect DOM i e folosit frecvent pe pachete de date de dimensiuni reduse (arbori cu numr redus de nivele). Recomandm familiarizarea cu DO M mai degrab dect cu SimpleXML datorit valabilitii universale a funciilor i proprietilor DOM.
Aceste exemple evideniaz caracterul mult mai facil al generrii i accesrii de date JSON comparativ cu XML, fr s se piard structura datelor. n ambele situaii, proprietatea responseText rmne accesibil i conine forma brut, de dinaintea operaiei de parsing, a irului de caractere primit de la server. Am sugerat anterior c pachetul Dojo elimin o parte neajunsurile AJAX. Pentru uploadul de fiiere prin formulare, Dojo ofer funcia dojo.io.iframe, ce mascheaz o funcionalitate bazat pe cadre interne invizibile ce conin fiierul de uploadat (deoarece JavaScript i XHR nu permit acces direct la discul clientului). Exemplu: ntr-o aplicaie Web tradiional, fiecare stare a aplicaiei e reprezentat de o pagin cu adres unic ce poate fi stocat ca semn de carte pentru revenire ulterioar. Trecerea de la o stare la alta are loc prin ncrcarea unei pagini noi. n AJAX, browserul primete o singur pagin pe care o modific dinamic pe baza datelor transferate de la server prin XHR. Aceasta nseamn c adresa aplicaiei AJAX rmne neschimbat pe toata durata utilizrii sale, iar un semn de carte tradiional, creat prin stocarea adresei URL curente nu va putea face diferena ntre diferite stri ale aplicaiei. Trecerea de la o stare la alta are loc la fiecare transfer XHR. Pentru a permite crearea de semne de carte, Dojo apeleaz la soluia: la fiecare transfer XHR se genereaz o marc unic (ir de caractere generat de programator sau n mod automat ca marc de timp). Marca e concatenat n momentul transferului la adresa aplicaiei. Fiecare astfel de marc devine reprezentativ pentru o stare a aplicaiei. Atunci cnd utilizatorul creeaz un semn de carte, n acesta se stocheaz adresa aplicaiei (care e unic) concatenat cu marca strii curente. Considerm funcia de transfer:
dojo.xhrGet({ url: "script.php", load: error: changeURL: "starea1"
32
Articolul http://www.ibm.com/developerworks/xml/library/x-xmlphp3.html?ca=dgrlnxw09PHP5-XSLT ofer o viziune de ansamblu asupra bibliotecilor PHP pentru procesare XML, inclusiv o comparaie util ntre DOM i SimpleXML 68
})
La executarea acestui transfer, adresa URL a aplicaiei AJAX se va modifica n browser la forma http://localhost/aplicatiamea.html#starea1. Aceast adres va putea fi stocat n Favorites sau Bookmarks, ca semn de carte ce va aduce aplicaia la starea imediat urmtoare transferului respectiv. Dac se dorete generarea automat a mrcii de stare, changeURL se seteaz la valoarea true. Legat de folosirea butoanelor Back/Forward, acestea se bazeaz pe istoricul paginilor vizitate de browser (i implicit pe adresele acestora). Ori, dup am artat anterior, aplicaia AJAX e o pagin unic, deci cele dou butoane vor prsi complet aplicaia n loc s navigheze ntre strile sale. n acest context devine avantajoas exploatarea cadrelor interne n locul obiectului XHR, deoarece fiecare modificare a coninutului unui cadru definete o stare nou n istoricul browserului. Numeroase pachete de funcii AJAX ofer mecanisme de simulare a istoricului de pagini pe durata utilizrii aplicaiei, folosind principiul anterior explicat, de definire a strilor aplicaiei prin concatenare de mrci unice la adresa paginii. Pachetul Dojo permite programarea comportamentului butoanelor Back i Forward de pe browser, prin funcii handler 33: backButton: function() {..........} forwardButton: function() {...........}
Not: Ca i n cazul upload -ului de fiiere, i n acest caz implementarea pe care o mascheaz Dojo e complicat i bazat pe un cadru intern invizibil. Cadrul invizibil sufer la creare dou operaii forward i o operaie back pentru a se afla, din punct d e vedere al istoricului, ntre un forward i un back (astfel nct nici una din cele dou operaii s nu provoace prsirea aplicaiei). Apoi, cele dou funcii Dojo sunt legate de evenimentul onload asociat operaiilor back i forward pe cadrul invizibil.
Un avantaj major al pachetului Dojo, care poate fi intuit din acest capitol, este c ncapsuleaz mecanismul complet de detectare a browserului pentru instanierea corect. Mai mult, dac obiectul XHR nu este disponibil sub nici o form, Dojo ncapsuleaz i comunicarea cu serverul prin cadre interne invizibile, fr nici un efort suplimentar din partea programatorului AJAX. Acest mecanism de implementare a mai multor variante de cod pentru a prentmpina limitrile de platform care pot s apar duce la aa-numitul cod surs degradabil. Codul degradabil este un cod surs ce conine ramuri de execuie alternative pentru fiecare funcionalitate care ar putea s lipseasc din browserul vizitatorilor, ceea ce asigur o robustee i o fiabilitate mrit fa de resursele utilizatorului. Structura try-catch de verificare a existenei claselor necesare instanierii XHR este un exemplu de astfel de cod degradabil. Adugarea unui suport suplimentar ce apeleaz la cadre interne invizibile atunci cnd XHR lipsete aduce un plus de degradabilitate i, implicit, de robustee iar pachetul Dojo este foarte bine construit n acest sens. n plus, am sugerat i faptul c n unele situaii cadrele invizibile devin obligatorii i anume n implementarea upload-ului de fiiere sau a gestiunii butoanelor Back/Forward ntre strile aplicaiei AJAX.
2.3.3. Comunicarea cu serverul prin biblioteca Prototype

Prototype este una din soluiile concurente pentru Dojo, axat pe extinderea obiectelor JavaScript urmnd un model inspirat de limbajul Ruby. Biblioteca poate fi descrcat gratuit i se instaleaz similar cu Dojo. ncepnd de la versiunea 1.5.1 ofer suport pentru date n format JSON. Presupunem c am creat n rdcina serverului Web folderul protoroot, n care copiem biblioteca care e un fiier unic cu un nume de forma prototype nrversiune.js. La nceputul paginii AJAX se apeleaz biblioteca, similar cu cazul Dojo:
<head> <script type="text/javascript" src="protoroot/prototype-1.6.0.2.js">
33
69
</script> <script type="text/javascript"> function procesare(obiectxhr) { var vect=obiectxhr.responseText.split(',') document.getElementById("TXoras").value=vect[0] document.getElementById("TXjudet").value=vect[1] document.getElementById("TXadresa").value=vect[2] documen.getElementById("Eroare").innerHTML="" } function proceroare(obiectxhr) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+obiectxhr.responseText+"</font>" } function date(cod) { new Ajax.Request("script.php",
} </script> </head>
{ asynchronous: true, method: "get", parameters: "CodPostal="+cod, onSuccess: procesare, onFailure: proceroare })
Not: Atenie la numrul de versiune al bibliotecii Prototype, care apare chiar n numele fiierului i care se modific uneori cu frecven lunar. Dup ce downloadai biblioteca, verificai numele fiierului i folosii-l ntocmai n apelul de includere a bibliotecii.
O diferen important fa de Dojo este c funciile handler pentru onSuccess (echivalentul proprietii load n Dojo) i onFailure (echivalentul proprietii error n Dojo) primesc un singur argument, i acela este chiar obiectul XHR, nu rspunsul, cum e cazul Dojo. Mai departe, se remarc faptul c parameters este echivalentul proprietii content. Aici valoarea parameters e construit ca ir de caractere, dar e acceptat i sintaxa JSON. Mai iese n eviden faptul c adresa scriptului server e un argument separat (nu face parte din obiectul-argument cu restul proprietilor, aa cum era cazul n Dojo). Ajax.Request poate primi numeroase argumente, dintre care cele mai importante sunt adresa scriptului i obiectul (aici n descriere JSON) cu descrierea cererii.
Not: Avnd n vedere c i funciile Prototype au ca argumente obiecte definite prin JSON, rmne valabil regula discutat la prez entarea Dojo: funciile handler sunt indicate doar prin nume, nu i prin paranteze, deci nu pot primi argumente explicite. Aadar, o construcie precum onSuccess: functiehandler(argument1,argument2) va funciona eronat: va executa funcia la construirea argumentului Ajax.Request i nu la declanarea evenimentului pentru care s -a creat handlerul! Handlerele Prototype au obligatoriu ca argument implicit obiectul XHR, ca n exemplul: new Ajax.Request(....{... onSuccess: functiehandler}) ..... function functiehandler(obiectxhr) { //blocul de execuie a handlerului } n consecin, singura cale de a transmite argumente handlerelor este intermedierea printr-un handler anonim (o valoarea de tip function): onSuccess: function (obiectxhr) {functiehandler(argument 1,argument2)}
70
Din interiorul funciei handler vor putea fi accesate att argumentele explicite ct i obiectul XHR.
Dac se dorete receptarea de cod JavaScript de la server, se poate apela la funcia care convertete iruri de caractere n construcii JavaScript: eval (util i la obinerea obiectelor JSON n mod nativ):
function procesare(obiectxhr) { eval(obiectxhr.responseText) } function proceroare(obiectxhr) { ...... } function date(cod) { new Ajax.Request("script.php", { asynchronous: true, method: "get", parameters: "CodPostal="+cod, onSuccess: procesare, onFailure: proceroare })
Evident, n acest caz scriptul server va returna un ir de caractere interpretabil ca i cod JavaScript, dup cum s-a exemplificat n cazul Dojo. Platforma care exploateaz biblioteca Prototype, numit Ruby on Rails, promoveaz un model aparte de aplicaii AJAX: generarea de cod HTML la nivelul serverului, care apoi este inclus n structura paginii prin proprietatea innerHML. Prototype este optimizat pentru aceast procedur:
<html> <head> <script type="text/javascript" src="protoroot/prototype-1.6.0.2.js"> </script> <script type="text/javascript"> function proceroare(obiectxhr) { document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+obiectxhr.responseText+"</font>" } function date(cod) { new Ajax.Updater("t1","script.php", { asynchronous: true, method: "get", parameters: "CodPostal="+cod, onFailure: proceroare }) } </script> </head> <body> <h1>Introduceti datele</h1> <form> <table id=t1> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td>
71
</tr> <tr> </tr> <tr> </tr> <tr> </tr> <tr>
<td><input type=text id=TXcodpostal onblur="date(this.value)"></td> <td>Adresa</td> <td><input type=text id=TXadresa size=50></td> <td>Oras</td> <td><input type=text id=TXoras ></td> <td>Judet</td> <td><input type=text id=TXjudet ></td> <td></td> <td><input type=submit value=Trimite ></td>
</tr> </table> </form> <p id=Eroare></p> </body> </html>
Se observ c, n cazul folosirii obiectului Ajax.Updater, nu mai e necesar precizarea handlerului onSuccess. Obiectul Ajax.Updater permite totui utilizarea handlerului onSuccess i a altor handlere ce corespund strilor transferului de date (vezi valorile xhr.readyState). Poate fi nevoie de un handler onSuccess pentru Ajax.Updater atunci cnd primirea rspunsului de la server are i alte consecine dect inserarea sa direct n pagin. n plus, Ajax.Updater e capabil s realizeze i inserare, nu doar nlocuire, dac se adaug proprietatea insertion, cu valorile posibile: top: imediat dup eticheta de deschidere a marcatorului indicat de primul argument; bottom: imediat nainte de eticheta de nchidere a marcatorului; before: imediat naintea etichetei de deschidere a marcatorului; after: imediat dup eticheta de nchidere a marcatorului.
Ajax.Updater(element, url, {........., insertion:top})
Revenind la exemplu, acesta se bazeaz pe faptul c serverul ofer cod HTML care poate fi introdus prin innerHTML n locul coninutului marcatorului al crui atribut id e precizat n primul argument Ajax.Updater. n consecin scriptul server ar trebui s genereze codul HTML de nlocuire:
<?php if ($_GET["CodPostal"]==400451) { $oras='Cluj Napoca'; $judet='Cluj'; $adresa='Aleea Azuga....completati detaliile'; } else { $oras='cod incorect'; $judet='cod incorect'; $adresa='cod incorect'; } $cod=$_GET["CodPostal"]; print " <tr> </tr> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> <td>CodPostal</td> <td><input
</tr> <tr>
type=text id=TXcodpostal onblur='date(this.value)'></td>
value='$cod'
72
</tr> <tr> </tr> <tr> </tr> <tr> </tr>"; ?>
<td>Adresa</td> <td><input type=text id=TXadresa size=50 value='$adresa'></td> <td>Oras</td> <td><input type=text id=TXoras value='$oras'></td> <td>Judet</td> <td><input type=text id=TXjudet value='$judet'></td> <td></td> <td><input type=submit value=Trimite ></td>
n scriptul PHP se observ integrarea variabilelor direct n irul de caractere, fr concatenare. Sintaxa PHP 5.0 permite acest lucru, variabilele fiind detectate i substituite cu valorile lor datorit prefixului $. Poriunile de cod HTML de acest gen, create de server pentru integrare imediat n codul paginii la client, poart denumirea de snippets. Desigur, exemplul nu este unul eficient. Ceea ce i se poate reproa este tocmai refreshul redundant pe care modelul AJAX ar trebui s l elimine. O parte din codul HTML (trei dintre rndurile tabelului) e rencrcat de la server, dei nu conine nici o modificare. n alte situaii ns, generarea de snippet HTML non-redundant de la server, care s se poat cupla la restul paginii cu minim de efort, este un instrument deosebit de puternic. Pentru a realiza acest lucru, intuiia ar dicta ca cele trei celule care se recreeaz la server s fie delimitate ntr-un bloc div sau span care apoi s fie rescris cu Ajax.Updater:
<form> <table>
........ </table> </form>
<tr>....</tr> <div id=blocinlocuit> <tr>.....</tr> <tr>.......</tr> </div>
Din pcate aceasta nu e o soluie. Blocurile div i span pot teoretic s delimiteze orice poriune de document, atta timp ct nu ncalc regulile de imbricare ale vocabularului XHTML. Aceste reguli impun o structur rigid a marcatorului table acesta poate conine doar marcatori tr, thead, tbody sau tfoot. Orice text inserat ntre marcatorii table i tr (sau ntre tr i td) este fie ignorat de unele browsere, fie mutat forat naintea tabelului. Aadar, n cazul de fa, la convertirea paginii n arbore DOM, browserele vor muta blocul div n faa tabelului iar substituirea sa cu un snippet va da rezultate nedorite. Soluiile reale sunt: formularul s fie aliniat pe alte ci dect prin includerea sa ntr-un tabel; cmpurile de nlocuit s fie grupate ntr-un tabel separat, ce va putea fi manipulat ca un ntreg:
<form> <table>
<tr>....</tr> <tr> <td><table id=blocinlocuit>.......</table></td> </tr> ........ </table> </form>
Tratarea rspunsului ca ir JSON sau XML este, n Prototype, intuitiv, datorit faptului c funciile handler au ca argument chiar obiectul XHR, cu proprietile responseText i responseXML. Obinerea unui obiect JavaScript dintr-un rspuns JSON e posibil cu ajutorul unei funcii de conversie a rspunsului de tip text: 73
obiect=obiectxhr.responseText.evalJSON(true)
Aceast atribuire va apare n funcia handler pentru OnSuccess. Argumentul true are rolul de a activa protecia fa de codul maliios. Spre deosebire de funcia nativ eval(), argumentul true face ca funcia Prototype s testeze dac irul de caractere are o structur JSON sau este un bloc de instruciuni JavaScript, urmnd ca n al doilea caz s mpiedice, printr-o eroare de sintax, operaia de conversie. Conversia invers, din obiect n ir JSON, se poate realiza cu:
sir=obiect.toJSON()
Obinerea unui arbore XML nu necesit efort explicit, acesta fiind preluat direct din proprietatea responseXML.
2.4. Interfaa cu utilizatorul

Dac ne referim strict la partea de interfa cu utilizatorul din AJAX, aceasta exista n anii 90 sub denumirea Dynamic HTML, care semnifica tocmai mecanismul de manipularea a unei interfee HTML prin JavaScript i CSS. Din nefericire, la momentul la care Dynamic HTML s-a lansat, a fost respins de comunitatea Web datorit lipsei de maturitate CSS nu devenise nc un limbaj n sine, ci doar o sintax de formatare complementar limbajului HTML, modelul DOM era nc primitiv iar diferenele de implementare ntre browsere erau descurajante. La ora actual exist nc diferene de implementare ntre browsere, care afecteaz AJAX, dar sunt mult mai ameliorate dect n anii 90. Oricum, ceea ce aduce propriu-zis AJAX n plus fa de Dynamic HTML este faptul c manipularea interfeei cu utilizatorul e dictat de datele obinute asincron de la server prin XHR sau cadre interne. Interfaa cu utilizatorul n AJAX aduce un plus de utilizabilitate aplicaiilor Web. Utilizabilitatea reprezint uurina de utilizare a unei aplicaii software, msurat printr-o serie de proprieti: curba de nvare a utilizrii, caracterul intuitiv, prentmpinarea nevoilor utilizatorilor, fiabilitatea i consistena interfeei, calitatea i promptitudinea dialogului cu utilizatorul. n aplicaiile desktop, utilizabilitatea a evoluat de la nceputul anilor 90 pn n prezent, pe msur ce s-a trecut de la sistemele de operare i aplicaiile cu linie de comand la cele cu meniuri i apoi la cele vizuale, bazate pe componente GUI reutilizabile i standardizate. n prezent, o aplicaie desktop poate obine un grad nalt de utilizabilitate prin programarea evenimentelor (click, mouseover, drag-and-drop etc.) care au deschis noi orizonturi comparativ cu aplicaiile n care interaciunea se baza strict pe introducere de date/comenzi sau selecia din meniuri. n schimb, aplicaiile Web au fost limitate n acest sens de gama redus de evenimente programabile i de latena reelei, adic de faptul c declanarea evenimentului i datele necesare se aflau pe calculatoare diferite. Apariia scripturilor client JavaScript i a modelului Dynamic HTML au permis tratarea anumitor evenimente exclusiv la nivelul clientului, evitnd latena de reea (vezi validarea formularelor), reducnd dialogul client-server i asigurnd astfel o experien de utilizare mai fluid, deci o utilizabilitate mrit. Mai departe, modelul AJAX, prin comunicarea asincron asigur faptul c modulul client funcioneaz nentrerupt i n timpul schimbului de date cu serverul, ceea ce tinde s aduc utilizabilitatea Web chiar mai aproape de utilizabilitatea desktop. Sub aspectul metodelor de programare, Dynamic HTML folosea o interfa de programare DOM primitiv, axat obligatoriu pe parcurgerea arborelui de-a lungul ramurilor sale, din nod n nod (firstChild, nextSibling, parentNode etc.). Mai mult, s-a atras deja atenia c diverse browsere pot obine arbori DOM diferii din acelai cod HTML, ceea ce face parcurgerea arborelui problematic. Standardul DOM actual, suportat de modelul AJAX, permite astfel de parcurgeri ale arborelui dar ofer i ci de acces mai facile la noduri, pe baz de atribut id (getElementById) sau prin vectorul getElementsByTagName. n plus, atributele marcatorilor HTML sunt mapai n proprieti ale obiectelor-element, dup cum s-a vzut deja n exemplele acestui material. Pachete de funcii precum Dojo, Prototype sau Script.aculo.us ofer metode de nivel chiar mai nalt pentru accesul la componentele arborelui DOM. Aceste pachete au avut un rol esenial n adoptarea rapid a modelului AJAX pe principiul reutilizabilitii astfel c n prezent majoritatea aplicaiilor AJAX nu sunt direct programate n JavaScript, ci sunt programate prin funciile pachetelor amintite, ce pot fi considerate blocuri reutilizabile de cod surs. 74
2.4.1. Manipularea interfeei cu utilizatorul prin biblioteca Prototype

Un numr mare de pachete de funcii JavaScript pentru AJAX sunt construite pe funciile pachetului Prototype. S-a artat anterior c pachetul este uor de instalat (e vorba de un singur fiier de tip .js ce conine definiiile tuturor funciilor, iar numele fiierului conine numrul de versiune al bibliotecii). Detaliem cteva din facilitile Prototype: prescurtarea sintaxei JavaScript; metode noi de localizare a nodurilor DOM (pe baz de stiluri); extinderea claselor JavaScript; funcii noi pentru lucrul cu colecii de date (masive, obiecte); ascunderea i eliminarea facil de noduri DOM prin clasa Element; inserare facil de cod HTML n orice poziie a paginii prin clasa Insertion; activarea, dezactivarea i focalizarea facil a cmpurilor formularelor prin clasele Form i Field; determinarea poziiei elementelor n pagin. Prescurtarea sintaxei JavaScript. n loc de:
nod=document.getElementById("identificator") atribut=document.getElementById("identificator").value
...se poate folosi sintaxa mult mai comod:

nod=$("identificator") atribut=$F("identificator")
Funcia $ poate primi chiar mai multe argumente, returnnd un vector:

vector=$("id1","id2","id3") Not: Prescurtarea $F() e value (marcatorii input). valabil doar pentru nodurile ce au atribut
Localizarea n arborele DOM: Prototype ofer o metod suplimentar de localizare a elementelor din document: getElementsByClassName() identific elementele prin numele stilului CSS din atributul class! Metoda e mai degrab asemntoare cu getElementsByTagName() prin aceea c returneaz un vector de elemente, datorit posibilitii ca mai multe poriuni de document s foloseasc acelai stil CSS. Metoda e folosit mai degrab n versiunea prescurtat sintactic:
noduri=$$("numestil")
Prescurtarea indicat are un caracter mai general dect getElementsByClassName, prin aceea c poate nlocui i getElementsByTagName:
noduridiv=$$("div")
Extinderea claselor JavaScript: Prototype adaug la clasa String proprietatea escapeHTML, similar cu innerHTML, cu diferena c browserul nu va mai interpreta marcatorii din irul de caractere, ci i va afia (de exemplu, atunci cnd e necesar afiare de cod HTML n textul documentului):
nod.innerHTML="<b>aaa</b>" afieaz n coninutul nodului aaa nod.escapeHTML="<b>aaa</b>" afieaz n coninutul nodului <b>aaa</b>
Anularea efectului escapeHTML se poate obine cu funcia invers, unescapeHTML.
75
O alt funcie este stripTags(), care elimin marcatorii din argumentul su de tip string, operaie util atunci cnd dorim s lucrm cu coninut textual ignornd formatul. Extinderea sintaxei n lucrul cu colecii de date: Urmnd modelul limbajului Ruby, Prototype adaug un pachet de funcii numit Enumerables, pentru prelucrarea coleciilor (masive, obiecte, mulimi etc.), construite n jurul funciei each(), care aplic iterativ o funcie fiecrui element din colecie. Acest fapt este posibil cu ajutorul variabilelor de tip funcie specifice limbajului JavaScript. Exemplul de mai jos calculeaz suma elementelor unui vector n mod clasic:
suma=0 for (i=0;i<numere.length();i++) { suma=suma+numere[i] } alert(suma)
Funcia each() permite ca iteraia s aib loc n felul urmtor, evitnd explicitarea ciclului for:
suma=0 function aduna(numar) { suma=suma+numar } numere.each(aduna) alert(suma)
Se observ c argumentul lui each() este o variabil de tip function, care apeleaz funcia aduna() pentru fiecare element al vectorului. Aadar, elementele vectorului care calific each() sunt transferate funciei din argumentul acesteia. Alte funcii similare cu each() definesc operaii care s se execute iterativ asupra elementelor unei colecii de date: inject() similar cu each(), dar n plus asigur o iniializare i returneaz o valoare unic acumulat n urma apelului repetat al funciei-argument; exemplul anterior, cu calculul sumei, va fi simplificat prin injectarea variabilei iniializate:
function aduna(suma, numar) { return suma+numar } alert(numere.inject(0,aduna))
grep() argumentele sale vor fi o expresie regulat i o funcie ce va fi apelat pentru fiecare element din colecie care respect condiia dat de expresia regulat; aadar, e similar cu each() dar folosete n plus i un criteriu de filtrare 34; all() argumentul va fi o funcie ce testeaz o condiie i returneaz valori booleene; all() returneaz true dac funcia-argument returneaz true pentru toate elementele coleciei; dac funcia-argument lipsete, se testeaz dac valorile au valoarea true;
numere=[-1,2,3] function pozitive(numar) { return numar>=0 } alert(numere.all(pozitive))
Expresiile regulate sunt mti de cutare aplicate asupra irurilor de caractere pentru a face testarea acestora mai concis dect prin folosirea funciilor de prelucrare a irurilor de caractere. Pentru sintaxa expresiilor regulate recomandm tutorialul aflat la adresa http://www.regularexpressions.info/repeat.html. 76
34
any() argument similar, dar returneaz true dac exist mcar un element n colecie care respect condiia; detect() argument similar; dar returneaz primul element pentru care funcia-argument returneaz true; findAll () argument similar, dar returneaz sub form de vector toate elementele pentru care funcia-argument returneaz true; reject() argument similar, dar returneaz sub form de vector toate elementele pentru care funcia-argument returneaz false; partition() argument similar, dar returneaz o matrice care are pe primul rnd elementele coleciei pentru care funcia-argument returneaz true, iar pe al doilea rnd cele pentru care funcia-argument returneaz false:
numere=[-2,-1,2,3] function pozitive(numar) { return numar>=0 } matrice=numere.partition(pozitive)
include() similar cu any(), dar argumentul su nu e o funcie, ci o valoare care va fi cutat n colecie (comparaia e strict: case sensitiv i senzitiv la tipul valorii); collect() argumentul va fi o funcie ce returneaz o valoare; valorile returnate pentru fiecare element al masivului vor fi colectate ntr-un nou masiv; exemplul de mai jos colecteaz n vectornou dublul valorilor vectorului numere:
numere=[-1,2,3] function dublare(numar) { return 2*numar } vectornou=numere.collect(dublare)
invoke() argumentul va fi un nume de metod (n format string) ce se va aplica asupra elementelor coleciei; exemplul de mai jos ascunde toate elementele din pagin stocate n vectorul a (vectorul b va stoca aceleai elemente deoarece invoke, ca i collect, returneaz un masiv):
a=$("id1","id2","id3") b=a.invoke("hide")
pluck() argumentul va fi un nume de proprietate (n format string) a crei valoare va fi citit pentru toate elementele coleciei, valorile obinute fiind stocate ntr-un masiv, ca n cazul collect; exemplul de mai jos creeaz vectorul a, cu toate elementele ce au folosit stilul stil1, iar vectorul b va primi toate valorile id ale acestora:
a=document.getElementsByClassName("stil1") b=a.pluck("id")
max() argumentul va fi o funcie ce returneaz o valoare; max() va returna valoarea maxim dintre toate valorile returnate de funcia-argument n timpul parcurgerii coleciei; min() similar, pentru mini; sortBy() argumentul va fi o funcie aplicat fiecrui element din colecie; sortBy() returneaz un vector cu elementele coleciei sortate dup valoarea funciei-argument; exemplul de mai jos, returneaz un vector de iruri de caractere sortat dup lungimea irurilor:
stringuri=["abc","a","ab"] function lungime(sir) { return sir.length } vectorsortat=stringuri.sortBy(lungime)
toArray() nu primete argument, convertete orice tip de colecie n masiv: 77
obiect.toArray()
Faciliti Prototype privind interfaa utilizatorului Definirea clasei Element. Prototype definete aceast clas n mod static, deci nu trebuie instaniat, proprietile sale fiind direct accesibile oricrui obiect-element. Clasa Element ncapsuleaz numeroase mecanisme frecvente n manipularea paginii AJAX. Spre exemplu, ofer o funcie pentru controlul vizibilitii unui set de noduri DOM:
<div id=div1>....</div> <div id=div2 style="display:none">......</div> <input type=button value="Control Vizibilitate" onclick="Element.toggle('div1');Element.toggle('div2')>
Funcia Element.toggle() comut vizibilitatea nodului din argument. Similar, clasa Element ofer funciile show() i hide() pentru afiare i ascundere de noduri.
Not: Avertizm asupra faptului c nodurile ascunse pot s influeneze totui comportamentul paginii. Spre exemplu dac se ascund cmpuri ale unui formular, acestea vor trimite totui date serverului la folosirea butonului submit. De asemenea, JavaScript va continua s aib acces la nodurile ascunse.
Un alt mecanism frecvent este eliminarea de noduri DOM, realizat de regul prin resetarea proprietii innerHTML sau cu metoda removeChild(), acestea fiind precedate de necesitatea de a localiza nodul dorit. Clasa Element ofer Element.remove() care preia ca argument atributul id al nodului de ters. Definirea clasei Insertion. Rolul clasei este de a oferi metode de inserare n grupuri de elemente consecutive. Poziiile de inserare sunt sugerate de numele funciilor: Top nceputul grupului; Bottom sfritul grupului; Before nainte de marcatorul ce ncapsuleaz grupul; After dup marcatorul ce ncapsuleaz grupul. Exemplu:
<ul id=lista> <li>111</li> <li>222</li> <li>333</li> </ul> <input type=text id=valoare> <input type=button value=AdaugaInceput onclick="new Insertion.Top('lista','<li>'+$F('valoare')+'</li>')"> <input type=button value=AdaugaSfarsit onclick="new Insertion.Bottom('lista','<li>'+$F('valoare')+'</li>')"> <input type=button value=AdaugaInainte onclick="new Insertion.Before('lista','<b>'+$F('valoare')+'</b>')"> <input type=button value=AdaugaDupa onclick="new Insertion.After('lista','<b>'+$F('valoare')+'</b>')">
Exemplul definete patru butoane ce execut funciile Insertion, insernd relativ la o list valoarea tastat n cmpul cu id=valoare. Clasa Insertion poate primi ca argument orice grup de noduri consecutive. Alte scenarii uzuale ar fi: inserare relativ la rndurile unui tabel n loc de blocul ul se va crea un bloc table iar funciile de inserare vor conine, n loc de li, marcatori pentru rnd i celul; inserare relativ la elementele unui formular; inserare relativ la componentele unui bloc div. Exemple: 78
<form id=formular> <input type=text value=111><br> <input type=text value=222><br> <input type=text value=444><br> </form> <input type=text id=valoare> <input type=button value=AdaugaInceput onclick="new Insertion.Top('formular','<input type=text value='+$F('valoare')+'><br>')"> <input type=button value=AdaugaSfarsit onclick="new Insertion.Bottom('formular','<input type=text value='+$F('valoare')+'><br>')">
n acest caz butoanele AdaugaInceput i AdaugaSfarsit insereaz noduri noi la nceputul i sfritul unui formular. Nu am mai reluat exemplele pentru inserare Before i After, acestea funcionnd oricum, independent de tipul grupului de elemente despre care e vorba. Grupul de elemente poate fi i unul eterogen, ca n exemplul:
<div id=blocdiv> <b>Imagine1</b><br> <img src="imaginel.jpg"><br> <b>Imagine2</b><br> <img src="imagine2.jpg"><br> </div> <input type=text id=numefisier> <input type=button value=AdaugaInceput onclick="new Insertion.Top('blocdiv','<b>Imagine0<b><img src='+$F('numefisier')+'><br>')">
Deoarece funciile Insertion permit explicitarea codului HTML ce va fi inserat (al doilea argument), utilizarea lor nu e limitat la colecii omogene de noduri (formulare, tabele, liste) ci e permis la orice grup de noduri frai grupate sub un marcator identificabil, dup cum se vede n ultimul exemplu.
Not: Avertizm asupra faptului c funciile Insertion permit doar inserare de cod HTML ce reprezint unul sau mai multe noduri complete i NU noduri pariale. Spre exemplu, nu e posibil ncapsularea grupului manipulat prin dou apeluri de genul... Insert.Before("bloc","<div id=blocnou>") Insert.After("bloc","</div>") ...deoarece nici una din cele dou funcii nu insereaz noduri complete. Regula e valabil pentru toate funciile Insertion.
Extinderea metodelor de lucru cu formulare. Prototype ncurajeaz abordarea formularelor ca i colecii de date mai degrab dect ca i subarbori ai arborelui DOM. Pentru aceasta, ofer metode de acces mai rapid la coninutul formularelor sau la formulare n ansamblul lor: Field.select() selecteaz valoarea curent a unui cmp; Field.focus() mut cursorul de focalizare pe cmpul dorit; Field.activate() combinaie ntre select() i focus(); Form.disable(), Field.disable() dezactiveaz cmpurile formularului; Form.enable(), Field.enable() face accesibile cmpurile formularului; Form.focusFirstElement() mut cursorul de focalizare la nceputul formularului, pe primul cmp.
<html> <head> <script type=text/javascript> ......... function campurinoi() { Element.toggle('detalii') Field.activate('TXadresa') Field.disable } ........... </script> </head> <body> ........ <form>
79
Informatii de baza: Nume: <input type=text> E-mail: <input type=text> <div onclick=campurinoi() style="color:red"> Click aici pentru detalii suplimentare </div> <div id=detalii style="display:none"> Adresa: <input type=text id=TXadresa> Telefon: <input type=text> </div> </form> ......... </body>
Acest exemplu definete un formular cu o poriune vizibil implicit, cu dou cmpuri, i o a doua poriune care devine vizibil doar la clic pe textul afiat cu rou (inclus n blocul div ce apeleaz funcia de activare a cmpului Adresa. Funciile enable() i disable() sunt disponibile att la nivel de formular ct i la nivel de cmp, avnd o utilitate deosebit n a converti un formular ntre strile read-only i editabil, de exemplu ca i consecin a apsrii de ctre utilizator a unui buton de editare. Accesul la poziia elementelor pe pagin. Prototype ofer o serie de mecanisme pentru a identifica poziia relativ a elementelor, inclusiv poziia fa de suprafaa vizibil a paginii ntr-o fereastr cu bare de derulare. Nu insistm asupra acestor mecanisme, deoarece ele sunt deja mpachetate n funcii de nivel i mai nalt, precum cele oferite de biblioteca Scrip.aculo.us.
2.4.2. Manipularea interfeei cu utilizatorul prin biblioteca Script.aculo.us

Script.aculo.us este una din cele mai cunoscute biblioteci JavaScript orientate spre interfaa cu utilizatorul, ce ncapsuleaz instrumentele oferite de pachetul Prototype n funcii de nivel i mai nalt. Componentele pachetului vizeaz: Efecte de animaie aplicabile oricror i orictor elemente din pagin, similare celor din prezentrile Powerpoint; Emularea unui mecanism drag-and-drop similar celui consacrat de aplicaiile desktop; Componente ce ncapsuleaz funcionaliti de nivel nalt precum mecanismele avansate de editare sau completare a casetelor de text; Componente ce permit testarea interfeei utilizatorului. Autorul pachetului este Thomas Fuchs. Succesul Script.aculo.us e garantat de adoptarea pachetului n designul unor site-uri de renume. Pachetul poate fi descrcat gratuit la adresa http://script.aculo.us. Instalarea sa presupune: Identificarea a 9 fiiere de tip js n arhiva descrcat. n versiunea actual, 1.8.1, acestea se afl n folderul src al pachetului (8 dintre ele) i n folderul lib (fiierul prototype.js). Fiierul prototype.js este chiar biblioteca Prototype care este aadar inclus n biblioteca Script.aculo.us; Copierea celor 9 fiiere ntr-un folder dedicat stocrii bibliotecii, n cazul nostru acesta va avea numele scriptaroot, n rdcina serverului Web; Scripturile ce vor folosi funcii Script.aculo.us vor include dou apeluri de biblioteci JavaScript, una pentru Prototype (versiunea Script.aculo.us) i una pentru Script.aculo.us (care conine apelurile celorlale 7 fiiere):
<script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script> Not: Chiar dac Prototype s -a instalat deja, am realizat instalarea versiunii din pachetul Script.aculo.us, pentru a evita riscul incompatibilitilor ntre Script.aculo.us i Prototype. n exemplele materialului de fa ultima versiune Prototype e apelat din folderul protoroot iar versiunea Script.aculo.us pentru Prototype e apelat din folderul scriptaroot.
80
Pachetul Script.aculo.us ofer un nucleu de efecte fundamentale (Opacity, Highlight, MoveBy, Scale, Parallel) i, pe baza acestora, o serie de efecte combinate de nivel mai nalt. Fiecare efect este o tranziie ntre dou stri, aadar fiecare efect permite fixarea unui punct iniial i a unui punct final, precum i durata desfurrii. Unele efecte sunt parametrizate cu coordonate ale ecranului sau distane. Toate efectele sunt asincrone n sens AJAX35, deci execuia lor nu ntrerupe execuia i experiena utilizrii, deci multiple efecte pot fi aplicate simultan aceluiai element. Efectele Script.aculo.us sunt o resurs deosebit pentru promovarea utilizabilitii aplicaiilor Web. Sintaxa general a unui efect este:
new Effect.NumeEfect(element,parametri,{optiuni})
Cuvntul cheie new este opional (ca i var la declararea variabilelor), rolul su fiind s indice un obiect nou creat. Opiunile sunt enumerate n format JSON. Cele mai uzuale dintre ele sunt: duration n secunde; fps frecvena de afiare a strilor intermediare ale animaiei (numrul de afiri pe secund, implicit 25); sync boolean, pentru sincronizarea frecvenei de afiare la efecte simultane; from punctul de start al efectului; to punctul de stop al efectului; transition algoritmul tranziiei, cu variante precum (se prefixeaz cu Effect.Transitions): o sinoidal vitez accelerat pn la un punct, apoi decelerat; o linear vitez constant; o reverse vitez constant cu inversarea punctelor de start i stop; o wobble micare dus-ntors repetat pe distane aleatoare; o flicker salt ntre poziii intermediare dintre start i stop; o pulse micri repetate (du-te-vino) ntre punctele de start i stop de 5 ori. Punctele de start i stop sunt definite normalizat, cu valori de la 0.0 la 1.0 mapate pe extremitile animaiei. Considerm un efect MoveBy ce deplaseaz un element cu 100 de pixeli la dreapta i n jos:
new Effect.MoveBy("idelement",100,100,{from:0.0,to:0.5})
Deplasarea suferit de element e definit pe distana 100x100 (distane negative vor permite deplasri la stnga sau n sus; prima valoare e verticala, a doua orizontala 36). Se observ enumerarea opiunilor n format JSON, aadar acestea pot fi anterior stocate ntr-un obiect. Opiunile acestui exemplu fixeaz: punctul de start 0.0 corespunde poziiei curente; punctul de stop 0.5 indic faptul c deplasarea se va opri la jumtatea distanei prevzute, aadar distana parcurs va fi de fapt 50x50. Prin urmare, opiunile unei animaii funcioneaz i ca modificatori pentru parametrii funciei. O facilitatea foarte puternic este posibilitatea de a asocia funcii JavaScript ca handlere pentru diverse stri intermediare ale efectelor. Caracterul asincron al efectelor trebuie pus n balan cu cu mecanismele de dialog cu utilizatorul. Spre exemplu, dac derularea unei animaii afieaz o caset alert(), animaia nu se va fi ntrerupe implicit n timpul interaciunii cu caseta de dialog. Exemplu:
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js>
A nu se confunda execuia asincron a efectelor cu posibilitatea afirii lor sincronizate, care se refer strict la aspectul lor vizual. 36 Atragem atenia c ordinea este invers fa de cea intuitiv, consacrat. E posibil s fie vorba de un bug. 81
35
</script> <script type=text/javascript> function deplasare() { new Effect.MoveBy("blocdiv",100,100,{from:0.0,to:0.5}) } </script> </head> <body> <div id=blocdiv onclick=deplasare()>Acest paragraf se deplaseaza la click!</div> </body> </html>
n acest exemplu, efectul MoveBy a fost legat, prin funcia handler a evenimentului click, unui bloc div. Pentru a nelege ce se ascunde n spatele efectelor Script.aculo.us, recomandm observarea codului surs a paginii cu instrumentul de depanare Firebug. Imaginea indic faptul c, la nivel de cod, efectul s-a obinut prin modificarea/crearea atributului style a blocului div ce marcheaz paragraful! Mai exact, prin MoveBy s-au modificat proprietile CSS legate de poziie. n lipsa bibliotecii Script.aculo.us, efecul s-ar fi putut obine prin construcia:
stilnou="position:relative; left:50px; top:50px" document.getElementById("blocdiv").style.cssText=stilnou
Evident, efectele Script.aculo.us ofer o economie semnificativ de efort att n editarea codului surs ct i n gndirea algoritmilor de tranziie. Spre exemplu, algoritmul flicker se obine printr-o formul matematic de randomizare a poziiilor intermediare ce implic funcii JavaScript precum cos(), random() i chiar Math.PI. n cele ce urmeaz, detaliem efectele fundamentale oferite de Script.aculo.us: Opacity() modific opacitatea (transparena) unui element al paginii, ntre extremele 0% (0.0, invizibil) i 100% (1.0, opac). Avertizm c opacitatea 0 nu e acelai lucru cu comutarea vizibilitii elementului (deci funcii Prototype ca Element.show() sau Element.toggle() nu vor avea 82
efect asupra unui element transparentizat pn la invizibilitate!). Aceasta se datoreaz faptului c opacitatea i vizibilitatea sunt proprieti CSS diferite (opacity i display sau visibility). Mai exact, un obiect complet transparent ocup totui o poriune din suprafaa afiat a paginii. Un obiect ascuns nu ocup spaiu n pagina afiat. Din acest motiv multe animaii de transparentizare sunt finalizate printro operaie explicit de ascundere a obiectului prin comutarea proprietii display la valoarea "none" sau visibility la "hidden". Exemplu:
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script> <script type=text/javascript> function deplasare() { new Effect.Opacity("bloc1",{ from:1.0,to:0.0,transition:Effect.Transitions.flicker}) } </script> </head> <body> <div id=bloc1 onclick=opacitate()>Acest paragraf devine transparent cu stri aleatoare</div> </div> </body> </html>
intermediare
Exemplul poate fi verificat tot prin clic pe paragraful afiat. De data aceasta, paragraful devine transparent (from 1 to 0!) trecnd prin stri intermediare aleatoare (flicker). Efectul de plpire se obine dac n loc de flicker se folosesc tranziii de alternare ntre punctul de start i de stop (pulse, wobble). MoveBy() asigur poziionarea elementelor pe pagin. Parametrii si obligatorii sunt distanele orizontal i vertical relativ la poziia curent (deci valori negative indic deplasare spre stnga sau sus). Un efect frecvent ntlnit este scuturarea elementului pentru a atrage atenia asupra sa (pulse aplicat pe o distan scurt). Scale() la dimensionarea elementelor paginii trebuie s se in cont de dou aspecte: fixarea unui col al elementului care s rmn fix n timpul dimensionrii i comportamentul elementelor imbricate n timpul dimensionrii elementului care le conine. Pentru aceasta, opiunile funciei sunt: scaleX: boolean (implicit true), stabilete dac e permis dimensionarea pe lime; scaleY: boolean (implicit true), stabilete dac e permis dimensionarea pe nlime; scaleContent: boolean (implicit true), stabilete dac elementele coninute se redimensioneaz proporional cu elementul printe; exist o serie de limitri n ce privete dimensionarea elementelor coninute: o funcia nu dimensioneaz elementele img (acestea trebuie s sufere propriul efect de dimensionare); o n unele browsere funcia dimensioneaz textul doar dac acesta a fost formatat explicit cu dimensiunea exprimat n uniti em (dimensiunea standard a literei m); scaleFromCenter: boolean (implicit true), stabilete dac centrul elementului rmne fix n timpul dimensionrii; scaleMode: valoarea box implicit stabilete s se dimensioneze doar poriunile elementului ce sunt vizibile fr derulare; valoarea content dimensioneaz complet elementul; scaleFrom: procentajul din dimensiunea curent de la care s nceap dimensionarea, implicit 100%.
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script>
83
<script type=text/javascript> function scalare() { new Effect.Scale('fereastra',300) } </script> </head> <body> <div id="fereastra" style="border: solid 1px black;"> <div id=titlu onclick=scalare() style="background-color: blue; color: white;"> Titlul ferestrei </div> <div id=continut> Continutul ferestrei </div> </div> </body> </html>
Exemplul provoac mrirea imaginii la clic pe bara de titlu a unei ferestrei simulate. Prin aceasta sugerm posibilitatea de a crea n AJAX o interfa bazat pe ferestre simulate, n care fiecare fereastr e definit ca un bloc div de conine alte dou blocuri div, pentru bara de titlu i pentru coninutul ferestrei. Diverse efecte pot reaciona prin handlere la diverse evenimente ale utilizatorului, pe diverse poriuni ale paginii, n cazul de fa, clic pe bara de titlu. Preluarea acestei sarcini de ctre un element de tip imagine (un buton, o bar de scalare) poate aduce interfaa AJAX mai aproape de interfeele aplicaiilor desktop, aducnd un semnificativ plus de utilizabilitate! Highlight() acest efect schimb culoarea de fundal a elementelor trecnd prin spectrul culorile intermediare. n forma implicit, efectul aplic modelul Yellow Fade, adic tranziie rapid, de tip flash, la galben i napoi, pentru a atrage atenia utilizatorului asupra unui element al paginii. Efectul nu afecteaz elementele care au deja o culoare de fundal stabilit prin CSS. Opiunile suplimentare ale efectului permit modificarea culorilor: startcolor: culoarea iniial de fundal; endcolor: culoarea final de fundal (dup care se revine la culoarea de fundal a paginii); restorecolor: culoarea final a fundalului elementului, dac se dorete s fie alta dect culoarea implicit de fundal a paginii. Valorile culorilor trebuie s fie coduri RGB hexazecimale introduse ca iruri de caractere. Animaia Highlight este, la baz, un algoritm de modificare a codului de culoare pentru proprietatea CSS "background-color" n cadrul unui ciclu for care modific sincron valorile R, G i B din codul culorii. Se poate remarca faptul c Script.aculo.us ofer instrumente de un nivel att de nalt nct percepia progamatorului asupra documentului se mut dinspre structura DOM (necesar atunci cnd se gndete n termeni de noduri i localizarea lor n arbore) spre suprafaa ocupat pe ecran de elementele formatate (necesar atunci cnd se aplic stiluri CSS).
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script> <script type=text/javascript> function colorare() { new Effect.Highlight('fereastra',{startcolor:'ff0000',endcolor:'00ff00'}) } </script> </head> <body> <div id="fereastra" style="border: solid 1px black;"> <div id=titlu onclick=colorare() style="background-color: blue; color: white;"> Titlul ferestrei </div> <div id=continut>
84
</div>
Continutul ferestrei </div>
</body> </html>
n acest exemplu, la clic pe bara de titlu, fereastra primete un flash de culori variind de la rou la verde. Se poate remarca faptul c bara de titlu rmne neafectat datorit stilului CSS predefinit. Parallel() permite aplicarea simultan a mai multor efecte i primete ca argument lista efectelor sub form de vector n sintax JSON. Permite aplicarea de opiuni comune tuturor efectelor, de exemplu fixarea unei durate comune. Exemplul de mai jos creeaz 4 efecte simultane asupra aceluiai element, sincronizate ca durat i frecven de afiare (frame-rate). Animaiile se declaneaz prin clic pe bara de titlu
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script> <script type=text/javascript> function multiplu() { a=new Effect.Highlight('fereastra',{startcolor:'ff0000',endcolor:'ffffff',restorecolor:'ff0000'}) b=new Effect.MoveBy('fereastra',100,100) c=new Effect.Scale('fereastra',300) d=new Effect.Opacity('fereastra',{from:1.0,to:0.5}) new Effect.Parallel([a,b,c,d],{duration:3,sync:true}) } </script> </head> <body> <div id="fereastra" style="border: solid 1px black;"> <div id=titlu onclick=multiplu() style="background-color: blue; color: white;"> Titlul ferestrei </div> <div id=continut> Continutul ferestrei </div> </div> </body> </html>
La acest set de 5 efecte fundamentale se adaug o list de efecte predefinite combinate pe baza celor fundamentale: Effect.Appear() opacitate iniial 0, crescut la 100 i asigurarea vizibilitii (dac elementul a fost definit ca ascuns prin proprietatea CSS display care, reamintim, nu poate fi controlat prin opacitate); Effect.Fade() opacitate iniial 100, cobort la 0 i ascunderea elementului n final; Effect.Puff() explozie: dublarea dimensiunii simultan cu transparentizarea i n final ascunderea elementului; Effect.BlindUp() micorare vertical la 0, fr micorarea coninutului i n final ascundere; Effect.BlindDown() mrire vertical la maxim, fr mrirea coninutului i n final asigurarea vizibilitii; Effect.SwitchOff() colapsarea elementului cu plpire (implic micorare centrat i opacitate flicker); Effect.DropOut() deplasare simultan cu transparentizare; Effect.SlideDown() alunecare n jos i dispariie a unui element div fiu din cadrul suprafeei unui unui element div printe; Effect.SlideUp() opusul efectului anterior; Effect.Squish() micorare brusc i ascundere; 85
Effect.Shrink() idem, cu micorarea coninutului; Effect.Grow() mrirea centrat elementului ncepnd de la 0; Effect.Pulsate() plpire pulsatorie, alternan de Appear i Fade; Effect.Shake() scuturarea orizontal (deplasare de tip pulse); Effect.Fold() mpturire (combinaie de BlindUp i Shrink).
Bibliografie modul: BUCHMANN ROBERT, Rolul XML n interoperabilitatea sistemelor informatice pentru afaceri, Ed. Risoprint, Cluj Napoca, 2007; CRANE DAVE et al., "Prototype and Scriptaculous in Action", Manning, 2007 CRANE DAVE et al., "AJAX in Action", Manning, 2005 Teste de verificare a cunotinelor Care sunt avantajele paradigmei Rich Client fa de siteurile tradiionale? Ce aspecte din siteurile tradiionale nu sunt suportate de obiectul XMLHttpRequest? Ce instrumente ofer biblioteca Prototype? Ce instrumente ofer biblioteca Scriptaculous? Ce instrumente ofer biblioteca Dojo? n ce fel deservete AJAX paradigma Rich Client? Ce rol are instrumentul Firebug?
86
Modulul III. Modele de afaceri pe Internet

Sumar
Modulul III. Modele de afaceri pe Internet 3. Categorii de afaceri pe Internet

3.1. Concepte de e-afaceri 3.2. Bariere n calea succesului comerului electronic 3.3. Tipologia pieelor electronice globale 3.4. Categorii de tranzacii electronice 3.5. Modele de afaceri electronice 3.6. Caracteristici ale comerului electronic 3.7. Componentele comerului electronic 3.8. Arhitectura de baz 3.9. Managementul relaiei cu clienii 3.10. Managmentul liniei de aprovizionare 3.11. Modaliti de plat - Contul de comerciant Obiective Prezentarea modelelor de afaceri electronice consacrate Prezentarea conceptelor fundamentale din domeniul e-business Prezentarea modelelor de management implicate n e-business
Recomandri Parcurgerea unor articole din presa on-line Parcurgerea de studii de caz pe Internet
Rezultate ateptate Asimilarea conceptelor specifice domeniului e-business Asimilarea modelelor de afaceri electronice consacrate Asimilarea modelelor de management implicate n e-business
Recapitulare Modulul anterior a prezentat principiile de implementare a modelului AJAX, oferind totodat ncadrarea modelului n paradigma Rich Client i compararea sa cu soluiile de nivel superior Dojo, Prototype i Scriptaculous. S-a insistat asupra mecanismelor de comunicare asincron prin structuri de date XML i JSON. n continuare se prezint sintetic modelele de afaceri electronice consacrate i, n contextul acestora, o serie de detalii privind comerul electronic, avantajele i limitele fenomenului.
87
3. Categorii de afaceri pe Internet

3.1. Concepte de e-afaceri
Piaa electronic (marketspace) reprezint spaiul virtual ce permite stabilirea unor relaii de parteneriat ntre cumprtori i vnztori, unde se tranzacioneaz afaceri electronice. Apariia acestui spaiu extrem de vast n care firmele i pot desfura activitatea transform pieele locale ale diferitelor produse n piee naionale sau chiar internaionale, competiia se intensific pe fondul concurenei firmelor din ntreaga lume care au acces la spaiul virtual, asistnd astfel la o adevrat revoluie a domeniului economic. Reacia firmelor la aceste tendine se manifest prin modificarea modului de organizare i de aciune, ncepnd s comprime vechile structuri ierarhice i s elimine barierele existente ntre compartimentele operaionale. Se tinde de asemenea, spre renunarea la barierele dintre firm i clienii sau furnizorii acestora. Tendina actual a multor firme este utilizarea Web-ul pentru a se face cunoscute, prin intermediul celei mai importante surse de informare din societatea informaional Internetul. Pentru a deveni un furnizor de informaii, trebuie s posede o pagin unic de pornire (home page), cu ajutorul creia orice firm poate deveni parte din Web, i poate oferi bunurile i serviciile i diverse informaii utile vizitatorilor site-ului. Principalele direcii ale utilizrii Internetului n afaceri pot fi concretizate astfel: comunicaie i administrare a informaiilor; asisten tehnic i servicii pentru clieni; vnzri directe; cercetri de marketing; publicitate on-line; cerere on-line; ntreinerea unei imagini publice; stabilirea unor reele pentru cumprtori. Astfel s-au dezvoltat cteva categorii care au impulsionat globalizarea: e-auctioning-licitatii electronice, e-banking - tranzactii bancare electronice, e-commerce - comertul electronic, e-directories - cataloage electronice - wite Pages, e-gambling - jocuri on-line, e-learning - invatamant prin Internet, e-mailing - mesajerie electronic, e-marketing - promovare electronica de produse/servicii, e-supply aprovizionare pe Internet, e-trading (e-brokering) - aciuni pe Internet i altele. Marketspace (piaa electronic) reprezint spaiul virtual ce permite stabilirea unor relaii de parteneriat ntre cumprtori i vnztori, unde se tranzacioneaz afaceri electronice. Deja este arhicunoscut faptul c mediul comercial contemporan se caracterizeaz prin creterea continu a produciei, accentuarea concurenei globale i creterea gradului de diversificare a cerinelor consumatorilor. Reacia firmelor la aceste tendine se manifest prin modificarea modului de organizare i de aciune, ncepnd s comprime vechile structuri ierarhice i s elimine barierele existente ntre compartimentele operaionale. Se tinde de asemenea, spre renunarea la barierele dintre firm i clienii sau furnizorii acestora. Literatura de specialitate ofer o serie de definiii ale acestui termen. Pornind de la analiza critic a unora dintre acestea vom ncerca s surprindem principalele elemente componente ale comerului electronic i nu n ultimul rnd principalele avantaje i dezavantaje pe care acest fenomen l implic. Afacerile electronice (Electronic Business, e-business) reprezint mulimea afacerilor asistate i bazate pe telecominicaii i informatic. Comerul electronic este definit ca ansamblul tranzaciilor comerciale n cadrul crora prile contractante interacioneaz prin intermediul calculatoarelor i nu prin schimburi fizice sau contacte directe. Dei este corect, o astfel de definiie nu poate capta integral spiritul comerului electronic care, n practic reprezint una din situiile n care nevoile tot mai complexe i tehnologiile noi se contopesc pentru a revoluiona modul n care se deruleaz afacerile. In concepia OECD (Organizaia Economic de Cooperare i Dezvoltare) comerul electronic reprezint desfurarea unei afaceri prin intermediul reelei Internet, vnzarea de bunuri sau servicii avnd loc offline sau online. Definiia elaborata de R.Kolakota i A.Whinston n lucrarea Frontier of electronic commerce aprut n 1996: Comerul electronic este o metod modern de efectuare a afacerilor, care se adreseaz nevoilor firmelor, pieelor i clienilor prin reducerea costurilor concomitent cu mbuntirea calitii produselor i serviciilor precum i creterea vitezei de oferire a acestora. 88
O alt definiie este dat de NTIA - National Telecomunications and Information Administration, definind comerul electronic ntr-un sens larg ca fiind utilizarea oricrei tehnologii electronice n orice aspect al activitii comerciale. ntr-un sens mai restrns termenul nseamn utilizarea infrastructurii naionale de informare, pentru realizarea uneia dintre urmtoarele funcii: atragerea produselor pe pia; intermedierea cumprtorilor i vnztorilor; comunicarea cu guvernul pentru urmrirea comerului; cumprarea electronic a produselor. Kalakota i Whinston (1997) definesc comerul electronic din mai multe perspective: din perspectiva tehnologiei comunicaiilor livrarea de informaii, produse i servicii sau plata bunurilor utiliznd orice metod electronic din perspectiva proceselor de afaceri utilizarea tehnologiei informaionale n vederea automatizrii tranzaciilor i fluxurilor de afaceri din perspectiva serviciilor posibilitatea reducerii costurilor i n acelai timp al creterii calitii i vitezei serviciilor prin utilizarea tehnologiei informaionale din perspectiva online capacitatea de a cumpra i vinde produse, informaii online Computer Desktop Encyclopaedia (www.computer language.com) definete sintaxa a face afaceri online astfel: Acest proces include cumprarea produselor, prin servicii online i Internet, precumn i schimbul de date electronice, prin care calculatorul unei instituii se informeaz i transmite ordine de cumprare calculatorului altei companii. O modalitate diferit de definire a acestui concept descrie comerul electronic att din perspectiva firmelor, ct i din cea a consumatorilor. Pentru unele firme, comer electronic nseamn orice tranzacie financiar care utilizeaz tehnologia informatic. Pentru altele, noiunea de comer electronic acoper circuitul complet de vnzri inclusiv marketing-ul i vnzarea propriu-zis. Indivizii consider comerul electronic ca fiind orice tranzacie comercial condus electronic pentru cumprarea unor produse cum ar fi cri, CD-uri, bilete de cltorie, informaie .a.m.d37. Din multitudinea de definiii ale comerului electronic se pot desprinde cteva idei de baz referitoare la acest concept. n primul rnd comerul electronic poate fi considerat un proces economic complex, care implic mai multe componente: instituii, procese i infrastructura informaional.
INSTITUII Guvernul Productori Comerciani Furnizori Consumatori Comer electronic REELE Proprii Internet Comerciale
PROCESE Marketing Vnzri Pli Suport
Componentele comerului electronic38 Comerul electronic produce schimbri eseniale n cadrul organizaiilor, prin modificarea proceselor de afaceri. Firmele trebuie s vad aceast schimbare ca o oportunitate i nu ca o provocare, un lucru important pentru c acest tip de afacere apare ntr-un mediu schimbtor, tehnologia evolueaz rapid i regulile competiiei se schimb. n aceste condiii utilizarea Internetului i a facilitilor acestuia ofer o ans firmelor de orice mrime s acioneze pe o pia dinamic i s obin un ctig n condiiile unei afaceri virtuale de succes. Astfel firmele mici pot obine o vizibilitate mai mare i acces la clieni din ntreaga lume, n timp ce pentru firmele mari, comerul electronic ofer posibilitatea Daniela Rusu - Comerul i afacerile mobile, extensii ale comerului i afacerilor electronice, tez de doctorat, 2005 38 Sursa: Kosiur, D., Understanding Electronic Commerce (How OnlineTransaction Can Grow Your Business), Microsoft Press, Redmond, Washington, 1997, p. 6 89
37
apropierii i a unei bune comunicaii cu clienii, avantaj exclusiv al firmelor mici. E-commerce ofer o oportunitate pentru a obine un avantaj maxim, dar aceast oportunitate trebuie s fie planificat. Comerul electronic ofer firmelor din ntreag lume i de diferite dimensiuni avantaje semnificative. n acest sens, Dave Chaffey39 identific att avantaje tangibile (care pot fi cuantificate), ct i intangibile (nu pot fi cuantificate). AVANTAJELE TANGIBILE Creterea vnzrilor, care conduce la creterea veniturilor prin ctigarea de: noi clieni, noi piee de desfacere clieni existeni (vnzri repetate) clieni existeni (vnzri indirecte) Reducerea costurilor de marketing prin: reducerea timpului de servire a clienilor vnzri online reducerea costurilor privind imprimarea i distribuirea elementelor de publicitate Reducerea costurilor de aprovizionare: nivel redus al inventarului creterea competiiei ntre furnizori reducerea timpului de procesare a comenzilor Reducerea costurilor administrative prin intermediul unor procese de afaceri mai eficiente, cum ar fi recrutarea personalului sau plata facturilor AVANTAJE INTANGIBILE Prezentarea imaginii firmei Brandul Campanii de marketing mai rapide i mai eficiente, inclusiv PR Cicluri de producie ale produselor mai rapide, care permit o adaptare mai rapid la cerinele pieei mbuntirea serviciilor oferite clienilor Adaptarea la cerinele viitorului Satisfacerea dorinelor consumatorilor ct mai bine Identificarea de noi parteneri de afaceri i imbuntirea relaiilor cu partenerii mai vechi Un management mai bun al informaiilor de marketing i mai ales al celor referitoare la clieni Feedback din partea clienilor n ceea ce privete produsele sau serviciile oferite 40 Principalele avantajele ale comerului electronic Ca i un mediu comercial, Web ofer un numr important de beneficii care pot fi examinate att la nivelul consumatorilor ct i la nivelul firmelor. Un beneficiu important al consumatorilor este accesul la cantitatea mare de informaii dinamice pentru sprijinirea lurii deciziilor. n plus caracterul interactiv a Web-ului permite cutare mai adnc, neliniar iniiat i controlat de clieni. De acum ncolo, comunicarea prin Web este mai mult condus de client, fa de mass-media tradiional, dirijat de cerinele furnizorului. Abilitatea Web-ului de a aduna, analiza i controla cantiti mari de date poate permite compararea cumprrilor i accelerarea procesului de gsire a articolelor. Web-ul faciliteaz proba i permite pe moment o satisfacie, clienii pot testa produsele online ceea ce stimuleaz cumprrile. De asemenea exist probabilitatea ca produsele greu de gsit s fie disponibile i o selecie mai larg a articolelor datorit lrgimii i eficienei Web-ului. n plus avantajele pentru consumatorii industriali sunt date de costurile reduse datorit competiiei n procurarea materiilor prime, deoarece mai muli furnizori pot concura ntr-o pia electronic deschis. Acesta determin pe competitori s ofere produse de gam larg i de mai bun calitate i de a produce articole conform cererii.
Dave Chaffey E-Business and E-commerce Management, Second Edition, Ed.Prentice Hall, 2004 40 Sursa: Chaffey, D. E-Business and E-commerce Management, Second Edition, Ed.Prentice Hall, 2004, p. 17
39
90
Din poziia de cumprtor, ctigul esenial este timpul deoarece acelai produs / serviciu poate fi cumprat mai ieftin, putnd fi vizitate mai multe magazine ntr-un timp scurt. Din punct de vedere al companiilor ce utilizeaz comerul electronic avantajele sunt multiple: creterea semnificativ a vitezei de comunicare, n special pentru comunicaiile internaionale; mbuntirea eficienei, dat fiind faptul c datele nu mai trebuie retastate manual att n calculatorul vnztorului, ct i al cumprtorului, permind minii de lucru s fie utilizat mai productiv; erorile de retastare se elimin; ciclurile de producie i cumprare se reduc drastic reducerea unor costuri, utiliznd e-mail-ul scad costurile cu pota sau mesagerie iar EDI poate nsemna o mare reducere a stocurilor i a costurilor legate de ciclul de cumprare; ntrirea relaiilor cu clienii i cu furnizorii, prin site-ul Web al companiei care prezint permanent partenerilor ultimele informaii necesare acestora iar EDI implic lucrul ntr-o strns legtur a partenerilor; o cale rapid i comod de furnizare a informaiilor despre o companie sau despre produsele sale prin intermediul unor site-uri www, a Intranet-urilor sau Extranet-urilor. canale alternative de vnzare, cum sunt afacerile prin intermediul unui site Web. 1. Beneficii pentru firme Extinderea la piee internaionale; Scdera costului de creare, procesare, distribuire, pstrare i gsire a informaiei bazat pe hrtie; Creeaz posibilitatea modelrii produselor i serviciilor pe nevoile cumprtorilor; Costuri de comunicaie mai mici. 2. Beneficii pentru consumatori D posibilitatea consumatorilor s cumpere sau s fac tranzacii 24h/zi, n tot timpul anului din aproape orice locaie; Acord consumatorilor mai multe posibiliti de alegere; Cumprtorii pot s aleag mai uor cel mai mic pre pentru un produs sau serviciu. 3. Beneficii pentru societate D posibilitatea mai multor persoane s lucreze de acas i s cumpere de acas ceea ce rezult n trafic mai mic pe strzi i popualre sczut a aerului; Permite ca anumite mrfuri s fie vndute la preuri mai sczute, cu avantaje pentru cei cu venituri mai mici; Crete eficiena i/sau mbuntesc calitatea. Beneficiile firmei sunt canalizate ndeosebi n domeniul distribuiei, comunicrii, precum i beneficii operaionale. Prin utilizarea Web-ului ca un canal de distribuie, costurile de distribuie sau costul vnzrii se contracteaz la zero. Acesta este mai probabil n domeniul publicitii, furnizarea informaiilor sau produse digitale. Mai mult, cumprtorii i vnztorii se pot contacta direct eliminnd cheltuieli de marketing i constrngerile impuse de asemenea interaciuni n lumea terestr, fcnd distribuia mai eficient. Timpul pentru desvrirea tranzaciilor comerciale se reduce, transformnduse n eficiene adiionale. Tehnologia ofer firmelor oportunitatea de a monitoriza alegerile consumatorilor prin dezvluirea preferinelor lor n comportamentul de navigare i cumprare prin Web. n general firmele utilizeaz Web-ul pentru a furniza informaii despre firm i despre oferta lor, precum i pentru comunicare intern i extern cu alte firme i consumatori. Site-urile Web sunt la dispoziia clienilor 24 de ore pe zi,7 zile pe sptmn. Caracterul interactiv al mediului poate fi folosit de marketeri pentru atragerea ateniei clienilor, prin angajarea lor ntr-un dialog care este o comoditate pentru ambele pri, acesta oferind oportunitatea de a croi comunicaie precis cu consumatorii individuali, permind clienilor de a solicita informaii ct doresc. Obinerea informaiilor relevante despre clieni, care sunt utilizate n scopul de a servi mai eficient n viitor permite firmelor s dea informaii clienilor despre ofertele lor i de a obine informaii despre clieni, despre necesiti, preferinele lor. Un aspect important este oportunitatea competiiei bazate pe axele specialitii n loc de axele preurilor. Beneficiile operaionale ale Web-ului, n cazul vnzrilor, sunt erori reduse i ctig de timp n procesarea informaiilor; costuri reduse prin accesarea electronic a bazelor de date a ofertei. n plus este facilitat crearea de noi piee i segmente de pia precum i intrarea mai uoar pe pieele existente i timp mai redus pentru tranzacii. Prin acesta este mai uoar i mai ieftin gsirea clienilor poteniali eliminnd i obstacolele dintre diferii pai ai subproceselor de afaceri.
91
3.2. Bariere n calea succesului comerului electronic

Indiferent de tipul de comer electronic abordat, acesta ntmpin o serie de dificulti i bariere mai mari sau mai mici, n funcie de o serie de factori de influen n domeniile economic, social, tehnologic, cultural etc. n continuare ne vom referi la o serie de obstacole importante n desfurarea afacerilor de comer electronic, identificarea acestora fiind un punct de plecare n gsirea cilor de reducere sau nlturare a lor. Sistemul de livrare a produselor la scar global. Una din principalele bariere n calea dezvoltrii pieelor internaionale l reprezint complicaiile vamale, de impozitare i formalitile cu transportul. Principalul obstacol, care continu s existe, este cel legat de distribuia global a bunurilor i serviciilor.Un alt obstacol se refer la dificultatea de a derula livrarea i/sau expediia unor loturi (pachete) mai mici. Cercetrile din rile membre ale UE evideniaz complicaii ale transportului internaional i datorit fragmentrii logisticilor interri. Diferen de cultur, limb i practic comercial. Aceasta include, i cultura afacerilor i practica propriu-zis comercial. Adesea dificultile n comerul electronic global sunt create de diferenele n sistemele legislative. n domeniul serviciilor juridice, pieele electronice globale nu se pot crea cu uurin, excepie fcnd unele domenii-ni, cum ar fi practica juridic internaional pentru cazul marilor corporaii. Fragmentarea n industrie. n rile n care industria este divizat n multe firme mici, poate fi deosebit de greu s se ating economia de scar necesar crerii unei piee electronice globale, chiar dac piaa produsului de baz, potenial, poate fi considerat global. Internet-ul i pieele electronice pot crea presiuni adiionale n scopul consolidrii industriilor fragmentate, n mod similar cu serviciile financiare asigurrile, transporturile i turismul Cadrul global autoreglator i juridic. n ultimii ani, au fost realizate progrese semnificative n adaptarea cadrului legal la realitatea comerului electronic i n dezvoltarea autoreglrii acestuia prin convenirea codurilor de conduit, n cadrul dezbaterilor i politicilor mai multor organisme internaionale. Cu toate acestea, legile i cadrul de conduit adesea vizeaz o singur ar i nu au o aplicabilitate global n mai multe ri. De exemplu, contractele electronice ncheiate ntre un vnztor i un cumprtor din ri diferite, prin intermediul unui Web site, trebuie s se supun legislaiei uneia dintr ri. n cadrul UE aceast situaie a fost rezolvat n 2002, prin adoptarea principiului rii de origine. Acest principiu precizeaz c un contract se supune legilor rii de origine a vnztorului i se aplic i n cazul e-mail. [Chaffey2004] Bariere specifice micilor ntreprinderi. Micile ntreprinderi ntmpin o serie de dificulti n a participa sau crea piee electronice globale. n primul rnd, acestea se refer la volumul relativ sczut al resurselor de capital i personal, lipsa de vizibilitate a mrcilor de fabricaie. n cazul IMM-urilor, problema cheie n crearea unor piee electronice este alegerea unor strategii specifice de genul parteneriatelor strategice, aranjamentelor privind mprirea segmentelor de pia ca, de exemplu, franchising i scheme asociate acesteia (zone comerciale). Concentrarea asupra unor nie de pia i cooperarea cu alte firme mici (crearea n comun a unor website-uri pentru promovarea exporturilor, aa cum fac micii exportatori de mobil n Spania). Ca participani individuali la pieele electronice, ntreprinderile mici pot ntmpina mari dificulti deoarece, n faza iniial a unor astfel de piee electronice, vor crete mai degrab transparena preurilor dect transparena caracteristicilor produselor n general (calitate, termen de livrare, nivelul serviciilor i cunotinele referitoare la afaceri). Strategii de marketing insuficient adecvate. Societile care vor s participe la comerul electronic global trebuie s-i exploateze activele de care dispun n mod global. Ele trebuie s depeasc obstacolele din mediile lor de afaceri i s-i soluioneze principalele slbiciuni interne. Strategiile de marketing sunt, de regul, urmtoarele: - orientarea ctre o pia global a produsului; - participarea la un lan global de livrare; - ofertarea unui suport lingvistic multiplu; - crearea unei zone reea de franchising; - complementaritatea prezenei fizice globale cu prezena pe Internet; - construirea unei prezene globale, prin fuziuni i achiziii.
92
3.3. Tipologia pieelor electronice globale

Literatura de specialitate clasific pieele electronice globale n patru grupe: piee electronice intrinsec globale care se ocup cu produse globale, consumatori, furnizori (exemplu: ntreinere, reparaii, automobile). piee locale global organizate (de exemplu, licitaiile de bunuri perisabile); piee locale cu infrastructur global; asociaii de export n care produsele sunt exportate global prin colaborarea productorilor.
Piee electronice intrinsec globale sunt acele piee care se ocup cu produse de natur global i cu consumatori i furnizori care sunt caracterizai printr-o prezen global. Multe dintre schimburile B 2 B aparin acestei categorii de piee. Acestea sunt necesare pentru afaceri n lumea ntreag i adesea exist muli furnizori pe plan mondial pentru astfel de produse. Pieele care ofer o viziune uniform asupra produselor oferite (Trade zone, Barclays, B2B) sunt intrinsec globale. Pieele locale global organizate sunt n mod necesar limitate din punct de vedere geografic. Cu toate acestea, modul de abordare i desfurare a tranzaciilor ntr-o regiune poate fi utilizat i n alte regiuni, n felul acesta realizndu-se o legtur ntre pieele respective.. Pieele locale construite pe o infrastructur global reprezint un alt tip de pia electronic funcional n plan local i global. Cnd se vorbete despre pieele electronice globale nu toate trebuie s fie ntr-adevr globale. Funcia real de reprezentare i comercializare a acestor tipuri de piee poate fi n ntregime local, n timp ce funciile de acces, plata, securitatea i livrarea produselor ar putea fi globale. Asociaiile de export reprezint un alt tip de pia electronic de dimensiune global care, cu toate acestea, este caracterizat i printr-un puternic element local. Conceptul const n existena unui numr de furnizori (ofertani), din aceeai regiune geografic, care caut o prezen global, dar care nu sunt capabili s acioneze global n mod individual. Acetia creeaz o entitate comun de export, care se ocup, n numele lor, de complexitatea comerului internaional cum ar fi cataloage n mai multe limbi, reglementri de export/import, finanri n mai multe valute, expediii internaionale etc. Dar valoarea real a e-business-ului apare n momentul n care companiile accept ideea comunicrii n dou sensuri, cnd ei integreaz propriile pagini Web, sistemele intranet i extranet n sistemul existent de afaceri, crend noi oportuniti pentru clieni, salariai, furnizori i distribuitori pentru a interaciona cu ei n orice moment i oriunde. Mai mult ca att, lucrnd cu intermediari, compania este capabil s furnizeze direct informaii de care au nevoie i realizeaz afaceri. Ca urmare salariaii, clienii, distribuitorii i furnizorii ctig mai mult accesnd datele mai repede i interacionnd direct cu nucleul sistemului de afaceri, iar companiile descoper posibiliti noi de folosire a resurselor. De fapt, informaiile obinute de firme, prin interaciunile directe cu salariaii, clienii, distribuitorii i furnizorii devin resurse pentru acestea. Firmele pot folosi aceste cunotine i experiene pentru a fundamenta calea spre care trebuie condus afacerea. Acesta este adevrata for a e-business-ului. Un e-business prosper are i o alt caracteristic. Firmele sunt interesate s vad schimbarea ca o oportunitate i nu ca o provocare. Acest lucru este important pentru c e-business-ul apare ntr-un mediu schimbtor, tehnologia evolueaz rapid i regulile competiiei se schimb. Dac o firm este mare, e-business poate ajuta ca s se comporte ca o companie mic, mult mai agil, fcnd compania mult mai responsabil i ofernd posibilitatea unei comunicaii mult mai directe cu clienii, n schimb dac este o companie mic, e-business poate s-o ajute ca s par una mare, oferind o vizibilitate mare i acces la clieni din ntreaga lumea.Deci, indiferent de mrimea firmei, peste tot clienii actuali i milioanele de noi clieni poteniali pot s aib acces la afacere oricnd i oriunde. E-business ofer o oportunitate pentru a obine un avantaj maxim, dar aceast oportunitate trebuie s fie planificat. Importana fundamental a e-business-uluireducerea costurilor, creterea veniturilor, satisfacerea clienilorse dovedete a fi doar vrful unui aisberg. Dup ce i-au dat seama de beneficiile Web-ului se ncearc sporirea aestor beneficii prin intergrarea aplicaiilor i tehnologiilor noi i existente e-business. Aceste procedee ajut la satisfacerea clienilor i mbuntesc eficiena.
93
Cheia ctre succes, este gsirea unor mijloace, de a oferi clienilor ceea ce-i doresc, fr cheltuielile operaiilor unei afaceri tradiionale. Comerul electronic reprezint un mijloc de a susine i realiza aceste schimbri pe scar larg i chiar la scar global. El ofer firmelor posibilitatea de a fi mai eficiente i mai flexibile n operaiunile interne, de a menine legturi mai strnse cu furnizorii i de a rspunde prompt cerinelor i doleanelor consumatorilor. Firmele i pot selecta cei mai adecvai parteneri de afaceri fr a mai ine cont de distanele geografice i i pot comercializa produsele pe o pia global.
3.4. Categorii de tranzacii electronice

Comerul electronic este o tehnologie utilizat n scopul schimbrii globale. Firmele care l privesc doar ca pe o modalitate suplimentar de derulare a afacerilor, vor avea beneficii limitate. Cele mai importante avantaje le vor obine acele companii care sunt dispuse s-i modifice organizarea i modul de funcionare, pentru a se adapta cerinelor operaionale ale comerului electronic. Comerul electronic poate fi divizat n mai multe categorii, n funcie de agenii participani: tranzacii ntre firme (business to business - B2B); tranzacii ntre firme i consumatori (business to consumer - B2C); tranzacii ntre firme i organizaii guvernamentale (Business to Governement -B2G); Business-to-Administration (B2A) care se refer la relaiile dintre o firm i instituiile de administraie public; tranzacii ntre consumatori i organismele guvernamentale (Consumer to Governement C2G); tranzaciilor ntre dou persoane private (Consumer to Consumer C2C). Business to Employee (B2E), se refer la tranzaciile din cadrul unei firme, folosind propriul sistem de intranet.
Firme (B)
Consumatori (C)
Guvern (G)
Angajai (E)
Firme (B)
B2B Comer electronic
B2C comer electronic
B2G Administraie, logistic C2G achitare online G2G coordonare

41
B2E Colaborare, coordonare
Consumatori (C)
C2B comparaie preuri G2B informare
C2C Licitaii online G2C informare
taxe
Guvern (G)
Principalele categorii de tranzacii electronice
n prezent, cele mai rspndite tipuri de comer electronic sunt Business-to-Business (B2B) i Business-to-Consumer (B2C). 1. Tranzaciile B2B se caracterizeaz prin faptul c ambele pri participante la tranzacia comercial, att vnztorul ct i cumprtorul, sunt instituii (ex rtcoffice.ro). Acoper toate tranzaciile efectuate ntre doi sau mai muli parteneri de afaceri. Aceste tranzacii sunt bazate de obicei pe sistemele extranet, adic partenerii de afaceri interacioneaz prin Internet cu numele de login i parolele de pe website-urile lor. Din punctul de vedere al unui client B2B managementul informaiei destinate cumprtorului ar trebui s se regseasc n site-ul cumprtorului, n vederea integrrii cu celelalte informaii. De asemenea, informaia destinat cumprtorului trebuie stocat n serverul acestuia, pentru a fi posibile plile electronice, fluxul de lucru, rspunsul prin Intranet. Un exemplu
41
Sursa: www.moldovainomc.org/modules/mydownloads/pdf/2003-02.pdf 94
pentru aceast categorie l reprezint o firm care utilizeaz reeaua de Internet pentru a plasa comenzi la furnizori, pentru a recepiona facturi i pentru a efectua pli. Acest tip de comer este implementat de civa ani, folosind n special tehnologia EDI (Electronic Data Interchange) n cadrul unor reele private i securizate. Schimbul Electronic de Date (EDI - Electronic Data Interchange) a aprut prin anii 1960 i poate fi considerat strmoul Comerului Electronic (EC - Electronic Commerce). EDI ofer societilor comerciale posibilitatea s schimbe documente de afaceri ntr-o form standard, utiliznd mijloace electronice pentru prelucrarea i transmiterea acestora. n acelai timp bncile utilizeaz reele dedicate pentru Transferul Electronic de Fonduri (EFT- Electronic Funds Transfer). Reelele ce folosesc tehnologia EDI au fost extinse n Internet. Una dintre acestea este Trading Process Network, care are 40.000 clienti n lume i permite cumprtorilor s stabileasc un canal sigur ctre principalii furnizori, s cear cotaii potenialilor noi furnizori din lume. Reeaua este folosit azi de Hewlett Packard, Textron Automotive, Chrysler, suplimentar peste 1.400 ntreprinderi mici i mijlocii din lume particip la tranzactii. Recent, odat cu creterea accesibilitii la Internet, EC a cptat interesul consumatorilor individuali i al societilor comerciale de orice mrime i preocupri. Mai mult dect att, cu tehnologiile avansate disponibile acum, se vorbete tot mai des de Economia Digital (DE- Digital Economy). 2. Tranzaciile B2C se realizeaz ntre cumprtori individuali i vnztori-mari companii (www.emania.ro, www.amazon.com ). n acest caz, factorul uman este mult mai important, interactivitatea fiind caracteristica de baz n decizia de cumprare. Se refer la relaiile dintre comerciant i consumatorii privai, activitate care este considerat comer electronic cu amnuntul. Acest tip de afaceri se bazeaz de obicei pe tehnologii Internet. Tranzaciile dintre firme i consumatori se refer la vnzarile electronice en-detail. Aceast categorie s-a dezvoltat foarte mult odat cu apariia i extinderea World ide Web iar n prezent exist o multitudine de magazine virtuale pe Internet, care ofer o gam foarte larg de produse, ncepnd de la prjituri i jucrii i terminnd cu calculatoare i autoturisme. 3. Tranzacii B2G Include toate tranzaciile dintre firme i organismele guvernamentale i administrative.(de exemplu e-licitatie.ro) Guvernele, la nivel naional, regional i chiar municipal utilizeaz canale de comer electronic pentru creterea eficienei operaiunilor, mbuntirea nivelului serviciilor oferite clienilor. O arie de interes pentru guverne n domeniul afacerilor este utilizarea pe scar mai larg a Interentului i a reelelor VAN, pentru diseminarea informaiei, a oportunitilor, cotaiilor primite de la vnztori/furnizori de bunuri i servicii. Tradiional, listele cu oportuniti erau transmise furnizorilor sub forma unei scurte liste, n ziare, sau n publicaiile guvernului. ntre anii 1980-1990 cteva guverne inovatoare, prin ageniile lor au nceput s utilizeze folosind sistemul dial-up n transmiterea "bulletin board services"(BBS), care asigur accesul online la cererile curente de informaii/oportuniti/consultan. Acest abordare a implicat din partea beneficiarului serviciilor BBS adaptarea la aceeai tehnologie software pentru a putea utiliza informaia. Departamentul de Aprare al Statelor Unite, pentru a avea o audien naional i internaional i-au proiectat reeaua VAN proprie, pentru a distribui informaia la audien. Aceast soluie a cerut de asemenea, furnizorilor s se aboneze la serviciile reelelor de provideri i s utilizeze capacitile de comunicare cum ar fi soft-ul necesar transmisiilor EDI, dac doreau s descarce informaiile n sistemele proprii. De exemplu, n SUA informaiile cu privire la noile taxe guvernamentale sunt publicate pe Internet, iar firmele pot reaciona pe cale electronic. n anii '90 aceast categorie se afla ntr-o stare incipient, dar ea se dezvolt rapid, avnd n vedere c unele guverne acioneaz n sensul promovrii i dezvoltrii comerului electronic. Pe lng publicarea unor informaii, organismele guvernamentale pot s ofere opiunea plii electronice a TVA i a altor taxe i impozite. Un exemplu elocvent este site-ul www.elicitatie.ro care permite achiziia de materiale consumabile, echipamente i alte categorii de mrfuri de ctre instituiile bugetate, prin intermediul licitaiei pe Internet. Totui, n condiiile dezvoltrii att a tranzacii dintre firme i consumatori, ct i a celor dintre firme i administraie, guvernele pot extinde interaciunea electronic n domeniul privind plata ajutoarelor sociale, returnarea taxelor etc. 4. Tranzacii C2G, acoper relaii guvern-ceteni la nivel de informare i prestare servicii publice(ex pltirea taxelor online). Categoria tranzacii dintre consumatori i organismele guvernamentale a fost implementat n ara noastr la nivel local (primrii). Totui, n condiiile 95
dezvoltrii att a tranzacii dintre firme i consumatori, ct i a celor dintre firme i administraie, guvernul a iniiat i va extinde interaciunea electronic n domeniul taxelor achitate la administraiile locale, privind plata ajutoarelor sociale, returnarea taxelor etc. 5. Tranzacii C2C, consumatorii care vin direct la ali consumatori (okazii.ro, ebay.com) n aceast categorie se includ site-urile de licitaii online, precum Ebay, QXL sau comuniti virtuale.. 4. Business to Employee (B2E) reprezint tranzaciile ntre o firm i angajaii si prin intermediul sistemului intranet. Impactul comerului electronic se face simit att la nivelul fiecrei firme, ct i pe ansamblul societii. Pentru firmele care-i exploateaz la maxim potenialul, comerul electronic ofer posibilitatea unor schimbri fundamentale care modific att de radical ateptrile consumatorilor, nct ajung s redefineasc piaa sau s creeze noi piee. Toate celelalte firme, inclusiv cele care ncearc s ignore noile tehnologii, vor fi influenate de schimbrile n ateptrile consumatorilor i ale caracteristicilor pieelor. n acelai timp, membrii societii vor beneficia de noi modaliti de achiziionare a bunurilor, de accesare a informaiilor i de interaciune cu organismele guvernamentale. Posibilitile de alegere vor fi mult mai mari, iar restriciile de spaiu i timp vor fi eliminate. Impactul global asupra stilului de via poate fi comparabil cu cel al creterii numrului de autoturisme sau cu cel al dezvoltrii telefoniei mobile.
3.5. Modele de afaceri electronice

Piaa virtual cuprinde urmtoarele modele de afaceri electronice: Magazinul electronic (e-shop) reprezint modelul sub care se desfoar n general comerul electronic de tip B2C. Un magazin electronic ofer firmelor posibilitatea de a-i prezenta oferta prin intermediul mediilor virtuale. Avantajele acestui model de afacere este n principal accesul la o pia extins, chiar internaional, pia care n acest caz devine mai accesibil fimelor mici i mijlocii. Un magazin electronic se implementeaz prin intermediul unui site Web, este administrat de companie pentru activitile de marketing i cele de vnzare a propriilor produse i servicii. Minimal, site-ul Web conine un catalog de produse sau servicii cu descrieri tehnice i comerciale pentru fiecare poziie din catalog. Aceste descrieri sunt gestionate n general de un SGBD (Sistem de Gestiune al Bazelor de Date) care va asigura stocarea i manipularea datelor, gestionarea posibilitilor de acces concurenial i securitatea tranzaciilor. Produsele care se comercializeaz cel mai bine prin intermediul magazinelor virtuale sunt, de regul, cele care pot fi descrise cu uurin i nu necesit ncercarea lor nainte de cumprare. Spre de exemplu: bilete de avion sau de concert, CD-uri, cri, software, produse alimentare, etc. Din punctul nostru de vedere, serviciile au rolul de a completa oferta de produse i se circumscriu deseori unei sfere mai largi, cum ar fi spre exemplu site-ul de comercializare a produselor cosmetice care poate prezenta i un desen/schi despre cum se aplico crem, un ghid despre genul de fard recomandat dimineaa, n timpul zilei i respectiv seara. Preurile produselor comercializate prin intermediul magazinelor virtuale sunt, n general mai mici dect cele practicate n magazinele fizice. Serviciile de informare sunt oferite gratuit la nceput, prin acces liber sau abonamente gratuite la publicaii periodice. Ulterior, ofertanii vor iniia servicii suplimentare de tipul accesului la arhive i vor extinde posibilitile de cutare, solicitnd utilizatorului plata unui abonament pentru a beneficia de acestea. S-a constatat c impactul abonamentului on-line asupra utilizatorilor este foarte mic deoarece majoritatea rmne fidel abonamentelor clasice, n general, numai clienii noi apeleaz la acest nou sistem de abonament. In schimb abonamentele on-line pentru accesul la tiri de ultima or sau la dezbateri cu participare restrictiv (contra cost), capteaz interesul doar dac serviciile oferite sunt de valoare mare. Aprovizionarea electronic (e-procurement). Integrarea electronic i managementul tuturor activitilor de aprovizionare primirea de oferte, comenzi, livrri i pli ntre o firm i furnizorii acesteia. n categoria aprovizionrilor electronice se includ i licitaiile organizate de marile firme i autoritile publice pentru achiziionarea de bunuri i servicii. Prin publicarea pe Web a specificaiilor ofertei, scad att timpul ct i costul de transmisie, mrindu-se i numrul de firme care iau parte la licitaie. Astfel, crete concurena i scade preul. Magazin electronic universal (e-mall): reprezint o transpunere n spaiul virtual al marilor complexe comerciale, prin intermediul unui site Web care cuprinde oferta mai multor magazine. Aceste
96
magazine ofer spre vnzare produse diferite. Mall-ul optim se definete ca fiind un mall cu o reea puternic, cu o strategie de marketing bun, cu un front de prezentare adecvat i din care s se poat accesa direct i pe mai multe ci e-shop-ul. Din punctul de vedere al clientului, un e-mall faciliteaz accesul la o mulime de magazine, cataloage de firm, vnztori specializai, la produse ale unor firme de renume i ajut clientul s gseasc i s aleag exact produsul de care are nevoie. Exist e-mall-uri care acoper o gam variat de produse, pot oferi produsele unui anumit productor sau pot acoperi o zon geografic. Un e-mall poate accepta metode de plat comune. Un magazin electronic de tip Mall reprezint un depozit electronic conectat la o serie de baze de date ale furnizorilor si, nu necesit spaiu de construcie, timp i bani pentru efectuarea de inventarieri i ofer posibilitatea de a face constant cele mai mici oferte la cele mai avantajoase preuri, ofer discount-uri ntre 10% i 50%. n concepia general magazinul virtual e-mall are propriile baze de date precum i baze de date conectate la magazine en-detail, productori sau en-gros. n momentul n care consumatorul solicit un produs sunt analizate bazele de date i se caut cele mai bune oferte, clientul alege produsele dorite, iar dac se ncheie actul de vnzare-cumprare se stabilete modalitatea de livrare a produselor comandate. Practic un e-mall ofer spaiu pentru mai multe e-shop-uri i poate fi realizat utiliznd diverse modele de tranzacii, n funcie de tipul de servicii pe care dorete s le ofere proprietarul e-mall-ului, de dezvoltarea strategiei de marketing a e-mall-ului. Un e-mall de succes se definete ca fiind o reuniune de magazine virtuale care deine o reea puternic, o strategie de marketing foarte bine gndit, un front-end de prezentare adecvat i diverse modaliti de accesare a e-shop-urilor componente. Conceptual e-mall este o afacere ce se integreaz n modelul colaborativ de ineraciune, comercial bazat pe acces al clienilor la un catalog on-line. Licitaiile electronice (e-auctions) permit achiziionarea prin intermediul unei licitaii, a unor produse de care indivizii nu au nevoie n mod frecvent. O licitaie electronic mai muli vnztori la fel ca n cazul unui e-mall. Licitaiile electronice pot fi de tip B2C (www.ebay.com) sau de tip B2B (www.qxl.com) Licitaia electronic reprezint automatizarea procesului de cumprare sau de procurare de resurse folosind aplicaii Web. Licitaia electronic ofer posibilitatea diferiilor cumprtori i ofertani s se ntlneasc, s interacioneze i s execute tranzacii direct pe Internet. Licitarea produselor i obiectelor pe Internet s-a dovedit a fi un model de mare succes, utilizat att pentru comerul electronic B2B ct i pentru cel B2C i, datorit faptului c este un domeniu de mare interes, poate fi, de asemenea integrat i n e-shop-urile obinuite. Produsele vndute prin licitaie electronic pot fi bunuri de ultim or, de suprastoc sau cu stoc fluctuant sau obiecte de valoare pentru colecionari specializai. Prin intermediul licitaiilor electronice se pot comercializa o gam variat de produse, de la bunuri materiale, metale, materii prime pn la obiecte de art, de mare valoare. Operatorul licitaiei gestioeaz mecanismele de plasare a obiectului licitaiei, (de obicei prin e-mail) i poate oferi n plus servicii de pli i de livrare. ntr-un sistem de e-licitaie fiecare pas se realizeaz electronic,de la crearea i trimiterea cererilor de ofert pn la recepionarea i plata bunurilor, datele tranzacionate sunt procesate electronic, reducnd astfel timpul i costul operaiilor de procurare, ceea ce determin o cretere a eficienei organizaiilor. Aplicaiile de tip licitaie electronic au la baz cataloage de produse ale diverilor ofertani care sunt unificate ntr-o singur surs de oferte, att pentru bunuri ct i pentru servicii. Inglobate n procesele de afaceri i n sistemele informatice Intranet, att ale vnztorilor ct i ale cumprtorilor, aplicaiile e-Procurement micoreaz costurile de procesare, gestiunea cataloagelor i mbuntaesc accesul clienilor la oferte. E-procurement leag vnztorii i cumpartorii ntr-o pia virtual dinamic care se bazeaz pe principiile economiei concureniale. Comuniti virtuale (virtual communities): ofer indivizilor posibilitatea de a se ntlni i discuta subiecte de interes pentru ei. Comunitile virtuale sunt grupuri de discuii interactive sau liste de corespondeni pentru dezbaterea subiectelor din diferite domenii de interes ale participanilor. Discuiile pot fi pe diferite teme, de la cele de divertisment pn la cele ce vizeaz un anumit domeniu de activitate. Astfel de discuii au loc prin intermediul forumurilor (forums), grupurilor (chat) sau listelor (mailing lists) de discuii. Acest sistem permite firmelor s participe la comuniti permanente sau temporare (asociaii, consorii, echipe de lucru la un proiect. Comunitile virtuale de afaceri reprezint un astfel de exemplu i se pot mpri n comuniti B2B sau B2C. Pe Internet se ntrunesc oamenii care au interese comune n comuniti, pentru a discuta sau a asculta tematicile preferate42 Calitatea de membru al unei comuniti virtuale presupune de obicei plata unei taxe. Instrumentele necesare comunitilor virtuale sunt oferite uzual ca servicii gratuite, n scopul
42
http://www.euro-info.ccir.ro/com-el.htm 97
creterii traficului pe site-ul Internet i dar pentru stimularea fidelitii i ataamentului emoional fa de aceasta. Comunicrile de afaceri n schimb pot fi realizate prin intermediul unui serviciu contra cost. Canalul de comunicare direct sau video-conferinele sunt instrumente atractive care reduc costurile de cltorie i sunt utilizate de firmele mari, att pentru comunicri tiinifice ct i pentru cele comerciale1.n funcie de statutul organizatorului conferinei, firm, prestator de servicii sau asociaie subiectele de discuii pe care le propune acesta pot fi taxate sub forma unei taxe de participare sau specifice evenimentului sau nu se percep taxe deloc. Platformele de colaborare ofer firmelor i indivizilor, experilor posibilitatea colaborrii ntr-un anumit domeniu. Scopul unei astfel de platforme este unul precis i implic n general sarcini de cercetare dezvoltare (proiectarea produselor, realizarea unor planuri, etc.). Platformele pot fi proprietatea unei firme sau organizaii sau neutre, caz n care confidenialitatea se ofer prin mecanisme precum semntura digital. Ctigurile provin din managementul platformei (taxa de membru sau taxa de utilizare), i din vnzri de instrumente specializate (pentru proiectare, workflow i gestiunea de documente). Platformele de colaborare ofer un set de instrumente i un mediu de informare pentru colaborarea ntre intreprinderi, ntre acestea i colaboratorii externi i ntre experi, acionnd ca o intreprindere virtual fa de lumea exterioar. n cazul n care platforma nu aparine unei anume ntreprinderi, operatorul trebuie s acorde o atenie special statutului de neutralitate, proteciei datelor i siguranei comunicrii, pentru a nu permite scurgeri de informaii de interes pentru concuren. Viteza de transmisie are o importan major, mai ales n domeniul tehnic iar semntura digital devine un instrument indispensabil pentru derularea activitii n general sau pentru domeniul contractual, n special1. Piata unui ter (Third-party marketplace) ofer vnztorilor o interfa Web pentru catalogul de produse al companiei, se ocup de promovarea acestora, preluarea comenzilor, logistic, efectuarea plilor i asigurarea securitii tranzaciilor. Site-ul Amazon.com este un exemplu n acest sens. Furnizor de servicii cu valoare adaugat (Value chain service provider) ofer diferite funcii specifice din cadrul lanului de aprovizionare al unei firme. Astfel de funcii sunt logistica, plata electronic, etc. Plata acestor servicii se face pe baza unor tarife sau a unei cote procentuale. Brokeraj de informaii (information brokerage) ofer consumatorilor i vnztorilor informaii cataloage de clieni clasificai pe profil, vnzarea de oportuniti de afaceri, consultan n domenii specializate asistndu-i n decizia de cumprare. Serviciile Internet diversificate adaug valoare volumului de informaii existent prin: furnizarea unor cataloage de clieni, clasificai pe profile; vnzarea unei oportuniti de afaceri; sfaturi pentru investiii; consultan n diferite domenii specializate; servicii de ncredere furnizate de autoritile de certificare sau de notariatele electronice; nfiinarea unor uniti i agenii de cercetare care ncearc s creeze mecanisme de detectare semantic (semantici WEB, ageni inteligeni, ontologii,etc); serviciile de informare, care se bazeaz pe experiena uman, respectiv experi n domeniu, rmn n continuare servicii de importan vital pentru lumea afacerilor (knowledge management). Aceste servicii comerciale sunt desfurate contra cost n mare parte, fie n baza unui sistem de abonament, fie prin intermediul banilor electronici de tipul e-cash sau cybercash. Au fost nfinate uniti i agenii de cercetare care ncearc s creeze mecanisme de detectare semantic, dar serviciile de informare care au la baz experiena uman, respectiv experi n domeniu rmn n continuare servicii de importan capital pentru lumea afacerilor. Servicii de securitate(trust services) sunt serviciile care certific calitatea produselor sau serviciilor oferite de firmele care acioneaz pe piaa electronic. Un exempul de astfel de servicii sunt oferite de TRUSTE (www.truste.org )
98
3.6. Caracteristici ale comerului el ectronic

Comerul electronic poate fi implementat la o multitudine de niveluri, ncepnd de la o simpl prezen pe reea i terminnd cu suportul pentru afaceri distribuite la mai multe firme, putndu-se observa diferene ntre tranzaciile naionale i cele internaionale, ale cror cauze nu sunt de natur tehnic ci, mai de grab, de natur legislativ. Comerul electronic este mai complex la nivel internaional datorit unor factori diveri: sistemul de impozitare, legea comercial, taxe vamale, diferenele dintre practicile bancare, etc.La nivelurile mai simple firma se preocup de prezena pe reea de promovarea imaginii firmei i de asistena pre i postvnzare, folosind tehnologii deja existente i testate, care sunt uor de implementat i implic costuri minime dar acesta nu reprezint un real comer electronic. Comertul electronic, n concepia Organizaiei Economice de Cooperare i Dezvoltare (OECD), reprezint desfaurarea unei afaceri prin intermediul reelei Internet, vnzarea de bunuri i servicii avnd loc offline sau online. n tranzaciile comerciale clasice distingem patru etape diferite: informarea comercial referitoare la tranzacie: cercetarea de marketing; ncheierea contractului comercial; vnzarea produsului sau a serviciului; plata produsului sau a serviciului. Multe organizaii care au implementat sisteme de comer electronic au ajuns la concluzia c cele mai mari probleme apar nu la pregtirea ordinelor de cumprare i livrare, ci la selectarea i identificarea partenerilor de afaceri. Pentru aceasta este necesar accesarea unor baze de date cu produse i servicii care pot fi achiziionate, precum i cu furnizorii diferitelor categorii de bunuri. Aceste baze de date sunt echivalentul pe Internet al cataloagelor de tip Pagini aurii i sunt denumite nomenclatoare electronice. Diferii utilizatori pot folosi criterii diverse pentru cutrile lor n aceste nomenclatoare, funcie de numele productorilor, sau numele exact al produsului dar majoritatea dein doar o descriere generic a produsului sau a unui standard internaional pe care bunul solicitat trebuie s-l respecte. Multe firme descoper c nomenclatoarele, datorit bunei structurri i funcionaliti, asigur avantaje concurenale importante. O utilizare special a nomenclatoarelor o constituie nregistrarea contractelor pe care o organizaie de mari dimensiuni le ncheie cu furnizorii si, caz n care toi achizitorii din cadrul organizaiei pot cumpra n baza acestor contracte, utiliznd clauze i condiii predefinite. Exist o mare varietate de moduri n care cumprtorii i vnztorii se pot ntlni i n care se poate derula negocierea preurilor, calitii, condiiilor de livrare i de transport. Unul dintre principalii factori care determin forma de ncheiere a contractelor o reprezint categoria de bunuri i servicii care fac obiectul tranzaciei: produse, mrfuri fungibile, bunuri i servicii proiectate la comand, produse i servicii adaptate etc. Comertul electronic reprezint o posibilitate de expandare a oportunitilor de afaceri, mbogirea de noi piee, mergnd dincolo de graniele li limitele fizice a pieei, pentru a ajuta afacerile, de a realiza noi valori tangibile i cuantificabile n afacere. E-commerce-ul furnizeaz un acces interactiv i comod n ntreaga lume, cu informaii de profunzime, incluznd disponibilitatea produselor, de a ajuta clienii s fac i mai rapid deciziile de cumprare. Aceasta, pn la urm, ajut la accelerarea ciclului vnzrilor. E-commerce poate ajuta afacerile s-i reduc costurile prin mbuntirea eficienei procesrii comenzilor, reducerea costurilor inventarilor i depozitelor i reducnd costul actual al unei vnzri E-commerce este mai mult dect deschiderea unei canal de vnzare online. Ea nseamn utilizarea tehnologiilor pentru fuzelarea modelului de afaceri, obinerea economiilor, i creterea eficienei, ea nseamn reducerea costurilor i stabilirea unor relaii mai strnse i sensibile cu clienii, furnizorii i partenerii. B2C, adic Business-to-Consumer este aplicat n orice afacere sau organizaie care i vinde produsele i serviciile consumatorilor prin Internet, pentru utilizare proprie, pentru consum. n adiie la vnzarea n detaliu online, B2C include servicii bancare, de transport, de licitaie, de sntate. Business to Business nseamn cumprarea i vnzarea online ntre companii, incluznd managmentul canalelor de aprovizionare, respectiv cazul n care mai multe companii mpart canalele de aprovizionare cu partenerii lor de afaceri. B2B poate economisi banii unei companii.prin ci specifice care includ: guvernarea mai eficient a inventarului, reglarea mai rapid la cererile clienilor, oferirea mai rapid a
99
produselor pe pia, reducerea sau eliminarea cheltuielilor presupuse de lucrul cu documente manuale (hrtia), obinerea preurilor mai sczute a stocurilor.
3.7. Componentele comerului electronic

n cazul comerului electronic, se ntlnesc aceleai componente ca i n cazul comerului clasic, dar care au caracteristici specifice i anume: produsul - material sau digital; locul de vnzare - un website pe Internet, care prezint produsele sau serviciile oferite; modalitatea de a atrage potenialii clieni s viziteze un anumit site; modalitatea de a primi comenzile, reprezentat de un formular on-line, cu legtur direct la baza de date a firmei; modalitatea de a ncasa contravaloarea serviciilor sau produselor n care se poate folosi i metoda clasic a facturrii, on-line sau prin pot sau varianta modern printr-un cont bancar, cu pli prin card de credit, sau alte modaliti electronice de plat. Acestea solicit o soluie sigur pentru preluarea i gestionarea comenzilor i conexiunea la o banc prin sisteme de securitate ale tranzaciilor. modalitatea de livrare clasic sau direct prin reeaua Internet dac marfa este intangibil (software, muzic, informaie, etc); modalitatea de a accepta retururi de mrfuri gestionate de formulare on-line legate la aplicaia server; modalitatea de acceptare a eventualelor reclamaii obinute tot prin formulare on-line; modalitatea de service prin email, formulare on-line, baze de cunotine on-line etc.. Exist o singur diferen major ntre B2B i B2C -clienii. In B2B clienii sunt alte companii, iar n B2C clienii sunt persoane fizice. Aceasta determin alte implicaii deoarece n general tranzaciile B2B sunt mai complexe i necesit un nivel mai nalt de securitate. Pe lng acest aspect, n proiectarea i realizarea aplicaiilor de e-commerce apar dou elemente eseniale:negocierea i sintetizarea. Vnzarea ctre o alt firm implic o serie de negocieri asupra preurilor, condiiilor de livrare i specificare a produselor. n cazul aplicaiilor B2C negocierea nu are loc, ceea ce faciliteaz crearea cataloagelor de produse. n cazul vnzrilor n detaliu nu este necesar integrarea cu sistemul clienilor dar sintetizarea i integrarea sunt cerine eseniale n B2B. Caracteristicile aplicaiei fiecrui partener care particip la comerul electronic i fluxul informaional dintre acetia sunt elementele de baz necesare pentru realizarea unei aplicaii de comer electronic. Implementarea unei aplicaii pentru comerul electronic prin Internet, trebuie s in cont de modalitile de plat existente, cunoscut fiind faptul c majoritatea acestor tranzacii se fac prin intermediul crilor de credit, pentru realizarea operaiilor de vnzare-cumprare. Dup publicaia eMarketer produsele care se vnd cel mai bine prin e-comer sunt: tehnic de calcul (hardware, software, accesorii); cri; muzic; divertisment; servicii financiare; electronic de uz casnic; cadouri i flori; servicii turistice; jucrii; bilete pentru spectacole i cltorie;informaii. E-commerce include: Prezentarea electronic a produselor i serviciilor; Preluarea on-line a comenzilor i a notelor de plat; Informaii despre contul clientului obinute n mod automat; Plata on-line; Furnizarea automat de soluii de management. Companiile care realizeaz afaceri cu alte companii (B2B), trebuie s fie siguri c pot comunica ntre ei fr intervenie uman. La realizarea aplicaiei se au n verdere cei trei parteneri: vnztorul, cumprtorul i intermediarul (aquirer gateway), care se ocup cu asigurarea securitii informaiilor crii de credit pe Internet.
3.8. Arhitectura de baz

In prezent exist numeroasele modele de derulare a afacerilor pe Internet pot fi clasificate n funcie de numrul de furnizori, prestatori de servicii ctre clieni, astfel:
100
e-shop (1-ctre-1); e-mall (mai muli-ctre-1); e-licitaie (mai muli-ctre-mai muli). Apare astfel, un lan de servicii n cadrul cruia fiecare participant poate fi dominant, respectiv: 1. furnizorul de produse sau servicii; 2. furnizorul de servicii Internet, care poate pune la dispoziie de la spaiu pe pagina web pn la posibilitatea integrarii ntr-un e-mall; 3. clientul, cu o anumit formare profesional, interese proprii i preferine. Acest client poate fi un consumator (B2C), o alt firm (B2B), administraia public (B2G) sau un angajat (B2E), analiznd contextul tranzaciilor interne din cadrul unei firme. Cele mai rspndite modele de afaceri pe Internet vor fi tratate n detaliu. Majoritatea site-urilor de comer electronic de tip B2C utilizeaz modelul magazinului virtual, astfel nct se impune o cercetare amnunit a acestuia. Magazinul virtual reprezint o transpunere n spaiul virtual al unui magazin care ofer clienilor si diferite produse. n funcie de procentul din afacerea fizic transpus n spaiul virtual putem identifica mai multe tipuri de magazine virtuale. Magazine care prezint n cadrul site-ului catalogul de produse al firmei. Magazine care ofer pe lng catalogul de produse i posibilitatea comenzii online prin utilizarea unui co de cumprturi. Magazine care ofer catalog de produse, co de cumprturi i posibilitatea plii online cu ajutorul crii de credit sau al portofelului digital. Tehnologia co de cumprturi Una dintre cele mai des folosite tehnologii de implementare e-commerce este coul de cumprturi. Aceast tehnologie de procesare-comand permite clienilor s acumuleze produsele sau servicii pe care vor s le achiziioneze pe msur ce continu s cumpere. Tehnologia coului de cumprturi este un catalog de servicii care ofer posibilitatea alegerii unui produs i introducerea lui n cadrul unui formular de comand. Clientul are posibilitatea modificrii acestei comenzi pe parcursul ntregii sesiuni de cumprturii, adic s adauge produse n co, s modifice cantitatea comandat, s elimine un produs din co n orice moment. Coul de cumpraturi poate fi vizualizat pe ntreg parcursul procesului de cumprare. Comanda este apoi validat, clientul i introduce datele de contact :adres, cod potal, telefon, fax, email, iar n cazul n care este posibil realizarea plii online, se introduc datele referitoare la cartea de credit. Procesul de achiziionare a produselor online prin intermediul unui magazin virtual pot fi sintetizate prin figura de mai jos, n care operaiile realizate sunt mprite n activiti anterioare comenzii i activiti realizate dup procesarea comenzii. Pentru a construi un sistem de comer electronic, din punct de vedere arhitectural este nevoie de colaborarea a patru componente (subsisteme electronice/informatice) corespunztoare urmtoarelor roluri: Client. Un echipament, clasic un PC, conectat direct (via un ISP) sau indirect (o reea a unei corporaii) la Internet. Cumprtorul folosete acest echipament pentru a naviga i a face cumprturi. Comerciant. Sistem informatic (hard & soft), situat de regul la sediul comerciantului, care gzduiete i actualizeaz catalogul electronic de produse disponibile a fi comandate on-line pe Internet. Sistemul tranzacional. Sistemul informatic (hard & soft) responsabil cu procesarea comenzilor, iniierea plilor, evidena nregistrrilor i a altor aspecte de business implicate n procesul de tranzacionare. Dispecer pli. (Payment Gateway). Sistem informatic responsabil cu rutarea instruciunilor de plat n interiorul reelelor financiar-bancare, cu verificarea crilor de credit i autorizarea plilor; acest sistem joac rolul unei pori care face legtura dintre reeaua global Internet i subreeaua financiar-bancar. Indiferent de tipul de afacere abordat n cadrul aplicaiilor de comer electronic apar trei componente majore: aplicaia cumprtor, aplicaia vnztor i aplicaia intermediarului.
3.9. Managementul relaiei cu clienii

Legtura dintre clieni i departamentele unei companii nu este posibil dect prin intermediul unui software specializat destinat managementului relaiilor cu clienii (Customer Relationship Management-CRM). Acesta urmrete toate aspectele relaiei pe care o firm le poate avea cu clienii 101
si: interaciunea cu acetia, produsele cumprate, problemele care pot aprea la un moment dat. La nivelul Internetului, CRM-ul transformat n e-CRM folosete tehnologia Web pentru a comunica n interior, ntre departamente i clieni. Cele mai complexe sisteme de e-CRM sunt cele produse de ctre firma GoldMine Software Corporation, Commence Corp, i MultiActiv Software. Aplicaiile de acest gen trebuie s conlucreze cu servere bazate pe SQL n cazul operaiilor de amploare. Liderul n domeniul sistemelor de e-CRM este Siebel System, al crui software este utilizat de ctre IBM. Sistemele oferite de ctre Siebel permit personalizarea, rspunsul automat la e-mail-uri, un portal Web i realizarea de planuri de e-marketing. Un alt lider al pieei este Oracle, care utilizeaz e-CRM pornind de la nucleul sistem ERP (Enterprise Resource Planning - gestiunea intreprinderii). Astfel, in aceste sisteme, CRM asigur interaciunea cu clienii, iar ERP infrastructura de gestiune a firmei. Oferta de e-CRM este extrem de variat, existnd soluii i pentru firmele mici i mijlocii. Produsele e-CRM majore sunt adevrate medii de dezvoltare, cu instrumente specializate destinate personalizrii sistemelor. Cheia succesului n e-business o reprezint posibilitatea Web site-ului de a interaciona cu clienii i de a le acorda acestora oferte i informaii personalizate. Direciile de dezvoltare ale e-CRMului sunt estimate de firma IBM prin: utilizarea Internetului pentru a comunica direct cu clienii; posibilitatea cunoaterii preferinelor clienilor i gsirea unor soluii individuale pe baza unor studii realizate direct online; anticiparea produselor/serviciilor cutate de client; o mai bun interdependen ntre departamentele i diviziunile firmei. Satisfacerea consumatorilor nu este suficient, scopul CRM este obinerea loialitii clienilor, prin personalizarea produselor/serviciilor la adresa clienilor n funcie de preferinele, necesitile sau problemele fiecruia. Procesul obinerii loialitii consumatorilor este un proces concentrat pe consumator, cuprinznd trei pai: achiziia, dezvoltarea i meninerea clienilor. Pentru achiziie, e-business ofer consumatorului un acces consistent la firm n orice moment, oriunde i independent de platform. Clienii sunt dezvoltai n momentul n care compania furnizeaz servicii personalizate. Informaiile despre utilizatori pot fi manipulate pentru a oferi o selecie personalizat de produse i servicii. Rspunsurile date clienilor trebuie s fie cultivate i meninute tot timpul personalizate, pentru a susine un proces consistent i repetabil.
3.10. Managmentul liniei de aprovizionare

E-business schimb modul n care ntreprinderea comunic i conduce afacerile cu furnizorii, distribuitorii i clienii si. Modul n care aceti actori sunt legai este determinat de managementul liniei de aprovizionare iar companiile utilizeaz aceast tehnologie pentru a ajuta comunicarea i colaborarea cu partenerii de afaceri. Managementul liniei de aprovizionare ajut la obinerea unor rspunsuri la ntrebrile de cheie n afaceri, de exemplu unde exist surse de materiale prime i auxiliare sau subansamble, determinnd cel mai eficient furnizor, de a nelege logistica de transport, determinarea celei mai bune locaii pentru sedii sau centre de distribuie i iniierea de cereri de prognostic i planificare. Soluiile oferite de IBM pentru managementul liniei de aprovizionare ajut la livrarea produsului potrivit, la locul potrivit, n timpul potrivit i la cel mai mic cost. Beneficiul nfiinrii unei legturi active cu furnizorii i clienii este semnificativ pentru: mbuntirea serviciilor oferite clienilor cu livrri rapide i de ncredere. reducerea pierderilor prin liniile de inventar, reduceri de pre i o utilizare mai bun a resurselor. accelerarea creterii afacerii care conduce la victorie pe pia, n pstrarea clienilor, creterea vitezei de cumprare i servicii mai bune pentru clieni. Soluiile de management a linei de aprovizionare conduc la creterea randamentului i la satisfacia clienilor. IBM i partenerii selectai, furnizeaz un suport capt la capt, incluznd planificarea cererilor, aprovizionarea continu, logistica de transport i modelarea pe calculator a variabilelor liniei de aprovizionare. IBM este situat n centrul unuia dintre cele mai mari linii de aprovizionare din ntreaga lume i este capabil s transfere aceste experiene pentru a ajuta clienii. Principalele produse de modelare a aplicaiilor e-business pentru managementul liniei de aprovizionare sunt Lotus Domino i MQ Series. Aceste produse includ servicii e-commerce i produse pentru suportul de tranzacii rapide i fr probleme. 102
3.11. Modaliti de plat - Contul de comerciant

Contul de comerciant este total diferit de conturile bancare obinuite, utilizate n afacerile tradiionale. El permite realizarea de pli prin cri de credit sau de debit ca form de plat electronic de la clieni. Un cont de comerciant, implic existena unui numr de identitate (Merchant ID) i a unui terminal la punctul de vnzare (point of sale terminal - POS). Un terminal de acest fel (POS) poate comunica prin intermediul liniilor telefonice, asemntor unui fax. Prin acest terminal se citesc i se nregistreaz informaiile despre consumator de pe banda magnetic a unei cri de credit sau de debit. Dup procesarea acestor informaii POS trimite informaiile i detaliile tranzaciei ctre institutiile autorizate s proceseze plata (VISA, AMEX, MASTERCARD etc. sau la banca emitent, dac este vorba de o carte de debit). Acestea rspund cu informaia dac fondurile/creditul existent sunt suficiente efecturii plii i autorizeaz sau declin tranzacia. n situaia n care comunicarea la terminalul POS nu este posibil din diverse motive (ex. ntrerupere temporar), tranzacia poate fi totui procesat manual la un numr de telefon gratuit (1-800). Un cont de comerciant care poate procesa tranzacii i prin Internet se distinge prin aanumitul cont de comerciant de tip MOTO (mail order / telephone order). Un fapt puin cunoscut i respectat este acela c procedura legal n tranzaciile prin Internet este s se expedieze produsul ctre destinatar, nainte de ncasarea sumei corespunztoare de pe cartea de credit/debit a clientului. n mod evident, autorizarea ncasrii este obinut ns nainte de expedierea produsului, pentru a avea confirmarea ca exist fonduri disponibile i a elimina riscurile n caz de furt. Transferul bancar are loc numai dup ce produsul este n drum spre consumator. Furnizorul contului de comerciant poate influena alegerea sistemului de shopping cart. n cazul tranzaciilor n timp real care ofer i palta online, este necesar ca formularul de plat s poata fi legat la serviciile de autorizare oferite de furnizorul contului de comerciant. Dac nu este posibil, cumprtorul va fi pus fi n situaia de a nu putea procesa tranzaciile, nici mcar manual. De aceea, este absolut necesar verificarea sistemelor de shopping cart care accept furnizorul contului de comerciant. n aceste condiii cunoaterea acestor detalii pot influena semnificativ tipul de afacere electronic pentru care o anumit firm opteaz. Sistemele electronice de pli Sistemele electronice de pli trebuie s ating nivele ridicate de securitate, vitez, caracter privat i confidenial, descentralizare i internaionalizare i s fie unanim acceptate de comerciani i oameni de afaceri. O trstur comun a majoritii acestor soluii o constituie utilizarea tehnicilor criptografice care asigur confidenialitatea, autenticitatea i integritatea mesajelor transferate ntre entitile implicate. n aceste sisteme sunt implicate, n general trei pri care interacioneaz ntre ele, i anume: o banc, un cumprtor i un vnztor. Un sistem electronic de pli43 este alctuit din dou nivele care sunt:[Roca_2004] 1. nivelul utilizator care cuprinde mulimea tuturor utilizatorilor i a tranzaciilor care au loc ntre acetia. Utilizatorii sunt mprii n trei grupuri, n funcie de modul n care acetia interacioneaz ntre ei n cadrul unei tranzacii. Aceste grupuri sunt cumprtorii, vnztorii i bncile. 2. nivelul sitem care cuprinde mulimea entitiilor fizice i a relaiilor care se stabilesc ntre ele. Entitile pot ndeplini unul din urmtoarele roluri: purttor de bani electronici sau registru de cas.
43
www.softnet.ro/library/files/papers/Introducere_in_Comert_electronic.pdf: 103
Emitent reali
bani
Emitent bani electronici 6.Bani electronici 7.Bani reali 4.Bani electronici Vnztor 5.Produse, servicii
1.Deschidere cont, bani reali
2.Bani reali 3.Bani electronici
Cumprtor
Arhitectura unui sistem de pli electronice Arhitectura unui sistem electronic de pli poate fi reprezentat grafic ca din figura 4.11. i acest sistem electronic de pli poate folosi urmtoarele modalitti de plat 44 cartela inteligent (smartcard) care este un cip ncorporat ntr-o cartel de plastic. Spre deosebire de o catel de credit obijnuit, un smartcard dispune de un microprocesor. Comunicarea cu punctul de acces se face printr-un contact direct cu dispozitivul specializat n citirea cartelelor iar cumprtorul nu are acces la instrumentele soft i hard ale dispozitivului de citire a cartelei fapt ce confer un plus de siguran bncilor. portofelul electronic cu observator care este alctuit din dou calculatoare; unul aparine clientului, prin care acesta comunic cu punctul de acces al sistemului de pli electronice, iar cellalt aparine bncii, fiind ncorporat n cel al clientului, i care previne dubla cheltuire a banilor electronici. punctul de vnzare (POS) care este folosit de ctre vnztor pentru a stoca temporal banii electronici. distribuitorul de bani electronici este un dispozitiv prin care se ncarc bani electronici n portofelul electronic al cumprtorului. Acesta distribuitor are mai multe forme: - distribuitor cont-bani electronici care permite incrementarea valorii din portofel, pe baza retragerii unei sume de bani reali din contul deschis de cumprtor; - distribuitor carte de credit-bani electronici care permite incrementarea valorii din portofel pe baza creditrii cumprtorului de ctre o cas de credit; - distribuitor numerar-bani electronici permite incrementarea valorii din portofel prin colectarea de la cumprtor a unei sume cash. Mijloacele de plat folosite n comerul electronic sunt:cecul on-line, ordinul de plat, plata la ramburs, plata prin card de credit, plti mobile (m-payment), etc Cecul on-line care este un nscris cu ajutorul cruia o persoan d ordin unei bnci s plteasc o sum de bani beneficiarului. Cecul este una dintre cele mai nesigure modaliti de plat, din cauza faptului c legislaia din ara noastr nu prevede o metod simpl de recuperare a banilor n cazul n care cumprtorul emite un cec fr acoperire. n ciuda acestui dezavantaj, exist la ora actual un numr destul de mare de magazine virtuale care accept i folosesc acest mijloc de plat on-line. Ordinul de plat care este emis de pltitor i este adresat bncii deintoare a contului su. Prin intermediul ordinului de plat, pltitorul cere bncii la care are deschis un cont, s plteasc o sum determinat unui anumit beneficiar. Ordinul de plat este cea mai utilizat metod de plat n Romnia, mai ales n tranzaciile ntre persoane juridice. Plata ramburs care este un sistem de expediere a mrfurilor, conform cruia destinatarul este obligat s achite la primire, expeditorului, contravaloarea mrfii. Principalele dezavantaje ale acestui sistem sunt date de valoarea limitat a tranzaciilor, iar pentru comerciant lipsa unei garanii c destinatarul va ridica i plti marfa. Aceasta este cea mai rspndit metod n comerul electronic romnesc, datorit rspndirii reduse a crilor de credit sau de debit. Plata prin cardul de credit Sistemul de cri de credit a fost creat n scopul de a-i permite cumprtorului s-i satisfac nevoia de cumprare de bunuri i servicii, chiar dac nu dispune la un anumit moment de banii necesari. Prin folosirea crii de credit, riscul este transferat de la vnztor la instituia financar care a emis credit card-ul. Plata prin cardul de credit se face astfel:
44
www.softnet.ro/library/files/papers/Introducere_in_Comert_electronic.pdf: 104
1. cumprtorul prezint vnztorului cartea de credit; 2. vnztorul trimite numrul crii de credit i detaliile tranzaciei la un sistem de autorizare; 3. sitemul de autorizare poate, fie s autorizeze direct tranzacia fie, s o direcioneze la banca emitent a crii de credit pentru aprobare; 4. la anumite intervale de timp vnztorul trimite detaliile tranzaciilor aprobate spre banca sa; 5. dup ce tranzaciile, pentru care banca respectiv este i colectoare i emitoare de cri de credit, au fost procesate, aceste informaii sunt transmise la asociaia emitorilor de cri de credit 6. la sfritul lunii, cumprtorul primete facturile pe care trebuie s le achite, astfel va plti dobnda pentru creditul acordat de banca ce a emis cartea de credit. Bibliografie modul: BUCHMANN ROBERT, Conceperea, proiectarea i realizarea afacerilor pe Internet, Ed. Risoprint, Cluj Napoca, 2004; RUSU L., ARBA R., BREFELEAN P., MUREAN L., BUCHMANN R., VERE O Modele de afaceri pe Internet, Ed. Risoprint, Cluj-Napoca, 2007 ROCA, GH.I et al., Comer electronic-Concepte, tenologii i aplicaii, Editura Economic, Bucureti, 2004 Teste de verificare a cunotinelor Care sunt caracteristicile modelelor B2B, B2C, G2G, G2B, B2E, G2E? Care sunt caracteristicile modelelor e-recruitement, e-auction, e-marketing? Care sunt etapele derulrii unei tranzacii electronice?
105
Anexe
Bibliografie obligatorie
BUCHMANN ROBERT, Conceperea, proiectarea i realizarea afacerilor pe Internet, Ed. Risoprint, Cluj Napoca, 2004; BUCHMANN ROBERT, Rolul XML n interoperabilitatea sistemelor informatice pentru afaceri, Ed. Risoprint, Cluj Napoca, 2007; CRANE DAVE et al., AJAX in Action, Manning, 2005 CRANE DAVE et al., Prototype and Scriptaculous in Action, Manning, 2007 PHILIPS L.A., XML, Ed.Teora, 2001 ROCA, GH.I et al., Comer electronic-Concepte, tenologii i aplicaii, Editura Economic, Bucureti, 2004 RUSU L., ARBA R., BREFELEAN P., MUREAN L., BUCHMANN R., VERE O Modele de afaceri pe Internet, Ed. Risoprint, Cluj-Napoca, 2007
Bibliografie opi onal

CHAFFEY DAN, E-Business and E-commerce Management, Second Edition, Ed.Prentice Hall, 2004 HOLDENER ANTHONY, Ajax: The Definitive Guide, O'Reilly, 2008; RUSSELL MATHEW, Dojo: The Definitive Guide, O'Reilly, 2008; RUSU LUCIA, BUCHMANN ROBERT, Proiectarea i realizarea aplicaiilor Web , Ed. Risoprint, Cluj Napoca, 2003; BURAGA SABIN, BRUT MIHAELA, Prezentari multimedia pe Web. Limbajele XHTML+TIME si SMIL, Editura: Polirom 2004 GUGOIU TEODOR, HTML, XHTML, CSS si XML prin exemple - ghid practic, Editura Teora 2005
Glosar
Termeni cheie ai materialului de curs: AJAX - model de aplicaii Web din paradigma Rich Client, bazat pe DHTML i comunicarea asincron dintre client i server a unor structure de date de tip text (XML sau JSON). Analizor XML - Un program care verific buna formare a unui document XML (vezi buna formare); se poate considera c este att emitor, ct i consumator XML, fiind de obicei un program cu rol de intermediere. n unele situaii, poate s nu fie intermediar, ci doar s indice utilizatorului uman dac documentul este bine format sau nu 45. Aplatizare (Flattening) - Transformarea unui document XML prin reducerea numrului de nivele al arborescenei sale, de obicei prin crearea mai multor elemente i atribute direct n rdcin i pierderea unor relaii de subordonare ntre elemente. Metoda este util dac unicul scop al documentului este formatarea. Atribut XML - Component a unui marcator, poate s apar doar n eticheta sa de deschidere, are nume i valoare. Atributele sunt separate prin spaii. Valorile atributelor sunt delimitate cu ghilimele, care pot fi opionale n unele limbaje de marcare. Atribut de enumerare - Un atribut XML care este definit prin enumerarea valorilor sale posibile.
n unele traduceri din literatur termenii parser, validator i analizor pot apare ca sinonimi, deoarece n multe cazuri cele trei funcii sunt realizate de acelai program. Totui, din raiuni de performan, exist numeroase cazuri n care sunt folosite programe diferite pentru a realiza conversia codului surs pe de o parte (parser) i pentru a verifica buna formare i validarea, pe de alt parte (analizor + validator). 106
45
Atribut identificator - Un atribut XML de tip ID, utilizat la identificarea elementelor XML care au acelai nume. Poate servi i la construirea relaiilor ntre elemente, prin conectarea cu un atribut referin. Atribut referin - Un atribut XML de tip IDREF, care face trimitere la un alt atribut (de tip identitate) pentru a reflecta o relaie ntre dou elemente XML. Browser - Un program ce ofer instrumente de parcurgere a documentelor. Sunt consacrate browserele HTML care interpreteaz marcatorii HTML i transform codul surs n forma final, formatat, a unei pagini Web. Unele browsere au funcionalitatea extins pentru a permite afiarea i navigarea documentelor XML. Bun formare, document bine format (well-formed document) - Proprietatea unui document de a fi de tip XML, adic de a nu nclca regulile limbajului XML, este o proprietate ce trebuie verificat de ctre orice consumator XML (se recomand i emitorilor). Un document XML nu este obligatoriu s aparin unui vocabular, dar trebuie s fie bine format din punct de vedere sintactic. Un exemplu de regul de bun formare este imbricarea complet. Cale XML - O construcie de tip cale, care permite localizarea i identificarea elementelor ntr-un document XML tratat ca un arbore. Vocabularul standard XPath ofer regulile dup care se costruiesc aceste ci, dar se bazeaz pe metoda clasic de construcie a cilor absolute sau relative ale fiierelor. CDATA - Date de tip caracter ce vor constitui valori de atribute. Comentariu - Marcator special, de forma  care conine text ignorat n general de procesoare XML dar care pot ajuta un consumator uman s neleag mai bine semnificaia unor poriuni din document. Consumator XML - Sinonim cu receptor XML. CRM (Customer Relation Management) - sisteme informatice care gestioneaz relaia cu clientul; sunt caracterizate de faptul c modelele lor de date graviteaz n jurul clienilor - un identificator de client este suficient pentru obinerea unei cantiti mari de date relaionate (produse comandate, totalizri etc.) CSS - limbaj de definire a stilurilor, esenial n modelul AJAX Date de tip caracter - irurile de caractere care sunt coninute n elemente, deci care nu constituie marcatori XML. Se prefer denumirea de "date" pentru a accentua faptul c de obicei programele le trateaz ca uniti, ca date de tip text i nu ca succesiuni (stringuri) de caractere. Declaraia DTD - Sinonim cu invocarea DTD. Declaraia XML - Primul marcator din orice document XML, este o instruciune de procesare ce indic versiunea limbajului XML folosit i setul de caractere (UTF, ISO etc.) folosit n document. Depozit XML - Echivalentul unei baze de date XML: o colecie organizat de documente XML al cror scop este s stocheze cantiti mari de date. Deschidere (Start tag) - Exprimare prescurtat pentru eticheta de deschidere a unui marcator. Document - Fiier al crui scop este s pun la dispoziie informaie n diferite forme (date, text, imagini, sunet etc.). Documentele pot s conin i indicaii de prelucrare a coninutului sau metainformaii (informaii despre coninut). Sunt excluse din definiie fiierele care prelucreaz/transform informaia (aplicaii, programe, procesoare etc.), acestea fiind considerate consumatori sau generatori de documente. DOM (Document Object Model) - Un model de date i un tip de parsere care permit tratarea documentelor XML ca pe arbori i ofer metode de parcurgere facil a nodurilor acestora. Are dezavantajul c memoreaz ntreg arborele n memoria intern a consumatorului. DTD (Document Type Definition) - Un fiier (cu extensia .dtd) care conine regulile pe care trebuie s le respecte toate documentele ce fac parte dintr-un vocabular. DTD permite stabilirea de reguli privind marcatorii, dar nu ofer reguli privind informaia marcat. Element - Componenta de baz a unui document XML, format din marcator (care d numele i atributele elementului) i coninut (valoarea elementului). Element document - Elementul rdcin al unui document XML Element vid - Element XML fr coninut, deci este sinonim cu marcatorul vid. Marcatorul su poate fi scris n forma prescurtat, cu o singur etichet: <nume_marcator /> Emitor XML - O persoan sau un program care genereaz cod surs XML. Entiti analizabile - Valori, simboluri, blocuri de caractere sau chiar de marcatori care se declar n DTD, i pot fi apelate prin referin din orice document al vocabularului respectiv, n mod similar cu apelul de variabile sau proceduri. n particular, pot fi apelate i din DTD-ul n care au fost declarate. Pe scurt entitile analizabile sunt iruri de caractere reutilizabile, de orice dimensiune, de la un singur caracter la documente ntregi.
107
Entiti non-XML/neanalizabile (Unparsed entities) - Tipuri de informaie apelate n documente XML, dar care sunt neanalizabile din punct de vedere XML, deci valorile lor nu sunt formate din text brut, ci fac trimitere la variate tipuri de fiiere (imagine, sunet, fiiere Word etc.). Granularitate - Densitatea documentelor XML dintr-un depozit de date. Granularitate ridicat implic un numr mare de documente de dimensiune redus (uor de manevrat) n depozitul de date. Granularitate redus implic faptul c fiecare document acoper cantiti mari de date, ceea ce are de obicei consecina c sunt mai dificil de manevrat. Imbricarea complet - Regula de bun formare a documentelor XML conform creia orice element XML trebuie s fie coninut de un alt element, mai puin rdcina, care trebuie s fie unic. Aceast regul permite ca elementele unui document XML s poat fi reprezentate ca un arbore, model folosit de parserele de tip DOM. Imbricarea asigur existena relaiilor de descenden/apartenen ntre elemente (elementul tat conine elementul fiu). Imbricare (nesting) - Proprietatea elementelor de a se conine unele pe altele; aceasta se asigur prin faptul c ambele etichete ale unui element fiu sunt coninute ntre etichetele printelui su. Instan - De obicei sinonim cu obiectul, fiind obinut prin fixarea tuturor proprietilor unei clase. n context XML, o instan este un exemplu de document care respect regulile unui vocabular/limbaj. Instaniere - Un tip particular de specializare, prin care, dintr-o clas de obiecte cu proprieti generale se obine un obiect pentru care toate proprietile sunt specifice (fixate la valori precizate). Obiectul obinut se mai numete instan a clasei de la care s-a pornit. Se poate afirma c o clas este un timp complex de obiecte, ori c un obiect face parte dintr-o anumit clas. n context XML, orice limbaj/vocabular este o clas sau tip de documente iar documentele care respect regulile unui limbaj/vocabular sunt obiecte/instane ale limbajului/vocabularului. De aici provine i prescurtarea DTD - document type definition (definirea unui tip de documente). Instruciuni de procesare (Processing instructions) - Marcatori XML de forma <?marcator?> care adreseaz procesoarelor XML indicaii privind prelucrarea anumitor poriuni din document. Invocarea DTD - Marcator special, care apare imediat dup declaraia XML, n acele documente care trebuie validate fa de un vocabular DTD. Marcatorul precizeaz numele elementului rdcin i regulile DTD (sau fiierul extern din care pot fi consultate de ctre un validator). nchidere (End tag) - Exprimare prescurtat pentru eticheta de nchidere a unui marcator. JSON - sintax pentru structure de date alternativ sintaxei XML, considerat de performan superioar n schimburile de date client-server; Lizibilitate (Readability) - Posibilitatea de a parcurge i nelege coninutul unui document de ctre un utilizator uman, cu minim de efort. Lizibilitatea este afectat de formatare. Metalimbaj - Limbaj care permite crearea de sublimbaje. SGML i XML fac parte din aceast categorie de limbaje. Model arborescent (ierarhic) - Alternativ la modelul relaional, care propune stocarea datelor sub form de arbori. Acetia au avantajul c reflect relaii de incluziune/subordonare/apartenen ntre proprietile obiectelor descrise. Model relaional - Model consacrat de stocare a datelor sub form de tabele ntre care exist relaii (dependene) de diverse tipuri. Mulime deschis de date (Open set, Open world) - Expresie care prezint caracterul deschis al modelului XML: un element sau un atribut se creeaz doar atunci cnd exist o valoare pe care s o memoreze. Tot coninutul unui document XML se consider cunoscut, tot ce nu conine se consider necunoscut. Aceasta are consecina c nu exist valori NULL. Mulime nchis de date (Closed set, Closed world) - Expresie care prezint caracterul modelului relaional de a rezerva, la crearea structurii tabelelor, spaiu de memorie chiar dac anumite cmpuri vor conine valori NULL (necunoscute sau care nu vor fi introduse niciodat). Nod XML - Nod al unui arbore obinut prin convertirea codului XML (vezi parser, imbricare complet). Parserele convertesc n general fiecare element ntr-un nod. Exist parsere care convertesc i atributele sau entitile n noduri, caz n care nodurile XML vor avea diferite tipuri. Notaie - Un nume, de obicei o prescurtare, cu care se identific un tip de informaie neanalizabil (care nu trebuie tratat ca text brut) dar care poate fi referit n documente XML, prin atribute de tip entitate. Receptorul este responsabil cu identificarea aplicaiei cu care se va deschide informaia neanalizabil, pe baza identificatorului public care se precizeaz n notaie. Ocuren (Occurrence) - modul n care unui element i se permite s apar n cadrul printelui su: cel mult o dat, cel puin o dat, de oricte ori .a.m.d. Ocurena fiecrui element reprezint una din regulile care trebuie stabilite ntr-un DTD.
108
Parser XML - Un tip particular de procesor XML, i anume un program al crui scop este s converteasc cod surs XML n diferite modele de date, mai uor de procesat. Modelele cele mai frecvent folosite sunt DOM i SAX. Uneori, parserele asigur i procesul de validare. Parsing - Activitatea unui parser. n numeroase cazuri, include i activitatea analizorului. Mai rar (din raiuni de performan), include i activitatea validatorului. Picior de cioar (Crow foot) - metod grafic de reprezentare a relaiilor de tip 1 la 1, 1 la n etc., n cadrul modelului relaional, ntre tabelele unei bazelor de date. Plic XML (Envelope) - Elementul rdcin al unui document XML, dac acesta conine atribute care identific/descriu documentul, emitorul sau receptorul su. Procesor XML - Dei uneori este utilizat ca sinonim cu consumator XML, definiia procesorului este ceva mai restrns - se refer doar la acei consumatori care aplic procesri (transformri) codului surs XML. Aceasta elimin din definiie utilizatorii umani care citesc XML sau documentele care memoreaz XML, deci un procesor XML este un program care accept date de intrare n format XML. Productor XML - Un tip particular de emitor XML, care este responsabil i cu producerea codului surs, deci se exclud emitorii care doar intermediaz transferul de fiiere. Prolog XML - Sinonim cu declaraia XML. Raport - Un document formatat care prezint ntr-o form lizibil, estetic, coninutul unei surse de date (o baz de date, un depozit XML etc.) Receptor XML - O persoan, un document sau un program care este gata s primeasc cod surs XML. Redundana - fenomenul prin care anumite date se repet ntr-o baz de date. n modelul relaional, redundana este minimizat prin normalizare. n modelul arborescent, redundana fie se pstreaz, fie se elimin cu ajutorul atributelor referin. Referine entitate - Numele cu care sunt apelate entitile, sunt marcatori speciali de forma &marcator; (dac sunt apelate din documente) sau %marcator; (dac sunt apelate din DTD). Relaie de incluziune/subordonare/descenden/apartenen - Termeni sinonimi prin care se arat c un element XML este imbricat n alt element XML. n acest caz, se poate afirma c elementul din interior este inclus, subordonat c aparine sau c este un fiu fa de cellalt. SAX (Simple API for XML) - Un model de evenimente i un tip de parsere care trateaz documentul XML ca pe o succesiune de evenimente care au loc la citirea codului surs ca i text brut (vezi DOM, text brut). Are avantajul c folosete o fereastr de parsing, zon a memoriei interne prin care se deruleaz textul documentului, deci economisete memoria intern. Schema XML (XML Schema) - Are acelai rol cu un DTD, dar este mai puternic, oferind un numr suplimentar de reguli care controleaz att marcatorii permii de vocabular, ct i informaia ce va fi coninut n potenialele documente. O schem XML este construit cu limbajul standard XML Schema care este, la rndul su, un vocabular XML cu un scopul indicat aici. SGML (Standard Generalized Markup Language??) - Limbajul care a consacrat marcatorii de forma <nume marcator>, din care s-au dezvoltat, prin specializare, limbaje ca XML i HTML. Conform acestui tip de limbaje, tot ce apare ntre paranteze ascuite reprezint marcatorul, iar ce apare n afara acestora este informaia marcat. Spaiu de nume (Name space) - Metod de calificare a unor seturi de elemente sau atribute cu prefixe unice, ce permit validarea a diferite poriuni de document dup diferite vocabulare, identificate cu prefixele respective. Text brut (Plain text) - Text fr formatri, tratat de programe ca un flux de caractere, este starea nativ a codului surs XML. Validare - Procesul de verificare a unui document XML fa de un vocabular. Se realizeaz cu ajutorul unui validator cruia i se indic fiierul XML i fiierul care conine vocabularul. Validator XML - Un tip particular de procesor XML, i anume un program al crui scop este s verifice dac un document XML aparine unui sublimbaj XML, adic dac respect regulile unui vocabular XML dat. Vocabular - tip de document XML. Un vocabular indic toate regulile de construire a documentelor XML comunicate ntre un emitor i un receptor, poate fi considerat un contract ntre cele dou pri care comunic. Vocabularul poate fi impus fie de emitor, fie de receptor. Metodele clasice de construire a unui vocabular sunt DTD i schemele XML (vezi DTD, Schema XML). Un document XML nu trebuie obligatoriu s aparin unui vocabular, dar vocabularele asigur caracterul extensibil al XML, adic posibilitatea de a crea sublimbaje pentru diferite tipuri de probleme, cu proprii marcatori i propriile reguli, care s fie acceptate apoi de ctre toi cei implicai n problemele respective.
109
XML (Extensible Markup language) - Limbajul extensibil de marcare. Trsturile sale definitorii sunt: are suport pentru seturi de caractere internaionale; este extensibil, adic permite crearea de sublimbaje (vocabulare) specializate pe anumite domenii sau probleme, obinute prin stabilirea setului de marcatori acceptai i a regulilor de folosire a acestora este un limbaj de marcare a informaiei particularizat din SGML; este un standard acceptat universal de productorii de software, deci asigur portabilitatea datelor ntre platforme hardware sau software diferite;
Biografia titularului de curs

Lect. Dr. Buchmann Robert Andrei este lector la Catedra de Informatic Economic a Facultii de tiine Economice i Gestiunea Afacerilor, Universitatea Babe Bolyai, ncepnd din anul 2006. A obinut titlul de doctor n anul 2004, n domeniul Cibernetic i Statistic Economic, cu teza Contribuii la conceperea, proiectarea i realizarea afacerilor pe Internet, sintetizat n volumul cu acelai titlu publicat la Editura Risoprint n anul 2004, premiat cu premiul Consiliului Cercetrii tiinifice al Universitii Babe Bolyai. Este absolvent al programelor de masterat i licen n cadrul aceleiai faculti, absolvind secia de Informatic Economic. n anul 2006 a reprezentat facultatea la XML Summer School la Universitatea Oxford. Domeniile sale de expertiz sunt modelele de aplicaii Web pentru afaceri electronice, n special cele bazate pe XML, i managementul calitii software. n aceste domenii, a condus dou granturi ctigate prin competiie naional: grantul doctoral Cercetri legate de modelarea i implementarea comerului electronic (finanat de CNCSIS prin programul TD) i grantul postdoctoral Regndirea comerului electronic o abordare n sensul omogenitii (finanat de MCT prin programul CEEX).A participat ca membru n alte 10 granturi conduse de membrii catedrei, a publicat 2 cri de unic autor i capitole n alte 11 cri cu mai muli autori, precum i numeroase articole i comunicri la conferine din ar i strintate.
110

Suport Curs UIA

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Suport Curs UIA

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA BABE-BOLYAI, CLUJ-NAPOCA Centrul de Formare Continu i nvmnt la Distan Facultatea de tiine Economice i Gestiunea Afacerilor Specializarea: Informatic

Economic Disciplina: Utilizarea Internetului n Afaceri

Modulul III. Modele de afaceri pe Internet................................. 87 3. Categorii de afaceri pe Internet ............................................ 88

Anexe ..................................................................................... 106

Biografia titularului de curs .................................................... 110

Modulul I. Limbajul XML

Modulul I. Limbajul XML 1. Elemente introductive de XML

1. Elemente introductive de XML

Fruct Denumire Pret

Fruct Denumire Pret

<Fruct Denumire="Mere" Pret="10000"/>

<Fruct Denumire="Mere" />

1.2. XML i HTML

n timp ce HTML nu accept aceste forme i accept n schimb

1.3. Prelucrarea informaiilor XML

1.4. Validarea informaiilor XML

1.5. Sintaxa XML

Forma sa extins precizeaz o serie de date opionale:

<!DOCTYPE NumeElementRadacina [descriere DTD intern]>

<!DOCTYPE NumeElementRadacina SYSTEM Cale/URL>

Un parser DOM va crea din acest exemplu urmtoarea ierarhie de noduri:

Character Data Text Node

1.7. Vocabulare XML orientate spre afaceri

sursa: Stephen Mohr, Connecting e-commerce to XML, Wrox Conferences, 2002 23

Exemplul este preluat dup http://www.xml.com/pub/a/2004/03/10/xbrl.html 26

Modulul II. Modelul AJAX

Modulul II. Modelul AJAX 2. Paradigma Rich Client i modelul AJAX

2. Paradigma Rich Client i modelul AJAX

Clic pe adresa scriptului server pentru afiarea datelor transferate

Butonul de deschidere a consolei Firebug

2.2. Fundaia AJAX 2.2.1. JavaScript

este echivalent cu:

2.2.2. XML i DOM

...acestea trebuind convertite la

n continuare vom utiliza forma XML pentru marcatorii cu etichet unic 39

Va duce la un arbore de forma:

2.2.3. XML DOM versus HTML DOM

2.2.4. Obiectul XHR

5. Utilizarea datelor de la server

</tr> </table> </form> </body> </html>

2.2.5. Cadrele interne invizibile

client-server indiferent de calea pe care sunt realizate, inclusiv prin cadre.

</tr> <tr> </tr> <tr> </tr> <tr>

</tr> </table> </form> </body> </html>

2.3. Platforme i biblioteci AJAX 2.3.1. Rolul platformelor AJAX

2.3.2. Comunicarea cu serverul prin pachetul Dojo

} else document.getElementById("Eroare").innerHTML="<font color=red>Eroare de conectare la server!</font>"

document.getElementById("Eroare").innerHTML= "<font color=red>Eroare de conectare la server!</font>"+raspuns

n continuare oferim i un exemplu de transfer a datelor prin metoda POST:

<td>CodPostal</td> <td><input type=text id=TXcodpostal name=cp onblur="date()"></td> <td></td> <td><input type=submit></td>

</form> <p id=confirmare></p> </body> </html>

print "La server au ajuns ".$_GET['v1']. " si ".$_GET['v2'];

descrierea valorile transmise serverului prin proprietatea content. Alternativa:

obiecttrimis={v1:...., v2:.....} obiectargument={url:....,handleAs:....,load:....,error:...., content: obiecttrimis} dojo.xhrGet(obiectargument)

descrierile de stil CSS sunt foarte asemntoare irurilor JSON:

.stil1 {proprietatecss1: valoare1; proprietatecss2: valoare2;....}

Valoare JSON atribuit unei variabile:

Practic o matrice nu este altceva dect un vector cu elemente vectori. 63

Urmtorul exemplu primete aceleai date n format XML, sub forma:

2.3.3. Comunicarea cu serverul prin biblioteca Prototype

</tr> <tr> </tr> <tr> </tr> <tr> </tr> <tr>

</tr> </table> </form> <p id=Eroare></p> </body> </html>

type=text id=TXcodpostal onblur='date(this.value)'></td>

</tr> <tr> </tr> <tr> </tr> <tr> </tr>"; ?>