Suport Curs UIA

5/12/2018 Suport Curs UIA - slidepdf.com

http://slidepdf.com/reader/full/suport-curs-uia 1/110

SUPORT DE CURS

ANUL III

Semestrul 2

Cluj – Napoca2010

UNIVERSITATEA BABEŞ-BOLYAI, CLUJ-NAPOCACentrul de Formare Continuă şi Învăţământ la Distanţă Facultatea de Ştiinţe Economice şi Gestiunea Afacerilor Specializarea: Informatică EconomicăDisciplina: Utilizarea Internetului în Afaceri



2

Informaţii generale

Date de identificare a cursuluiDate de contact ale titularului de curs:

Nume: Buchmann Robert AndreiBirou: 436, sediul FSEGATelefon: 40 + 0264-41.86.52/3/4/5Fax: 40 + 0264-41.25.70E-mail: [email protected]ţii: Luni 14-16, Marţi 14-16

Date de identificare curs şi contact tutori:

Denumirea cursului: Utilizarea Internetului înAfaceri Tutore: Lect.Dr. Buchmann Robert AndreiE-mail secundar: [email protected]

Condiţionări şi cunoştinţe prerechizite Cursul nu are condiţionări prerechizite. Cunoştinţele prerechizite care pot facilita asimilarea

materialului sunt legate de proiectarea siteurilor Web și stăpânirea limbajelor HTML, JavaScript și CSSla un nivel mediu. Sugerăm ca înainte de parcurgerea materialului să se identifice următoarele

cunoştinţele prerechizite: Concepte de bază: format, stil, hiperlegătură; Abilități legate de dezvoltarea Web: creare de stiluri, validare de formulare.

Descrierea cursuluiCursul 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 urmăreștefamiliarizarea cu tehnologiile ce stau la baza AJAX: JavaScript, DOM; CSS, XML, JSON și o serie debiblioteci de înaltă productivitate (Dojo, Prototype, Scriptaculous).

Datorită audienței țintă a cursului, primul modul va asigura fixarea sintaxei XML cu referințela cunoștințele prerechizite legate de limbajele de marcare și HTML , apoi se trece la dezvoltarea dedeprinderi practice în exploatarea tehnologiilor.

Tehnologiile vizate sunt de tip open-source și standarde WWW, fiind accesibile gratuitutilizatorilor și implicit studenților . Cursul trece în revistă și o serie de vocabulare XML strict orientatespre afaceri, precum XBRL.

Piaţa muncii din România pe domeniul Web indică o tendință de migrare dinspre siteurileclasice, Thin Client, spre siteurile bazate pe AJAX și XML. Primele două module ale cursului au uncaracter puternic tehnic, în timp ce ultimul model oferă o imagine sintetică asupra modelelor de afacerice pot avea de câștigat din implementările prezentate.

Organizarea temelor în cadrul cursului Ordinea temelor abordate de curs, conform structurii materialului didactic ce va fi disponibilă

pe platf orma software de învăţământ la distanţă: https://portal.portalid.ubbcluj.ro/

Modulul I. Limbajul XML1.1. Marcatori XML1.2. XML şi HTML 1.3. Prelucrarea informaţiilor XML 1.4. Validarea informaţiilor XML 1.5. Sintaxa XML1.6.Principiile DOM1.7. Vocabulare XML orientate spre afaceriModulul II. Modelul AJAX2. Paradigma Rich Client şi modelul AJAX 2.1.Introducere în AJAX2.2. Fundaţia AJAX 2.3. Platforme şi biblioteci AJAX

2.4. Interfaţa cu utilizatorul Modulul III. Modele de afaceri pe Internet3. Categorii de afaceri pe Internet

https://portal.portalid.ubbcluj.ro/






3

3.1. Concepte de e-afaceri3.2. Bariere în calea succesului comerţului electronic 3.3. Tipologia pieţelor electronice globale 3.4. Categorii de tranzacţii electronice 3.5. Modele de afaceri electronice3.6. Caracteristici ale comerţului electronic

3.7. Componentele comerţului electronic 3.8. Arhitectura de bază 3.9. Managementul relaţiei cu clienţii 3.10. Managmentul liniei de aprovizionare3.11. Modalităţi de plată - Contul de comerciant

Pentru paginarea temelor, recomandăm consultarea cuprinsului din partea a doua amaterialului de faţă.

Formatul şi tipul activităţilor implicate de cursCursul va fi prezentat prin activităţi tutoriale periodice programate conform orarului facultăţii .Prin adresele de e-mail oferite sau la sediul facultăţii, titularul şi tutorii cursului stau la

dispoziţia studenţilor pentru consultaţii on-line sau faţă în faţă în afara activităţilor periodice

preprogramate. Se încurajează studiile de caz legate de locul de muncă al acelor studenţi care sunt dejaangajaţi în domeniu.

Activităţile tutoriale sunt, pentru studentul la distanţă, facultative şi nu afectează nota acestuia,obţinută strict prin forma indicată: examen scris, lucrări de control și proiect practic. Totuşi, încurajăm

participarea interactivă la activităţile tutoriale în special pentru dezvoltarea incrementală a proiectuluipractic.

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 ROŞCA, GH.I et al., Comerţ electronic-Concepte, tenologii şi aplicaţii, Editura Economică,

Bucureşti, 2004 RUSU L., ARBA R., BREŞFELEAN P., MUREŞAN L., BUCHMANN R., VEREŞ O –

Modele de afaceri pe Internet , Ed. Risoprint, Cluj-Napoca, 2007

Materialele sunt accesibile la biblioteca facultăţii, la biblioteca catedrei sau pot fi puse la dispoziţie decătre titularul de curs.

Materiale şi instrumente necesare pentru cursLaborator 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 întâlniri preprogramate pe semestru, cu datele şi locaţiile afişate pe site-ulfacultăţii la începutul semestrului. Premergător fiecărei întâlniri se recomandă parcurgerea materialulu ide faţă, pe module pentru a asigura cursivitatea discuţiilor. Conţinutul acestor întâlniri va fi, în ordine:

Prima întâlnire – discuţii pe marginea modulului I; A doua întâlnire – discuţii 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ă:



4

Conţinut:

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ă Conţinut: Întrebări cu răspuns deschis, de dificultate şi pondere în notă echitabile (1 punct pe întrebare).

Evaluare continuă (teme și lucrări de control verificate în timpul semestrului) – 30% din notă

Nivelul minim pentru promovarea examenului este dat de obţinerea notei 5 la fiecare dinprimele două părţi (practic şi teoretic) și a mediei 5 pe ansamblu.

Primele două probe vor avea loc la datele programate pentru examen, la sediul facultăţii. Notele vor fi acordate în aceeaşi zi, comunicate personal fiecărui student cu posibilitate de contestareimediată.

Nu se vor accepta proiecte practice sau participări la examen la alte date decât celeprogramate.

Elemente de deontologie academică Tentativele de fraudare atât la examen scris cât şi în dezvoltarea proiectului practic vor fi

pedepsite prin anularea examenului şi aplicarea regulamentului instituţional. Nu este admisă în timpulexamenului utilizarea mijloacelor de comunicaţie.

Studenţi cu dizabilităţi E-mail de contact pentru situaţii deosebite şi suport acordat studenţilor cu dizabilităţi: [email protected] vor recomanda soluțiile de asigurare a accesibilității pentru persoanele cu dizabilități,

oferite de sistemul de operare Windows.

Strategii de studiu recomandateRecomandăm în ordine:

parcurgerea materialului de faţă şi contactarea tutorilor pentru orice nelămuriri; parcurgerea bibliografiei obligatorii; cercetarea individuală pe tema cursului, folosind Internetul; consultarea documentației și specificațiilor WWW ale tehnologiilor implicate.



5

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 informaţiilor XML................................................................. .................... 11 1.4. Validarea informaţiilor 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. Fundaţia 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. Interfaţa cu utilizatorul ................................................................................................. 74

2.4.1. Manipularea interfeţei cu utilizatorul prin biblioteca Prototype ........................... 75 2.4.2. Manipularea interfeţei 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 comerţului electronic......................................................... 92 3.3. Tipologia pieţelor electronice globale ................................................................. ......... 93 3.4. Categorii de tranzacţii electronice .............................................................. .................. 94 3.5. Modele de afaceri electronice .......................................................... ............................. 96 3.6. Caracteristici ale comerţului electronic .............................................................. ......... 99 3.7. Componentele comerţului electronic .......................................................... ................ 100 3.8. Arhitectura de bază..................................................................................................... 100 3.9. Managementul relaţiei cu clienţii ............................................................... ................ 101 3.10. Managmentul liniei de aprovizionare ....................................................................... 102 3.11. Modalităţi de plată - Contul de comerciant .............................................................. 103

Anexe ..................................................................................... 106 Bibliografie obligatorie .............................................................. ....................................... 106 Bibliografie opţională ........................................................................................................ 106 Glosar .............................................................................................................. .................. 106

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



6

Obiectivele generale ale cursului de faţă sunt date de detalierea următoarelor aspecte legate deproiectarea Web:

Fixarea terminologiei XML și a celei specifice aplicațiilor AJAX; Cunoașterea modelelor consacrate de afaceri pe Internet și a vocabularelor XML

orientate spre afaceri; Asimilarea cunoștințelor necesare realizării de pagini Web cu tehnologiile XML,

CSS și AJAX; Asimilarea deprinderilor practice în utilizarea depanatorului Firebug



7

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 informaţiilor XML 1.4. Validarea informaţiilor 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 cunoștințe privind vocabularele XML orientate spre afaceri

Recomandări

Angajarea studenților în verificare de exemple Se recomandă analiza studiilor de caz prezentate şi identificarea altora în sfera on-line Se recomandă discuții pe marginea trend-urilor din proiectarea Web

Rezultate aşteptate

Înțelegerea 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.



8

1. Elemente introductive de XML

1.1. Marcatori XML

Limbajul XML și vocabularele sale îşi propun să ofere în acelaşi timp posibilităţi de

formatare a documentelor, de structurare, de caracterizare semantică a informaţiei, precum şi deprocesare a lor. Astfel, există o ambiguitate generală legată de "care este scopul XML?" Răspunsul celmai corect este că scopul XML este cel pe care suntem capabili să i -l atribuim în calitate de receptori.XML are posibilităţi de exploatare nelimitate datorită faptului că este un metalimbaj. Aceastaînseamnă că standardul XML nu oferă un set fix de instrucţiuni ca limbajele obişnuite, ci oferă:

un set de reguli sintactice, regulile de bună formare, care trebuie respectate de oricedocument XML şi care impun structura pe care trebuie să o respecte orice marcator XML;

un limbaj auxiliar, Document Type Definition (DTD), care permite definirea altorlimbaje (vocabulare), prin pentru definirea instrucţiunilor acestora (marcatori, atribute) şia modului lor de utilizare.

Astfel, puterea XML nu este legată de crearea unor documente sau programe, ci de crearea devocabulare (limbaje de tip XML) cu marcatori şi atribute personalizate, cu care apoi se construiescdocumentele şi programele, în funcţie de scopul propus şi de potenţialii receptori. Dacă se urmăreştedistribuirea de documente XML către alţi utilizatori sau alte programe, trebuie ca regulile după care s -au construit marcatorii personalizaţi şi semnificaţia lor să fie aduse la cunoştinţa tuturor receptorilor 1.Aceasta necesită un efort suplimentar dar asigură posibilităţi nelimitate de personalizare şi dedistribuire între diferite platforme hardware şi software. Exemple de vocabulare XML consacrate suntMathML (limbaj de marcare matematic) şi CML (limbaj de marcare în chimie), specializate înformatarea şi structurarea datelor din domeniile respective (formule matematice, formule chimice), învederea utilizării lor de către specialişti sau programe specializate în domeniu. Alte exemple esenţialesunt o serie de vocabulare XML destinate chiar manipulării de documente XML: XS L permitetransformarea şi formatarea de documente, XLink permite relaţionarea marcatorilor din documenteXML iar XSDL permite chiar definirea de noi vocabulare XML, ca alternativă la DTD.

Nu trebuie să se înţeleagă că orice document XML necesită crearea în prealabil a unuivocabular. Se pot crea documente care respectă doar regulile de bună formare, folosind marcatori

oarecare, improvizaţi pentru nevoi imediate, ce nu au fost definiţi în prealabil de nici un vocabular. Încazul în care documentele sunt de uz intern, fără intenţii de distribuire pe scară largă, şi atunci când segarantează faptul că toţi receptorii documentelor vor fi pregătiţi să le prelucreze, se poate evitaconstruirea unui vocabular. În schimb, în contextul interoperabilităţii la nivel Web sau al organizaţiilor mari, în care documentele XML devin complexe şi sunt schimbate automat între emiţători şi receptoricare nu se cunosc în prealabil, crearea unui vocabular devine necesară ca bază contractuală pentruschimbul de informaţii într -o manieră consistentă şi fără ambiguităţi de interpretare.

Spre exemplu, putem construi un document XML cu următorii marcatori personalizaţi:

<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 afişării, dacă atribuim fiecărui marcator un stil2

1 În mod similar, datele unei baze de date sunt însoţite întotdeauna de structura sa (capul detabel) pentru ca sistemele de gestiune a bazelor de date (SGBD) să le poată înţelege şi prelucra.Reamintim regula generală: în comunicarea informaţiei, atât emiţătorul cât şi destinatarul trebuie săcunoască regulile după care marcatorii modifică forma, sensul sau utilizarea informaţiei.

2 Concept similar stilurilor Word: un stil este o mulţime de formatări de diferite nivele – font,paragraf, chenare – memorate sub un singur nume. Pentru ataşarea unor stiluri de formatare datelorXML se folose;te vocabularul XSL.



9

b. structurarea datelor în vederea stocării într -o bază de date relaţională; practic, exemplul de maisus poate reprezenta tabelul unei baze de date de forma:

Fruct Pret

Mere 10000

Pere 12000

Avantajul XML faţă de forma tabelară, consacrată de bazele de date relaţionale, este cămarcatorii imbricaţi pot indica relaţii de apartenenţă/subordonare (relaţii tată-fiu între datelemarcate), în timp ce câmpurile unui tabel se află doar într -o relaţie de alăturare.

c. trimiterea documentului spre programe capabile să trateze documentul ca pe un arbore dedate:

Fig. 1. Forma arborescentă a unei structuri de date XML

Flexibilitatea XML poate fi arătată prin faptul că documentul poate suferi transformări.Aceleaşi date ar putea fi prezentate în următoare formă, tot de tip XML, dar cu o structură de marcatoridiferită:

<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 operaţii de restructurare amarcatorilor, prin programe capabile să manipuleze arbori XML sau cu ajutorul limbajului specific detransformare - XSLT.

Raţiunile după care alegem modul de structurare a marcatorilor ţin de claritatea conţinutului pentru utilizatorul uman, de relaţiile de subordonare (tată-fiu) între date şi de optimizarea pentru procesare. În ce priveşte ultimul aspect, fişierele ar trebui să aibă dimensiune cât mai mică, pentrutransfer rapid în reţea. În plus se ştie că majoritatea programelor care procesează XML lucrează mai

rapid cu atribute decât cu marcatori, deci transformarea marcatorilor copii ai lui <Fruct> în atribute aleacestuia ar fi o alegere în sensul optimizării.

În ultimul exemplu mai apare un element de noutate, marcatorul vid, care nu are conţinutîntre etichetele sale de deschidere şi închidere. Acesta are un echivalent în HTML, la marcatorii care nuau ca rol delimitarea unei porţiuni de document (am exemplificat deja <img>,<br>). Pentru a micşora

efortul şi numărul de caractere în document, XML permite scrierea marcatorului vid fără etichetă de închidere, într-o formă care diferă de HTML prin prezenţa unu slash înaintea parantezei de închidere:

ListaFructe

Fruct

PretDenumire

Fruct

Denumire Pret

Mere 10000 Pere 12000



10

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

Unitatea fundamentală a unui document XML este elementul. Marcatorul dă numeleelementului, iar conţinutul delimitat de etichetele de deschidere şi închidere este considerat valoareasau conţinutul elementului. Această terminologie este general adoptată de toate instrumentele deprelucrare 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 atâta timp cât se păstrează relaţiile de subordonare/ apartenenţă3:

<Fruct>Mere</Fruct>

În acest exemplu putem afirma că avem: marcatorul <Fruct> cu conţinutul textual Mere elementul cu numele Fruct şi valoarea (conţinutul) Mere

sau, prin construirea unui atribut:

<Fruct Denumire="Mere" />

marcatorul vid (fără conţinut) <Fruct>, cu atributul Denumire ce primeşte valoarea Mere, elementul vid (fără valoare) cu numele Fruct, cu atributul Denumire ce primeşte valoarea Mere

Pentru a evita confuziile, în materialul de faţă se va apela la terminologia: elementul esteformat din:

marcator (care dă numele elementului) conţinut 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 excepţii de la această terminologie. Spreexemplu programele care tratează documentul XML ca pe un arbore de date separă conceptelevaloarea elementului şi conţinutul elementului. În astfel de cazuri, conţinutul unui element va ficonsiderat în arbore un nod fiu de tip frunză, care are valoare de tip text şi nu mai are nici un nod însubordine. Se va reveni la această problemă în situaţii concrete.

1.2. XML şi HTML

O comparaţie î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 formatărilor, XML pune accent pe construirea liberă de marcatori şi distribuirea structurii / semnificaţiei acestora între utilizatori sau programe diferite.

În particular, XML poate fi folosit pentru construirea unui vocabular de formatare similar cu

HTML cu marcatorilor personalizaţi în acest scop, de aceea se poate afirma că XML poate realiza toatefuncţiile HTML, dar nu se limitează la acestea. Vocabularele XML pot defini şi marcatori în altescopuri: instrucţiuni de procesare, descrieri semantice etc.

Desigur, elemente comune există, având în vedere că ambele limbaje sunt specializări aleSGML. Putem chiar afirma că HTML este mai puternic specializat decât XML având în vedere cămarcatorii lui au o destinaţie clară, fixă, nealterabilă şi acceptată la nivel global de orice browser la oraactuală. De aici s-ar putea trage concluzia că HTML poate fi considerat un vocabular XML, adică unlimbaj în care sensurile marcatorilor au fost deja fixate şi acceptate de orice partener care citeştedocumente HTML.

3 Dacă putem afirma că într -o imbricare un marcator fiu aparţine marcatorului părinte, se poate afirma şi că atributele unui marcator aparţin marcatorului.



11

Această afirmaţie este din punct de vedere tehnic falsă, deoarece cele două limbaje s -audezvoltat divergent spre obiective diferite. Motivul pentru care HTML nu este un vocabular XML estecă HTML conţine reguli pe care sintaxa XML nu le permite în vocabularele sale4:

Marcatorii XML obligatoriu trebuie să fie corect imbricaţi. HTML permite în unele cazuriimbricare incorectă, fără 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, aceştia doar seintersectează pe porţiunea centrală de text. XML nu permite o astfel de construcţie.

Marcatorii fără conţinut 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, valorileatributelor HTML se pot scrie şi fără ghilimele dacă nu conţin spaţii;

Marcatorii XML sunt case-sensitive, deci majusculele şi literele mici nu sunt echivalente, ca în HTML;

Există o serie de declaraţii care apar obligatoriu pe post de antet XML, care identifică undocument ca fiind de tip XML sau ca aparţinând unui vocabular XML. Aceste diferenţe ne indică şi regulile de bază în construirea de documente sau sublimbaje

XML şi definesc un concept esenţial: buna formare. Documentele bine formate (well-formed) suntcele care respectă aceste reguli sintactice în scrierea marcatorilor, reguli obligatorii în XML indiferentde semnificaţia, structura sau utilizarea fişierului. Un fişier XML nu va fi acceptat de către nici un

program receptor până când nu se asigură că este bine format, de aceea există fişiere corecte din punct

de vedere HTML dar incorect formate după regulile XML, motiv suficient să putem afirma că HTMLnu este un vocabular XML. "Buna formare" este o constrângere specială impusă de XML, care nuexistă în SGML. De aceea un document XML va putea fi considerat corect din punct de vedere SGML,ignorându-se constrângerea suplimentară, deci putem afirma că XML este un vocabular SGML (culimitarea amintită privind setul caracterelor).

Aşadar: 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.

Totuşi, eforturi în vederea compatibilizării s-au realizat, prin construirea unui vocabular XMLnumit XHTML. Acest limbaj a fost construit în aşa fel încât defineşte marcatorii consacraţi în HTMLcu semnificaţiile lor consacrate, dar le impune regulile de bună formare (obligativitatea imbricării, aghilimelelor etc.), astfel încât XHTML poate fi considerat o versiune a limbajului HTML care respectătoate regulile XML.

1.3. Prelucrarea informaţiilor XML În cele ce urmează se va folosi terminologia consacrată: receptorii documentelor XML poartă

numele de consumatori. Aceştia pot fi utilizatori umani, pentru care are importanţă deosebită

4 În altă exprimare, HTML nu doar introduce reguli noi, ci permite abateri de la regulile XML

5 Ghilimelele din documentele XML trebuie să fie ghilimelele drepte, din setul de caractere pecare le folosesc mediile de programare şi nu ghilimele rotunde, folosite de editoarele de texte, ceea cecauzează adesea o eroare dificil de sesizat.



12

lizibilitatea, sau programe. Programele care aşteaptă date de intrare în format XML, în scopul prelucrării acestora, poartă numele de procesoare XML.

În vederea utilizării documentelor XML, nu este suficient ca procesoarele să conţină proceduride prelucrare a marcatorilor şi a datelor marcate. Înainte de asta trebuie să fie capabile să delimiteze şisă extragă marcatorii şi conţinutul lor, atributele şi valorile lor, pentru a le atribui unor variabile delucru. Astfel, înainte de a fi procesată informaţia 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. Aşa cum un browser transformă documentul HTML într-o formă accesibilă utilizatorului uman în vederea afişării, un parser transformă documentul XML într-un model accesibil programelor în vederea prelucrării datelor. Parserele sunt disponibile în variatesisteme de operare, inclusiv Windows XP, sub forma unor biblioteci de funcţii apelabile din variatemedii de programare obiectuală. S-au consacrat două astfel de modele, şi două tipuri de parserecorespunzătoare:

A. DOM (Model obiectual al documentelor)Regula de imbricare corectă a marcatorilor face ca orice document XML să poată fi tratat ca

un arbore în care relaţia de incluziune (între marcatori imbricaţi) este transformată într -o relaţie tată-fiu în arbore. Localizarea datelor în şiruri de caractere este mult mai anevoioasă decât căutarea înarbori, pentru care există deja algoritmi consacraţi. Rezultatul operaţiei de parsing DOM este un

model obiectual arborescent al documentului: marcatorii şi conţinutul lor sunt transformaţi în clase,obiecte şi atribute, după principiile obiectualităţii. DOM oferă metode (în sens obiectual) puternicepentru parcurgerea arborilor, convertirea datelor din arbori în diferite tipuri de variabile saumodificarea structurii arborelui (adăugare de noduri, modificare, mutare, copiere sau ştergere).

În urma construcţiei unui arbore DOM, nodurile arborelui vor corespunde unităţilor delimitate din document şi vor avea diferite tipuri: un nod element va avea subordonate noduri atribute,noduri de conţinut textual, noduri ale elemenetelor fiu şi alte tipuri de noduri corespunzătoareconstrucţiilor auxiliare permise în XML.

Dezavantajul DOM este dat de faptul că întreg documentul XML este încărcat în memoriainternă pentru a fi reprezentat în arbore, deci este un model consumator de memorie internă.

B. SAX (Simple API for XML).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 încărcat complet, cicaracter cu caracter, în aşteptarea declanşării unor evenimente. Exemple de evenimente uzuale sunt:

apariţia unei etichete de deschidere (startElement), apariţia unei etichete de închidere (endElement), apariţia unui conţinut textual care nu este marcator (characters).

Pentru fiecare eveniment, asociat fiecărui marcator relevant, se pot construi funcţii (metode)speciale numite manageri de evenimente (event handler), în care se indică operaţiile ce se vor executala apariţia evenimentului.

Se poate remarca similitudinea între modul de procesare a fişierelor XML şi modul deprocesare a bazelor de date relaţionale. În teoria bazelor de date relaţionale, SGBD -ul este programulresponsabil cu convertirea fişierelor fizice de pe disc, care conţin datele, într -un modeltabelar/relaţional, 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 datearborescente şi bazele de date relaţionale, despre care s -a considerat multă vreme că s-a finalizat cutriumful ultimului model. În prezent, pentru anumite utilizări ale XML, putem considera că fişiereleXML devin baze de date arborescente care au multiple avantaje în special în ce priveşte portabilitatea(şi deci distribuirea informaţiei pe diferite platforme), dar şi în ce priveşte reflectarea relaţiilor tată-fiu

între date.Aceasta asigură faptul că limbajele de tip XML (vocabularele) pot fi considerate simultan

limbaje de programare (care oferă instrucţiuni executate de consumator) sau modele de date (care oferăstructuri de date şi nume de cîmpuri). Prin asta subliniem încă o dată versatilitatea XML şi justificăm

preferinţa pentru termenul vocabular în loc de limbaj de tip XML sau model de date XML. Utilizăriledocumentelor XML, ca succesiune de instrucţiuni (marcatori) sau ca structură de date, rămâne lalatitudinea consumatorului în funcţie de scopul propus.

În concluzie, prin calitatea sa de metalimbaj, XML reuşeşte să anuleze diferenţierea între text ,cod sursă şi date, grupându-le pe toate în conceptul general de document.



13

1.4. Validarea informaţiilor XML

Validarea XML este un proces de verificare a corectitudinii documentelor superior verificăriiregulilor de bună formare. Regulile de bună formare impun doar un număr redus de reguli sintactice(imbricare corectă, caractere permise în marcatori etc.). Validarea devine utilă în oricare din abordările

amintite, deci indiferent dacă vedem în documentul XML un cod sursă cu instrucţiuni, o structurăcomplexă de date sau un text marcat cu descrieri semantice ori de formatare. În perspectiva tratării fişierelor XML ca structuri de date, vocabularul devine un model de

date iar validarea devine similară cu validarea câmpurilor din baze de date. În teoria bazelor de date,validarea verifică datele în raport cu un criteriu, regula de validare. Atunci când se introduc, spreexemplu, notele studenţilor într -un tabel trebuie să se impună regula conform căreia nici o notă să nufie din afara intervalului 1-10. Alte exemple de validări sunt preţurile şi cantităţile care trebuie să fiepozitive, intervalele de vârstă acceptate în diverse situaţii etc. Prezenţa datelor invalide în bazele dedate poate avea efecte grave asupra programelor care folosesc acele date şi asupra rezultatelor acestora.În baze de date scopul validării este să se asigure un conţinut valid al tabelelor în raport cu sensulatribuit datelor.

În perspectiva tratării fişierelor XML ca şi coduri sursă, vocabularul devine setul permis deinstrucţiuni-marcatori iar validarea devină similară cu verificarea sintactică a codului sursă, în

limbajele de programare tradiţionale. În perspectiva tratării fişierelor XML ca texte, validarea îmbină aceste abordări, verificânddeopotrivă corectitudinea marcatorilor cât şi informaţia marcată (intervale de valori, tipuri etc.).

Astfel, se pot crea vocabulare XML de variate complexităţi, orientate pe tipizarea datelor, peimpunerea unor structuri de marcatori sau variate combinaţii între cele două abordări.

Odată ce un vocabular a fost creat se pot construi documente pe baza construcţiilor permise devocabular. Distribuirea vocabularului permite ca regulile vocabularului să fie aduse la cunoştinţatuturor utilizatorilor şi programelor care ar putea lucra cu acel tip de documente pentru a stabili oconsistenţă în utilizarea marcatorilor personalizaţi. În momentul în care se transmite un fişier XML dela un utilizator la altul, de la un program la altul, ambele părţi trebuie să fie de acord asupra regulilor după care s-au construit marcatorii, pentru a înţelege sensul şi posibilităţile de utilizare a conţinutului.Aceasta se realizează prin consultarea vocabularului care devine o bază contractuală între emiţător şireceptor. Compararea unui document XML faţă de regulile unui vocabular DTD este procesul de

validare şi se realizează cu programe speciale denumite validatoare6

. Opţiunea de validare este inclusăşi în unele parsere, deşi de multe ori este dezactivată pentru a nu afecta viteza de procesare adocumentului din partea programului destinaţie. Programul validator trebuie să aibă la dispoziţie DTD -ul şi documentul XML care se verifică.

O altă variantă în acest sens o reprezintă documentele care au diferite porţiuni scrise în diferitevocabulare, cu alte cuvinte, fiecare marcator îşi poate invoca propriul vocabular care să-i guvernezeconţinutul.

Î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 fără posibilităţi de tipizare; validarea XML Schema este mai puternică, aduce în plus tipizarea datelor, deci permite

impunerea de reguli atât asupra informaţiei marcate cât şi asupra marcatorilor.

DTD (Definiţia tipului de document) conţine regulile de construire ale unui vocabular XML pentru date netipizate (numit şi tip de document ). Folosind o sintaxă SGML, un DTD precizeazămarcatorii acceptaţi în vocabular, atributele lor şi structurile permise (imbricări, ordine, număr deapariţii etc.). DTD-ul poate fi:

intern, dacă este descris în interiorul unui document XML; extern, dacă este descris într -un fişier independent, cu extensia .dtd.

Ultima metodă este recomandată deoarece fişierul extern va putea fi distribuit independent dedocumentele XML care îl invocă.

Spre exemplu, HTML este un tip de document SGML: se ştie că fişierele HTML şi SGMLsunt, de fapt, f işiere text (conţin un şir de caractere), dar nu orice fişier text este cod HTML valid.

6 Chiar dacă se poate folosi orice editor de texte pentru scrierea documentelor XML, serecomandă folosirea editoarelor profesionale (XMLSpy, StylusStudio) care permit şi construirea devocabulare, precum şi validarea.



14

Vocabularul HTML conţine un set fixat de marcatori care pot fi folosiţi şi mai conţine o serie de regulila care se supun marcatorii (<tr>, rândul unui tabel, apare obligatoriu încadrat în <table>, marcatorul

pentru crearea unui tabel). Doar fişierele text care respectă constrângerile acestui vocabular sunt valide din punct de vedere HTML.

Pe scurt, constrângerile DTD indică, de fapt, regulile care definesc un limbaj de tip XML,reguli suplimentare pe lângă cele de bună formare impuse de XML dar insuficient de puternice încât să

impună restricţii de tip asupra informaţiei ce va fi marcată în documentele vocabularului.În plus, există posibilitatea ca un document să respec te regulile mai multor DTD-uri simultan,astfel se va putea afirma că documentul aparţine mai multor tipuri de document (vocabulare). Deexemplu, orice document XHTML este valid în acelaşi timp, după regulile limbajelor XHTML, XMLşi SGML.

XML Schema este un vocabular XML (deci este definit la rândul său printr -un DTD) al căruiscop este să definească vocabulare XML tipizate (scheme XML), având în vedere că DTD nu oferăaceastă posibilitate. Prin aceasta, un vocabular XML Schema se apropie de conceptul de schemă a

bazei de date, impunând 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> defineşte regula conform căreia toate elementele copiltrebuie să apară într -un document exact în ordinea precizată de schemă: mai întâi elementul cu numele

profesia, apoi categorie-varsta7 .

Elementele <xs:element> definesc cele două elemente permise: unul cu numele profesia şi a cărui valoare (conţinut) va trebui să fie de tip string; în plus,

având în vedere că numărul minim de apariţii posibile este 0 (minOccurs), înseamnă căprofesie este un marcator/element opţional;

unul cu numele (eticheta) categorie-varsta, tot opţional; conţinutul acestui marcator va fi deun tip de date personalizat (simpleType):

o acest tip este definit cu ajutorul elementului <xs:restriction>: foloseşte 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ă validăm următoarele date înformat 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 (secvenţa) celor doi marcatori; intervalul de valori acceptate 18-100; apariţia unui element nedefinit în schemă.

Presupunem validarea conţinutului XML:

<categorie-varsta>25</categorie-varsta>

7 Acest element este un descriptor de mulţime. Descriptorii de mulţime delimitează o mulţimede elemente XML şi stabileşte caracterul lor (opţional, obligatoriu), precum şi ordinea acestora (impusăsau liberă)



15

De data aceasta datele sunt valide, deoarece respectă toate regulile: chiar dacă elementul <profesie> lipseşte, aceasta respectă regula conform căreia este un

element opţional; valoarea 25 respectă regula de apartenenţă la tipul întreg non-negativ, precum şi restricţia

suplimentară de apartenenţă la interval. nu apare nici un alt element în afara celor prevăzute.

În consecinţă, validitatea documentelor XML nu se raportează la un set absolut de reguli (aşacum este în cazul regulilor de bună formare, impuse de standardul XML) ci relativ la un vocabular. Unacelaşi document poate fi valid conform cu unele vocabulare (DTD sau scheme) şi invalid în raport cualtele. Important este ca atunci când documentul este transferat între un emiţător şi un consumator,ambele părţi să se pună de acord asupra vocabularului faţă de care se validează şi să aibă acces laacesta. Cu ajutorul vocabularelor, XML asigură un nivel de interoperabilitate superior hipertextului,interopera bilitatea structurală sau sintactică, ceea ce înseamnă că entităţile Web pot să schimbedocumente XML (coduri sursă, structuri de date sau de text) conforme unor reguli sau tipizări comune.

În final, rezumăm 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, fără a fi necesară afilierea la un vocabular; buna formare este

obligatoriu verificată de către orice consumator XML şi condiţionează operaţia de parsing; validitatea: un document XML este valid în raport cu un vocabular dacă respectă regulile şi

tipizările impuse de acesta (prin DTD, XML Schema dar şi alte soluţii asupra cărora se vareveni ulterior); validitatea nu condiţionează operaţia de parsing şi documentele XML pot ficreate sau consumate fără a se verifica afilierea lor la un vocabular.

1.5. Sintaxa XML

Componentele unui document XML sunt: Declaraţia XML (Prologul) Elementele şi atributele lor Datele de tip caracter Referinţele entităţilor Instrucţiunile de procesare Comentariile Invocarea DTD (dacă documentul se supune unui vocabular)

Declaraţia XML Este o componentă poziţionată obligatoriu la început. Se recomandă utilizarea sa pentru ca

aplicaţiile care citesc documentul să recunoască formatul XML fără 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 opţionale:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>

Datele opţionale sunt setul de caractere folosit în document şi dacă documentul esteindependent (nu invocă DTD extern). Alte seturi uzuale de caractere sunt:

Unicode extins, pe 16 biţi, 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

ElementeleSunt componentele fundamentale, alcătuite din:

etichetele marcatorilor;



16

conţinut (valoarea elementului) - conţinutul poate la rândul său să fie constituit din alteelemente (subelemente, elemente imbricate, elemente fiu).Regulile de bună formare privind elementele:

Să existe exact un element rădăcină (elementul document); Toate elementele au etichetă de închidere şi de deschidere, inclusiv elementele vide (pentru

care se admite notaţia prescurtată, cu o singură etichetă); Toate elementele să fie corect imbricate (conţinuturile 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 spaţii, acestea fiindconsiderate delimitatori de atribute);

Excepţie privind numele: nu pot să înceapă cu cuvântul "xml" (majuscule, litere mici sau oricecombinaţie); se recomandă şi evitarea caracterului ":" folosit în anumite scopuri specifice(spaţiile de nume).

AtributeleSunt perechi nume=valoare subordonate elementelor.Reguli de bună formare privind atributele:

Atributele se ataşează doar etichetei de deschidere a elementului; Perechile nume=valoare se delimitează prin spaţii; Valorile atributelor se încadrează obligatoriu cu apostrof sau ghilimele drepte ('...' sau "..."); Un nume de atribut nu se poate repeta în acelaşi element (în timp ce elementele se pot repeta

în acelaşi document sau chiar subordonat aceluiaşi element- părinte!) Atributele nu pot conţine caracterele <,&,','' Nu are relevanţă ordinea atributelor în cadrul elementului.

Date de tip caracterConţinutul elementelor XML sau valorile atributelor au un singur tip: caracter. Practic, datele

de tip caracter sunt echivalente cu conţinutul textual al elementelor (acel conţinut 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 conţinut î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 conţine caractere <, &, acestea având semnificaţie deosebită în XML (începutul unui

marcator); pentru a utiliza aceste caractere se apelează la una din soluţiile de mai jos:

Soluţia 1: Secţiuni CDATAAceste secţiuni încadrează porţiunile de conţinut textual în care apar caractere nepermise. Spre

exemplu, ar putea apare probleme de parsing a următorului conţinut:

<Paragraf>Forma generala a unei etichete XML este: <eticheta></Paragraf>

Conţinutul textual are o porţiune care ar putea fi interpretată ca marcator XML când, de fapt,este un text oarecare inclus în elementul Paragraf. Mai mult, se va semnala o eroare de bună formaredeoarece <eticheta> nu are etichetă de închidere. Forma corectă este:

<Paragraf><![CDATA[Forma generala a unei etichete XML este: <eticheta>]]></Paragraf>

În cadrul secţiunii CDATA, parserele ignoră orice marcatori, până la întâlnirea simbolurilor deînchidere a secţiunii ("]]>"). Se recomandă încadrarea întregului conţinut textual al unui element însecţiune CDATA. Parserele nu consideră echivalentă următoarea construcţie:

<Paragraf>Forma generala a unei etichete XML este: <![CDATA[<eticheta>]]></Paragraf>



17

În ultimul exemplu, se consideră că elementul conţine două unităţi: blocul de text şi secţiuneaCDATA, ceea ce influenţează modul în care un parser DOM delimitează nodurile în document (se vor crea două noduri fiu pentru nodul Paragraf ).

Soluţia 2: Referinţe entitate

Acestea sunt un tip special de marcatori de forma &NumeEntitate;, utilizaţi în HTML pentruincluderea unor caractere speciale (entităţile text), inclusiv a caracterelor nepermise. Exemplulanterior poate fi scris şi în forma:

<Paragraf>Forma generala a unei etichete XML este: <eticheta></Paragraf>

Aici, "<" este referinţa entităţii "<", caracter nepermis. Se poate observa regula de bunăformare a acestui tip de marcatori: "&" şi ";" sunt etichetele, iar "lt" este numele entităţii. În acest caznumele entităţii este codul unui caracter, dar în XML entităţile capătă o funcţionalitate mult ma largă.

Numele entităţilor pot fi cunoscute pe trei căi: pentru caractere speciale există un set de coduri standard, utilizate şi în HTML şi recunos cute

de parsere: < (<) > (>) & (&) ' (') " ("). entităţile HTML sunt un exemplu restrâns; î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 fireutilizată nelimitat8.

entităţile pot fi definite la o adresă URL sau în fişiere externe, care se indică parserului pentruconsultare.O altă utilizare, mai puţin frecventă, a acestui tip de marcator este referirea caracterelor prin

cod numeric recunoscut de orice parser: în forma zecimală: & în forma hexazecimală: (

Instrucţiuni de procesare Acestea sunt reprezentate de un alt tip de marcatori speciali în care parserele delimitează două

şiruri de caracter separate cu primul spaţiu care apare în marcator, sub forma:

<?predicat parametru?>

Aceste elemente sunt interpretate de procesoarele XML ca indicaţii asupra unor prelucrări carese recomandă de către creatorul documentului, recomandări adresate aplicaţiei consumatoare vizate.Consumatorul trebuie să fie dotat cu un mecanism de interpretare a acestor instrucţiuni, de receptare a

parametrului şi de efectuare a operaţiilor recomandate de document. Parametrul este tratat ca un şir decaractere dar poate conţine orice structuri ce pot fi reprezentate prin caractere, inclusiv şiruri deinterogare, seturi de perechi atribut-valoare etc. Totuşi, conţinutul parametrului nu va putea fi procesatsub formă de atribute, aplicaţia consumatoare fiind nevoită să folosească o metodă de extragere asubşirurilor pentru a utiliza datele stocate în parametru.

În mod similar, orice program într-un limbaj oarecare conţine o serie de instrucţiuni care sunt

practic recomandări de prelucrare adresate compilatorului. Desigur, nici un compilator nu va ignorasetul de instrucţiuni ale unui limbaj de programare. În cazul documentelor XML, consumatorul poate săinterpreteze sau să ignore recomandările de procesare. Considerăm 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 modnormal, programele care vor recepţiona (consuma) aceste date vor avea implementat, de exemplu,

8 Putem considera că entităţile au rolul variabilelor şi procedurilor reutilizabile: valoarea l or poate fi o dată, o succesiune de marcatori XML sau orice porţiune a unui document XML. Numele lor (mai exact referinţa) va fi apoi folosit pentru a apela şirul de caractere respectiv oriunde este nevoie.



18

mecanismul de a le stoca într-o bază de date relaţională. Primul marcator din cadrul elementuluiStudent este o instrucţiune de procesare care recomandă o procesare de excepţie legată de aceste date,de exemplu că ar trebui folosite pentru a corecta datele existente ale studentului cu legitimaţia 101. Mairămâne să ne asigurăm că programul consumator înţelege recomandarea şi conţine algoritmul care sătrateze această recomandare.

În ciuda aparenţelor, instrucţiunea 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 Legitimaţia, ciavem două şiruri de caractere: Corectura este predicatul, indicaţia 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 deşiarată ca un atribut obişnuit. De aceea, mai poartă şi denumiea de pseudoatribut . Indicaţia deprocesare ar putea arăta şi astfel:

<?CR 101?>

desigur, cu condiţia ca programul consumator să înţeleagă ce înseamnă instrucţiunea CR şi cesemnifică parametrul 101. Acest detaliu este important deoarece, după cum se va arăta în capitolulModele de procesare XML, parserele sunt capabile să extragă fiecare atribut dintr -un element, dar

dintr-o instrucţiune de procesare nu pot să extragă decât cele două şiruri de caractere componente: un predicat şi un parametru, urmând ca parametrul să sufere operaţii la nivel de stringuri dacă stochează ostructură de date mai complexă (vector, atribute etc.).

Regulă de bună formare a instrucţiunilor de procesare: nu trebuie să înceapă cu şirul xml (majuscule, litere mici sau orice combinaţie), acestea fiind

rezervate pentru declaraţia XML de la începutul documentului.Se poate considera că declaraţia XML de la începutul unui document este o astfel de

instrucţiune, ale cărei recomandări, de identificare a versiunii XML şi a setului de caractere folosit, suntînţelese de orice parser.

ComentariiForma comentariilor este următoarea:



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 către programele care exploatează rezultatuloperaţiei de parsing, pentru o localizare corectă a informaţiei.

Regulă de bună formare a comentariilor: nu pot să conţină succesiunea "--" care este interpretată ca final de comentariu

Invocarea DTDAceastă parte este necesară doar în documentele care au fost construite conform unui

vocabular de tip DTD. Aceste documente trebuie să conţină o zonă în care se face apelul la DTD -ulcare conţine regulile vocabularului la care se afiliază documentul. Apelul DTD -ului se realizează în

diferite moduri:

DTD intern: Însoţeşte permanent documentul, caz în care va fi inclus chiar în document, într -un marcator DOCTYPE, plasat imediat după declaraţia XML:

<!DOCTYPE NumeElementRadacina [descriere DTD intern]>

O soluţie mai comodă este memorarea sa într -un fişier separat, pentru a nu afecta dimensiuneadocumentelor. În această situaţie, fiecare document va conţine calea sau URL -ul unde estepoate fi consultat DTD-ul. Evident, soluţia cea mai comodă este ca DTD-ul să poată ficonsultat de la o adresă Web unde să fie permanent disponibil. În această situaţie avem unDTD extern care se apelează cu:

<!DOCTYPE NumeElementRadacina SYSTEM Cale/URL>



19

DTD mixt apare atunci când un document invocă un vocabular extern şi în acelaşi timpconţine o definiţie de vocabular internă; de regulă această metodă se foloseşte când DTD-ulintern îşi propune să particularizeze o parte din regulile DTD-ului extern invocat;

Ultima situaţie este atunci când un document foloseşte 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 spaţiile de nume:

Spaţiile de nume oferă o metodă de invocare a vocabularelor (de orice tip, DTD sau scheme) prin calificare cu un prefix. Prefixul permite invocarea multiplă evitând coliziunii între nume (deelemente ş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ă construcţie foloseşte atributul special xmlns:xlink care este un atribut cu nume şivaloare bine formate pentru un parser care nu înţelege spaţii de nume. Majoritatea parserelor moderneacceptă însă spaţiile de nume şi vor da următoarea interpretare:

Elementul UnElement va fi utilizat conform cu regulile vocabularului XLink şi oriceconstrucţie din vocabularul respectiv va fi prefixată cu xlink, Regulile XLink sunt disponibile pentru consultare la adresa precizată ca valoare a atributului

xmlns:xlink9

Toţi marcatorii şi atributele ale căror nume începe cu xlink vor fi validaţi în raport vocabularulXLink, cu condiţia ca aceştia să apară în interiorul elementului care a invocat spaţiul de nume.Se observă cum în interiorul elementului, fiecare atribut (type, href) este calificat cu numelevocabularului.Cu alte cuvinte, spaţiile 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 dinspaţiul respectiv poartă numele de prefix, în acest caz prefixul fiind xlink. Prefixul este identificatorullocal al spaţiului de nume, pentru a evita reinvocarea repetată a spaţiului de nume, la fiecare element,prin atributul xmlns. Evident, fiecare element al unui document poate să îşi invoce propriul vocabular,

cu propriul spaţiu de nume (şi prefixul aferent). Marcatorii care nu sunt calificaţi se consideră caaparţin vocabularului de bază al documentului, dacă a fost invocat unul.

Un exemplu pe care l-am întâlnit deja sunt marcatorii de validare XML Schema care aparţinvocabularului XML Schema şi trebuie calificaţi în spaţiul de nume xs11. Reluăm exemplul pentrureamintire:

<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>

9 Nu este obligatoriu ca la adresa respectivă să existe ceva. Important e ca valoarea atributuluiprefixat cu xmlns să fie un nume unic. Este recomandat ca acest nume să indice spre o resursă utilă dinpunct de vedere informativ.

10 Calificare în sensul de "aparţine". Marcatorii şi atributele calificate cu un nume devocabular, aparţin acelui vocabular. Această tehnică este similară cu calificarea obiectuală, unde sefoloseşte punctul: Obiect.Atribut este o construcţie prin care se arată că Atribut este o componentă a

Obiect. 11 Prefixul este la alegerea creatorului documentelor. xs şi xsd sunt prefixe uzuale pentruconstrucţii XML Schema care, aşa cum s-a arătat, este la rândul său definit ca un vocabular DTD.



20

</xs:schema>

Elementul rădăcină în acest exemplu este xs:schema. Prin atributele sale se precizează: în interiorul elementului se va folosi vocabularul XMLSchema (denumit prescurtat xs) ale

cărui 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ă precizări în formarea marcatorilor şi atributelor.

Se mai observă că vocabularul XMLSchema permite activarea sau dezactivarea calificărilor, având învedere că într -o schemă XML nu există de regulă marcatori din alte vocabulare.

Deoarece un spaţiu de nume (şi vocabularul aferent) este utilizabil doar în interiorulelementului în care a fost invocat cu atributul xmlns, se recomandă ca toate spaţiile de nume să fiedeclarate în rădăcina documentului, pentru a fi accesibile oriunde în document.

1.6.Principiile DOM

Modelul DOM este unul din cele două soluţii consacrate pentru extragerea informaţiilor dintr -un document XML, indiferent că acestea sunt stocate în numele sau valorile elementelor, numele sauvalorile atributelor sau în structurile XML auxiliare. DOM nu este o aplicaţie în sine, ci un modelabstract implementat la nivelul parserelor, ca o colecţie de interfeţe de programare (API) ce folosesc

paradigma obiectuală pentru a transpune conţinutul oricărui document conform cu standardul XML înclase, obiecte şi metode. Astfel, DOM este independent de platformă şi limbajul de programare, fiindconsiderat un strat între parser şi aplicaţiile consumatoare de XML. Practic, parserul citeşte date dinsursa XML şi alcătuieşte arborele DOM translatând imbricările între marcatori în relaţii tată -fiu şiunităţile XML în noduri ale arborelui.

Tipul de dată fundamental în DOM este DOMstring, un şir format din caractere de 16 biţi încare 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 pesteun tip de string 8-bit. Nucleul DOM, numit DOM Core, este un set de interfeţe de programare de uz general la care

se adaugă module oţionale precum cele adaptate pentru manipulare de de stiluri HTML, care nu apar neapărat în toate implementările şi dintre care indicăm:

DOM Views – pentru manipularea unei reprezentări 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 porţiuni de document

care nu reprezintă neapărat colecţii de noduri (fragmente, conţinut textual).

În modelarea DOM, pornim de la exemplul de mai jos, salvat în fişierul fisier.xml:

<produse><produs cod="p01">Televizor</produs></produse>

Un parser DOM va crea din acest exemplu următoarea ierarhie de noduri:



21

Fig. 2. Modelul arborescent creat de un parser DOM

Nodul rădăcină reprezintă întreg documentul în ansamblu. Este important să se evite confuzia între nodul rădăcină şi elementul rădăcină , care este primul element XML din document, dar este unfiu al nodului rădăcină, alături de declaraţia XML. Prin aceasta, sugerăm că nodurile DOM sunt dediferite tipuri: elemente, atribute, conţinut textual, comentarii, instrucţiuni de procesare etc. Esteimportant de reţinut că nodurile atribute sunt tratate ca proprietăţi ale nodurilor elemente şi nu canoduri fii ale acestora, ceea ce afectează rezultatul anumitor operaţii de procesare a fiilor unui nod.

Node List este o interfaţă necesară manipulării colecţiilor de noduri ordonate. Faptul că ocolecţie de noduri poate să apară chiar în subordinea nodului rădăcină, indică faptul că acesta poateavea şi alţi fii decât elementul rădăcină: declaraţia XML, invocarea DTD, un comentariu etc. Named

Node Map este o interfaţă pentru manipularea colecţiilor neordonate de noduri referite prin nume, cumsunt colecţiile de atribute.

Cele două interfeţe sunt specializări care moştenesc interfaţa generică Node, prin care se

manipulează toate nodurile DOM. Alte interfeţe specializate din Node sunt Element, Document, Text,Character Data şi Attr al căror rol poate fi intuit. Manipularea arborelui poate avea loc pe două căi: Generic, prin manipularea interfeţei Node; Ierarhică, prin manipularea specializărilor interfeţei Node.Manipularea generică, denumită şi abordarea aplatizată, este utilă în lucrul cu documente

foarte mari în care performanţa primează. Manipularea ierarhică permite însă un mod de lucru mai facil prin exploatarea unor proprietăţi redundante.

Interfeţele nucleului DOM Core sunt descrise în cele ce urmează, conform clasificării în douăcategorii.

Interfeţele fundamentale trebuie să apară în orice implementare, chiar şi cele care vor lucracu documente nonXML (HTML sau CSS).

Interfeţele extinse trebuie să apară în implementările care lucrează cu XML şi implic it cuXHTML.

<HTML><HEAD>

Document NodeDocumentul complet

NodeList

Element Node<produse>

Element Node<produs>

NodeList

NamedNodeMapNodeList

AttrNodeID=”p01”

Character DataText Node

„Televizor”



22

<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 MSXML2disponibil pe platforme Microsoft. Printre proprietăţile şi metodele acestei implementări se remarcă ceade încărcare a fişierului (load) şi indicaţia de încărcare asincronă (async). Încărcarea asincronă permitecodului sursă să se execute în continuare, înainte ca operaţia load să se finalizeze.

1.7. Vocabulare XML orientate spre afaceri

Afacerile electronice sunt unul din domeniile cele mai strâns legate de cerinţeleinteroperabilităţii deci, implicit, de integrarea XML în aplicaţiile software. Se poate afirma că îndomeniul e-business XML este mai mult decât un limbaj, este un suport al paradigmei sistemelorcolaborative. Stephen Mohr (Omicron Consulting), în cadrul uneia din conferinţele Wrox, afirmă căafacerile electronice sunt exerciţiul fundamental în interoperabilitate, de al cărui succes depindedezvoltarea pe scară largă a sistemelor colaborative.

Interoperabilitatea afacerilor electronice presupune conectarea şi comunicarea fluidă în cadrulunei reţele de furnizori şi parteneri de afaceri, grefată pe o reţea de aplicaţii şi agenţi software. XML calimbaj 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 reacţie reduşi,

precum şi separarea sarcinilor cu posibilitatea de outsourcing a anumitor activităţi spre organizaţii partenere. Orice activitate realizată manual anulează într -o anumită măsură aceste calităţi şi orice punctde interconectare între sisteme ce folosesc formate diferite de date produc costuri proprii care riscă, însisteme eterogene să compenseze negativ reducerile de cost dobândite prin virtualizare. Este imperativăimplementarea în condiţii de cost minim a aplicaţiilor e- business pentru ca acestea să nu producă o

povară suplimentară asupra organizaţiei. La punctele de interconectare între aplicaţii şi sisteme apare problema conversiilor de format deoarece fiecare organizaţie are tendinţa de a-şi impune propriulmodel de date şi chiar diferite aplicaţii ale aceleiaşi organizaţii folosesc modele diferite. Problema edoar parţial rezolvată prin adoptarea standardelor, dar aceasta reduce doar parţial eteorgenitateamediului economic virtual. Contribuie la ameliorarea problemei şi adoptarea sistemelor Electronic DataInterchange, dar acestea au succes în companiile mari care îşi permit achiziţia unor platforme orientateEDI.

Interoperabilitatea trebuie să poată fi asigurată la orice nivel, chiar şi sub nivelul small

business, public sau privat, şi la orice scară (independent de numărul de parteneri) astfel încât oricedouă sisteme ce pot fi conectate hardware să poată schimba date cu efort minim de conversie. În unelecazuri, partenerii de afaceri sunt cei care dictează formatul datelor care se schimbă între organizaţii,astfel că organizaţiile mici trebuie să fie pregătite să se adapteze la cerinţele de format care pot săapară.

Investiţiile existente, sistemele moştenite, sunt încă suficient de mari încât înlocuirea lor definitivă să fie o soluţie. Majoritatea sunt adoptate la un nivel profund în organizaţie, fără să mai fienecesară antrenarea şi adaptarea lor la sistemul informaţional. De multe ori interoperabilitatea acestor sisteme este asigurată de intervenţii manuale: receptarea unei situaţii de ieşire şi retastarea sa ca set deintrare. În alte cazuri, este implementată o interfaţă de conversie între sisteme. Totuşi, în contextulefectului de reţea, numărul de interfeţe 1 la 1 ajunge să fie foarte costisitor. Soluţia ideală este creareaunui format universal standard, cu valoare de coloană vertebrală, la care să fie convertite toateformatele moştenite. În aceste condiţii, numărul de interfeţe necesare se reduce drastic. Formatul XML

asigură aceste cerinţe, se pretează comunicaţiilor prin protocoale Internet şi se pretează la conversiidinamice de format. XML se bazează pe structuri de text, aşadar este independent de platformă şi dereprezentarea internă a datelor. XML are suport pentru seturi internaţionale de caractere şi o modalitate



23

de a specifica setul ales chiar în antet. XML nu are nevoie de modificări pentru a fi transferat prin protocoale Internet tradiţionale. XML poate fi adoptat ca format nativ de către noile aplicaţii, dar poateservi şi ca format în care să se convertească datele din alte surse: date din formulare HTML, din tabelerelaţionale, din fişiere text aplatizate, din aplicaţii de mesagerie, din spreadsheet-uri. Indiferent desursă, sunt necesare instrumente de generare şi manipulare XML, dintre care cele mai importante aufost deja prezentate în materialul de faţă. La acestea mai sugerăm câteva cu caracter mai particular.

Seturile de înregistrări ADO oferă posibilitatea de a genera XML pe baza acestora. Înversiunea 2.1 era vorba de posibilitatea de a salva XML pe disc într-un format care echivalaînregistrările cu elementele şi câmpurile cu atribute. Versiunea 2.5 a adus posibilitatea de a scrie XMLîn interfaţa IStreamPersist, de a realiza parsing cu MSXML şi de a scrie XML în obiectul ASPResponse.

Suportul ADO a fost urmat în scurt timp de adoptarea suportului XML în majoritatea SGBD-urilor, de obicei folosind acelaşi format XML generat de ADO, cunoscut mai frecvent ca formacanonică XML. Alternativele la forma canonică au fost introduse de SQL Server 2000, prin careinterogările pot stabili modelul de date XML care să fie generat. Astfel, a apărut problemavocabularelor care fixează structura în care o aplicaţie să exporte sau să genereze date. De asemenea, s-a pus problema conversiei XML dintr-un vocabular în altul. Aceste operaţii au consacrat limbajele decreare a vocabularelor şi limbajul de transformare XSLT, prezentate anterior în lucrarea de faţă.Operaţiile de validare şi transformare au fost adoptate de către parsere ca şi componente opţionale, cu

rol contractual şi de documentare în cazul unui parteneriat B2B. Validarea a devenit în scurt timp ooperaţie cu caracter contractual între organizaţii. Transformarea a căpătat acelaşi rol, de clauzăcontractuală în cazul eşecului adoptării unui vocabular de referinţă comun la momentul unui schimb dedate.

Două vocabulare consacrate în afacerile electronice sunt cXML şi XML Common PurchaseOrder (XML CPO). Rolul lor este să modeleze documente uzuale în derularea afacerilor sub formaunor mesaje cu structura fixată de vocabulare. cXML încapsulează mesajul în elementul cxml, al căruistructură 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 modelării comenzilor de cumpărare, care corespunde unui mesaj de tip OrderRequest încXML. Numeroase astfel de vocabulare s-au dezvoltat în timp. O parte pot fi consultate la site-urilecreatorilor acestora: www.rosettanet.org, www.xbrl.org şi www.biztalk.org fiind două surse dereferinţă.

Un mesaj cXML de tip OrderRequest modelează o comandă sau o actualizare de comandă.Structura acestuia poate fi consultată în exemplul12:

<cXML payloadID="[email protected]" 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



24

<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 cespecifică faptul că e comandă nouă sau o actualizare, şi elementele ItemOut, care modelează câte oînregistrare care va fi facturată.

XML CPO este o alternativă la comenzile EDI în cadrul BizTalk Server, cu elementulrădăcină CommonPO şi elementele POHeader, BillTo, ShipTo, apoi o colecţie de elemente Item şi unelement 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 şiLineItemTotal.

<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 căruia invocă regulile caretransformă celelalte elemente şi creează câteva elemente care nu apar în sur sa cXML.

Deşi foile de transformare XSLT se dovedesc esenţiale pentru comunicarea între vocabularediferite, crearea unei transformări pentru fiecare contact cu un vocabular partener poate deveni osarcină anevoioasă. Preferabil e ca transformarea să fie generată automat prin comparareadocumentelor sursă şi destinaţie şi eventual să poată gestiona şi fişiere text aplatizate sau alte formatetext. În acest scop există numeroase produse software dedicate domeniului B2B pentru gestionareamesajelor, cum este cazul BizTalk Server produs de Microsoft. Prin interfeţe prietenoase, acestinstrument permite crearea de vocabulare de afaceri şi mapări generatoare de transformări automate, cu

posibilitatea de implementare a unui flux de auditare care să verifice fluxul de transformări prin caretrec mesajele.



25

BizTalk Mapper este una din componentele fundamentale în acest scop. Este capabil să preiaspecificaţiile unor mesaje originale (ca XML Schema sau descrieri de mesaje text plate) şi să ofere ointerfaţă grafică pentru modelarea personalizată a componentelor acestor mesaje. Procesăriintermediare între modelul sursă şi modelul destinaţie sunt posibile prin crearea unor intermediarispeciali numiţi functoizi. E vorba de procesări care nu sunt suportate de XSLT, cum sunt manipulăricomplexe la nivel de caracter şi acces la baze de date relaţionale. BizTalk include nativ specificaţiile

XML CPO şi permite încărcarea specificaţiilor altor vocabulare, cum este cXML. Functoizii pot fiutilizaţi pentru obţinerea valorilor calculate, ori se poate apela la elemente xsl care permit încapsulareade scripturi în secţiuni CDATA. Există un număr mare de functoizi pentru calcule uzuale, caregenerează codul respectiv automat în Visual Basic.

BizTalk Management Desk este componenta prin care se pot defini organizaţii virtualeasociate vocabularelor sursă, porturi ce indică vocabularul destinaţie şi locaţia destinaţie şi canale cepermit negocierea vocabularului cu porturile. Portul este punctul la care are loc transformareavocabularelor şi care livrează mesajul final la o destinaţie dorită. Canalul poate fi personalizat înfuncţie de protocolul şi specificaţiile de securitate dorite.

Activităţile B2B uzuale implică adesea şi o sincronizare a unui flux de mesaje de tipuridiferite. BizTalk permite definirea unui astfel de flux în mod grafic la nivelul serverului prin definireadocumentelor de orchestrare. Acestea sunt formate dintr-o serie de acţiuni şi noduri decizionale careimplică porturile şi canalele definite anterior, pot defini fluxuri concurente sau procese condiţionate.

Documentul de orchestrare este în format XML şi poate fi invocat de aplicaţiile care vor să se aliniezela fluxul respectiv.

Comunicarea cu partenerii B2B necesită şi crearea unui portal în care să aibă loc agregareavocabularelor. Biztalk.org este un astfel de depozit de vocabulare pentru mesaje BizTalk.RosettaNet.org este un depozite de fluxuri standard de mesaje. Un număr important de organizaţiiimpun astfel de portaluri ca şi condiţie contractuală pentru alinierea la vocabularele proprii.

XBRL13 este un vocabular XML standardizat pentru domeniul afacerilor, pentru a permiteraportarea în format XML. Standardul este gestionat de XBRL International 14, un consorţiu nonprofitsusţinut de jurisdicţii naţionale din diferite ţări, care activează în interesul adoptării standardelor pentruaplicaţiile contabile, generatoarele de raportări financiare, auditare etc. Eforturile pe marginea XBRLse îndreaptă spre unificarea structurilor de raportare financiară, mai întâi la nivel naţional, prin modelelocale numite taxonomii (create de jurisdicţiile naţionale), apoi şi la nivelul interoperabilităţii

internaţionale. Succesul XBRL este demonstrat de numeroasele proiecte europene de implementare aformatului în aplicaţiile financiare şi de proiectul american lansat de U.S. Federal Deposit InsuranceCorporation pentru agregarea raportărilor câtorva mii de bănci americane15.

Standardul XBRL prevede crearea de documente cu detaliile raportate ale unei afaceri(business facts) însoţite 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 instanţe ale vocabularului XBRL, cuurmătoarele componente:

Datele raportate ale afacerii, în două forme: o Item, un element XML cu conţinut textual; o Tuplu, un element XML cu subelemente imbricate;

Contextul, care indică entitatea care a raportat datele, perioada de raportare şi informaţiiopţionale care indică dacă raportul este o previziune, o constatare, o planificare bugetarăetc;

Unităţile de măsură; Note de subsol; Referinţe la taxonomie. Taxonomia XBRL referită de instanţe este o colecţie de definiţii XML Schema împreună cu o

bază de legături XLink. Definiţiile 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 său de conţinut şi o serie de atribute ce asigură identificarea prin nume şi tipizarea

13 Limbaj extensibil de raportare în afaceri, Extensible Business Reporting Language

14 v. http://www.xbrl.org15 Rezultatele proiectului sunt sintetizate de articolul disponibil lahttp://www.xbrl.org/us/us/FFIEC%20White%20Paper%2002Feb2006.pdf



26

datelor financiare din documentele XBRL. Vocabularul de bază poate fi specializat de jurisdicţiilenaţionale pentru a deservi formatele de raportare financiare cu specific naţional.

Baza de legături este o colecţie de legături extinse XLink, cu arce şi locatori. Rolul său este dea stabili relaţii între conceptele XBRL sau între acestea şi resurse Web concrete sau între marcatoriiXBRL. Baza de legături imprimă un caracter semantic conceptelor structurate cu XML Schema, deaceea o colecţie de documente XBRL nu poate fi validată complet numai faţă de un vocabular, ci

trebuie validată faţă de taxonomie pentru a testa relaţionările semantice. Practic, taxonomia este un setde minivocabulare conectate semantic.Următorul exemplu16 este un fragment XBRL prin care se stabileşte 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 relaţionat 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 lanivelul marilor corporaţii. Scopul schimbării este alinierea raportărilor financiare la un standardtransparent şi este una din priorităţile organismelor de auditare financiară internaţională în urmaincidentelor 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ă, alţii indică faptul că, aşa cum seîntâmplă în XML, complexitatea documentelor este proporţională cu complexitatea feno menuluimodelat.

În concluzie, rolul XML în domeniul afacerilor este asigurat de următoarele 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 decaractere Unicode) sunt standarde;

Flexibilitatea indusă de independenţa de platformă, separarea formei de conţinut şi posibilitatea de a transforma documentele; efectele apar în eficienţă şi izolarea facilă aerorilor;

Longevitatea XML depăşeşte longevitatea sistemelor pe care le alimentează, ceea ce nu ecazul formatelor proprietare sau binare. Datele XML pot persista şi fi transferate la trecereadintr-o versiune în alta a sistemului;

Vocabularele şi transformările asigură comunicarea între parteneri B2B fără ca aceştia să fieinformaţi asupra detaliilor de platformă internă;

Scalabilitatea conversiilor la XML este superioară scalabilităţii interfeţelor 1 la 1; Extensibilitatea XML este dată de posibilitatea de a crea noi vocabulare orientate pe probleme

specifice folosind principii sintactice comune, uşor de asimilat; Simplitatea XML induce simplitate în implementarea parserelor şi interfeţelor de programare

independente de vocabular; Transferul efortului de procesare dinspre server spre client, cu o parte importantă de procese

efectuate în browser; Indicaţii semantice asupra datelor prin caracterul lizibil; Anularea diferenţelor 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



27

Internaţionalizarea este un factor esenţial în interpretarea documentelor cu specific local încontextul unui mediu de afaceri global;

Personalizarea formatelor şi accesibilitate din partea consumatorilor; Eficientizarea metodelor de căutare prin dezvoltarea Semantic Web şi a bazelor de cunoştinţe

pe fundaţia 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 văzut ca şir de caractere oferă o formă serializată a datelor, care se grefează uşor peserializarea 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 cunoştinţelor Care sunt interfețele fundamentale DOM?

Care sunt regulile de bună formare XML? Care sunt diferențele între analizorul XML și validatorul XML? Ce reprezintă termenul DTD? Care sunt caracterisicile vocabularului XBRL? Care e rolul spațiilor de nume?



28

Modulul II. Modelul AJAX

Sumar

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

2.1.Introducere în AJAX 2.2. Fundaţia AJAX 2.3. Platforme şi biblioteci AJAX 2.4. Interfaţa cu utilizatorul

Obiective

Familiarizarea cu tehnologiile care stau la baza AJAX Familiarizarea cu biblioteca Dojo Familiarizarea cu biblioteca Prototype

Familiarizarea cu biblioteca Scriptaculous Cunoașterea modelului AJAX și mecanismelor de comunicare asincronă Aplicarea cunoștințelor în realizarea de pagini Web folosind strict standarde WWW și

bibliotecile aferente

Recomandări

Realizarea unui site Web Rich Client Studiu comparativ între cele trei biblioteci studiate Studiu comparativ între mecanismele de comunicare asincronă

Rezultate aşteptate Formarea deprinderilor practice de implementare AJAX Asimilarea cunoștințelor privind tehnologiile de la baza AJAX Însuşirea proprietăților modelelor Rich Client și Thin Client

RecapitulareModulul anterior a prezentat sintaxa XML, rolul acestuia în interoperabilitate și tehnica de

procesare XML prin intermediul modelului DOM și a interfețelor de programare aferente. Deasemenea, s-au trecut în revistă aspecte legate de XBRL și alte vocabulare XML orientate strict spremodelarea afacerilor.

În cele ce urmează se prezintă tehnologiile care definesc modelul AJAX, precum și o serie deexemple relevante prin care se subliniază deosebirile dintre modelul AJAX brut și bibliotecile Dojo,Prototype și Scriptaculous.



29

2. Paradigma Rich Client şi modelul AJAX

2.1.Introducere în AJAX

AJAX este un termen care promovează paradigma Rich Client în domeniul aplicaţiilor Web.

Aplicaţiile Web au evoluat în timp dinspre paradigma Thin Client, în care rolul clientului se reducea laa formata un document, spre modelele încadrate în aşa numita generaţie Web 2.0, printre care RichClient, ce promovează transferul efortului de procesare dinspre server spre client, pentru a micşoraefortul distribuit al serverului şi pentru a minimiza latenţele provocate de comunicarea intermitentăîntre client şi server (refreshul redundant de pagină) – acestea ducând, în final, la o îmbunătăţire afluidităţii experienţei utilizatorului care apropie regimul de utilizare a aplicaţiilor Web de regimul deutilizare al aplicaţiilor desktop (în care interfaţa cu utilizatorul şi baza de date se află în aceeaşimemorie, deci latenţa reţelei şi refreshul interfeţei nu există).

De-a lungul timpului au existat numeroase tehnologii care să promoveze modelul Rich Client,majoritatea orientându-se însă spre aplicaţii Internet non-Web (programe tip Messenger, gestionarelocală de e-mail - vezi Outlook, diverse aplicaţii desktop consumatoare de date on-line etc.), toateacestea fiind aplicaţii ce necesită un efort prealabil de instalare şi configurare. Dezvoltarea Web spreaceastă direcţie a presupus găsirea de soluţii care să elimine necesitatea instalării modulelor client. Înacest sens, modelul a fost promovat iniţial de appleturile Java şi scripturile client (JavaScript), apoi de

produsele Shockwave (Flash) şi, în prezent, de AJAX şi o serie de variaţiuni ale sale. Astăzi seconsideră că tehnologiile lider în domeniu sunt AJAX şi Flash, aflate în competiţie: Flash ca produs comercial: optim pentru prezentări multimedia şi interfeţe vizuale, scalabil

raportat la suprafaţa de avişare – de la monitor la PDA - şi portabil, dar dezavantajat în ce priveştemanipularea textului (în siteuri Web orientate spre text); Flash necesită pentru creare mediul deprogramare Flash (oferit în prezent în cadrul unor produse Adobe) iar pentru vizualizare un plug-in pentru browser (disponibil gratuit tot prin intermediul Adobe);

AJAX ca soluţie necomercială, bazată strict pe standarde WWW (XML, CSS, HTML,JavaScript): optim pentru manipulare de pagini cu text masiv, cu capabilităţi multimediarezonabile, dar dezavantajat în ce priveşte scalabilitatea pe suprafeţe de afişare de dimensiuni

variabile şi în ce priveşte portabilitatea (datorită diferenţelor din modul în care browsereleimplementează standardele Web); AJAX necesită pentru creare doar un editor de texte iar pentruvizualizare orice browser modern (acestea incluzând implicit interpretoarele CSS-HTML-JavaScript ş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 deJavaScript şi nivelul datelor de XML. Accesul la datele serverului e gestionat asincron pe diferite căi,cele consacrate fiind obiectul XMLHttpRequest (XHR) sau cadrele invizibile. Nivelul prezentării easigurat de HTML (structura paginii) şi CSS (formatul paginii), atât elementele HTML cât şistilurile CSS fiind manipulate dinamic de JavaScript prin intermediul modelului DOM. Partea deserver nu mai trebuie să asigure generare dinamică de cod HTML, ci alimentarea modulului RichClient AJAX cu date în format text (inclusiv XML).

Modelul AJAX e astăzi adoptat pe scară largă de majoritatea actorilor din scena Web,succesul său fiind demonstrat de pionieratul celor de la Google prin Google Maps(http://maps.google.com). Trebuie remarcat că Google Maps nici măcar nu este o aplicaţie AJAX100%, deoarece nu exploatează transferul asincron de date – elementul care leagă tehnologiile Webamintite sub denumirea AJAX.

Indicăm în continuare o comparaţie între aplicaţiile tradiţionale şi cele de tip AJAX: Web tradiţional:

o Datele se trimit de la client spre server cu ajutorul formularelor sau a hiperlegăturilor (variabile GET sau POST), aşadar prin decizia conştientă a utilizatorului (în urmaunui clic); răspunsul se returnează de la server sub formă de cod HTML;

o Starea iniţială a aplicaţiei e determinată de transferul dinspre server a primei pagini

(homepage);



30

o Fiecare stare a aplicaţiei are asociată o nouă pagină generată dinamic (deci stărileaplicaţiei sunt pagini diferite din punct de vede al operaţiilor Back/Forward şi AddBookmark/Favorites);

o Fiecare pagină generată dinamică implică un refresh complet al paginii curente, decele mai multe ori redundant (implică şi reîncărcarea elementelor nemodificate de pe

pagină);

o Fiecare refresh sau încărcare de pagină nouă blochează temporar aplicaţia, până cândnoua pagină soseşte de la server, ceea ce afectează fluiditatea experienţei de utilizare(comparativ cu aplicaţiile desktop unde durata dintre clic şi reacţia la clic e de regulăinsesizabilă);

o Experienţa de utilizare şi utilizabilitatea lasă de dorit, nu doar datorită comunicăriiintermitente cu serverul care suspendă utilizarea, ci şi datorită gamei reduse deevenimente la care reacţionează pagin (de obicei doar clic-uri);

o Rolul browserului e de a formata o pagină (thin client); AJAX:

o Datele pot fi trimise de la client spre server la orice moment, JavaScript putânddeclanşa transferuri HTTP oricând, cu sau fără notificarea utilizatorului; răspunsul sereturnează de la server în format text, fie brut, fie structurat (XML, JSON), pentru afi prelucrat prin funcţii JavaScript;

o Starea iniţială a aplicaţiei e determinată de transferul dinspre server a întreguluimodul client, cu toate stările sale posibile (deci are loc un transfer iniţial masiv care etotuşi suportat de calculatoarele moderne şi nu necesită instalar e, toate interpretoarelenecesare fiind încorporate în browser);

o Fiecare stare a aplicaţiei e obţinută prin modificarea la nivel de client a structuriiinterfeţei cu utilizatorul (structura DOM), pe baza unor date primite de la server (trecerea dintr-o stare în alta nu presupune încărcare de pagină nouă, decimecanismele Back/Forward şi Bookmark nu funcţionează);

o Nu are loc refresh redundant, deoarece după încărcarea stării iniţiale serverul livreazădoar datele necesare aplicaţiei, nu toate elementele interfeţei;

o Cererile asincrone de date nu blochează funcţionarea interfeţei cu utilizatorul (aşacum face refreshul de pagină) – interfaţa continuă să funcţioneze în acele stări carenu au nevoie de datele aşteptate de la server; aceasta asigură o fluiditate rezonabilă a

experienţei de utilizare, apropiată de cea a aplicaţiilor desktop; o Experienţa de utilizare şi utilizabilitatea sunt mult îmbunătăţite, nefiind foarte

afectate de schimbul intermitent de date cu serverul; în plus, gama de evenimente lacare reacţionează suprafaţa interfeţei utilizatorului e apropiată de cea a aplicaţiilor desktop (ex: se poate declanşa un transfer de date la trecerea cursorului peste oanumită zonă a paginii – care nu trebuie să fie neapărat un buton sau o imagine, decischimbul de date cu serverul poate fi parţial ascuns faţă de utilizator);

o Browserul execută o aplicaţie JavaScrip cu interfaţă HTML.

Modelul AJAX are şi o serie de dezavantaje dintre care cele mai importante sunt: Aplicaţiile AJAX nu respectă mecanismul Back/Forward al browserului – aceste operaţii 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);

Aplicaţiile AJAX nu pot fi marcate cu Add Bookmark sau Add Favorites – din motivul descrisanterior, un semn de carte va marcha doar aplicaţia AJAX în ansamblul său, nu poate marcadiferite stări ale sale (aşa cum se pot marca paginile de interes ale unui site);

Aplicaţiile AJAX sunt afectate de diferenţele de implementare în diferite browsere atehnologiilor componente (HTML, JavaScript,XHR, CSS); în acest sens recomandăm studiulsite-ului http://www.quirksmode.org care încearcă să păstreze o evidenţă la zi asupra acestor incompatibilităţi, oferind totodată suport prin tutoriale (inclusiv o funcţie de detectare abrowserului clientului); o parte din aspectele cross-browser sensibile vor fi detaliate înmaterialul de faţă;

Formularele AJAX nu pot realiza nativ încărcare de fişiere pe server (prin câmpuri de tipFILE în formulare) - aceasta se datorează faptului că JavaScript, din raţiuni de securitate, nuare acces la fişierele de pe discul clientului.



31

S-au făcut eforturi pentru a depăşi toate aceste limitări, o parte din soluţii bazându-se pecadrele invizibile. Vom atrage atenţia asupra soluţiilor existente în materialul de faţă, la momentulpotrivit.

Exemple:

Considerăm 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 sfârşitul formularului s-a introdus un marcator p, care defineşte un paragraf vid, fărăconţinut textual. Rolul său este de a afişa ulterior eventuale mesaje de eroare, prin modificareadinamică a conţinutului marcatorului (se poate considera că, în mod implicit, mesajul de eroare estevid). Rolul atributului id este de a identifica în mod unic paragraful respectiv, pentru a fi ulterioraccesat de JavaScript. În acelaşi scop, s-au folosit atribute id pentru fiecare câmp al formularului

(atributul id se poate aplica oricărui marcator din pagină). Scopul exerciţiului este de a construi, prin tehnici AJAX, posibilitatea ca oraşul, judeţul şi

strada să fie completate automat de către server, imediat după ce utilizatorul a tastat codul poştal.Pentru aceasta, se asociază o funcţie handler câmpului CodPostal, care se va executa ca reacţie laevenimentul blur (îndepărtarea cursorului de pe câmp prin Tab, Enter sau cu ajutorul mouseului):

<input type=text id=TXcodpostal onblur="date(this.value)" >

Funcţia respectivă va fi responsabilă cu obţinerea datelor de la server prin intermediulobiectului XHR, capabil să gestioneze cereri HTTP (codul funcţiei se scrie în antetul paginii).

<script>var xhr;

function date(cod){

xhr=new XMLHttpRequest()



32

xhr.open("GET","script.php?CodPostal="+cod)xhr.send(null)

}</script>

Funcţia creează o instanţă XHR (clasa folosită e disponibilă în Mozilla, pentru InternetExplorer vom reveni ulterior cu metoda de instanţiere necesară), care defineşte o conexiune lascript.php transferând ca variabilă GET codul poştal. Funcţia send() este responsabilă cu trimiterea dedate prin metoda POST la server17 şi cu crearea unei stări de aşteptare pentru client (aşteptarearăspunsului). În acest caz singura informaţie trimisă e variabila GET concatenată la adresa scriptului

php. Aşadar, rolul lui send() rămâne cel de a activa conexiunea cu serverul şi de a crea starea deaşteptare (care va fi testată ulterior) motiv pentru care primeşte un argument null.

Pentru a nu complica exemplul, nu vom folosi o bază de date cu codurile poştale, ci vom programa scriptul server să recunoască un singur cod poştal, 400451, corespunzător datelor "Cluj Napoca, Cluj, Aleea Azuga". Următorul cod sursă va fi stocat pe server în fişierul script.php (în acelaşifolder cu pagina HTML client), apelat anterior de obiectul XHR:

<?phpif ($_GET["CodPostal"]==400451)

print "Cluj Napoca,Cluj, Aleea Azuga...(completati detaliile)";else

print "cod incorect, cod incorect, cod incorect";?>

Aşadar, scriptul recepţionează variabila GET CodPostal, care conţine chiar valoarea tastată încâmpul TXcodpostal. Dacă valoarea acestei variabile este chiar cea aşteptată (400451), scriptulreturnează sub formă de text brut, cele trei valori, separate prin virgulă. Dacă s-a primit orice alt cod

poştal, se returnează valoarea "cod incorect" de trei ori. Într -un exemplu pragmatic, variabila GET nuva fi comparată cu 400451, ci va fi căutată în baza de date a codurilor poştale apoi, instrucţiunea printva returna clientului datele corespunzătoare extrase din baza de date.

Revenind la modulul client, o altă funcţie va procesa rezultatul obţinut:

function procesare(){

var datestring=xhr.responseTextvar datevect=datestring.split(',')document.getElementById("TXoras").value=datevect[0]document.getElementById("TXjudet").value=datevect[1]document.getElementById("TXadresa").value=datevect[2]

}

Reamintim că răspunsul primit de la server are forma unui şir de valori text delimitate devirgulă, chiar şi în condiţii de eroare (cod poştal incorect). Din acest şir se extrag datele într -un vectorcu ajutorul metodei split, iar valorile vectorului se atribuie celor trei câmpuri 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ă aclientului). Astfel, document e obiectul ce reprezintă întreaga pagină, iar metoda getElementById cautăun marcator după atributul său id. Proprietatea value a marcatorului găsit este chiar valoarea câmpuluirespectiv, deci în urma celor trei atribuiri, cele trei câmpuri vor fi completate cu datele obţinute de laserver.

Faptul că AJAX este un model asincron de comunicare cu serverul este evidenţiat 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);

17 Metoda POST necesită câteva operaţii suplimentare la definirea conexiunii HTTP asupracărora vom reveni în cadrul unei prezentări detaliate a obiectului XHR.



33

xhr.send(null);procesare();

}

Acest exemplu e incorect - apelul funcţiei procesare() nu va avea nici un efect, deoarece proprietatea xhr.responseText nu este accesibilă la momentul respectiv. Pentru a implementacomunicarea asincronă, cererea şi răspunsul serverului sunt procesate pe fire de execuţie dife rite.Modelul AJAX prevede ca procesarea răspunsului să aibă loc într -o funcţie de tip handler, apelatăautomat atunci când datele de la server au sosit. Chiar dacă din punct de vedere al codului sursăconstrucţia de mai sus pare comodă şi intuitivă, aceasta ar fi corectă doar pentru comunicare sincronă.Din punct de vedere al funcţionării comunicarea asincronă aduce principalul avantaj al modeluluiAJAX - faptul că execuţia codului nu se întrerupe între formularea cererii XHR şi receptarearăspunsului responseText . Mecanismul asincron se implementează, după modelul handlerelor, printr -un 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);}

Aşadar, e vorba de evenimentul readystatechange căruia i se asociază funcţia handler definită.Handlerul poate fi asociat imediat după crearea obiectului, deoarece execuţia sa nu va avea loc până laobţinerea unui răspuns de la server. În paralel, orice alte instrucţiuni care ar apare după xhr.send (sau înalte funcţii decât date()) vor fi executate atâta timp cât nu depind de răspunsul serverului. Toateoperaţiile care depind de acest răspuns vor fi încadrate în funcţie procesare().

Evenimentul readystatechange este asociat proprietăţii readyState cu valorile posibile: 0 – funcţia send() nu a fost încă apelată (nu s-au trimis date spre server); 1 – funcţia send() a fost apelată dar nu s-a recepţionat răspunsul; 2 – funcţia send() a fost apelată, răspunsul s-a recepţionat dar nu a fost convertit în tipul de

dată aşteptat (nu a avut loc parsingul dacă se aşteaptă, de exemplu, XML); 3 – funcţia send() a fost apelată, răspunsul a fost recepţionat, are loc procesul de parsing; 4 – funcţia send() a fost apelată, răspunsul de gata de utilizare.

Deoarece evenimentul readystatechange va apela funcţia handler de câte ori se schimbăvaloarea readyState, există riscul ca procesarea datelor să înceapă înainte ca acestea să fie completdisponibile clientului. În acest scop, funcţia de procesare a datelor trebuie să verifice dacă s -a ajuns înstarea 4 înainte de a începe operaţiile:

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 totuşi remarcat faptul că XHR permite şi implementarea de comunicări sincrone,dacă metoda open() primeşte un al treilea argument cu valoarea false. Aşadar, este posibilă procesareaimediată a datelor în exemplul:

function date(cod){

xhr=new XMLHttpRequest();xhr.open("GET","script.php?CodPostal="+cod,false);

xhr.send(null);procesare();

}



34

Din păcate în acest caz avantajele modelului asincron dispar, execuţia este întreruptă întreultimele două linii de cod până la receptarea completă a răspunsului şi avantajul esenţial al modeluluiAJAX dispare. De fapt, în aceste condiţii nici nu se mai poate folosi acronimul AJAX, fiind vorba doarde o formă evoluată a modelului Dynamic HTML (care permitea încă din anii 90 accesarea structuriidocumentului HTML prin JavaScript şi CSS). Întreruperea execuţiei este cauzată de latenţa de reţea -

aplicaţiile Web se particularizează faţă aplicaţiile desktop prin aceea că interfaţa utilizatorului şi datelenecesare se află în memorii diferite (a clientului şi a serverului) şi devin foarte frecvente apelurile de tipRPC (apel de proceduri la distanţă – când apelul de procedură şi execuţia procedurii au loc pecalculatoare diferite). Chiar dacă în multe cazuri latenţa de reţea e insesizabilă (mai ales că în AJAXcare nu face refresh de pagină integrală ci transferă doar un set redus de date), aceasta afectează

întotdeauna performanţa aplicaţiei şi fluiditatea experienţei utilizatorului. Latenţa de reţea afecteazăevident şi comunicarea asincronă, iar codul AJAX trebuie să prevadă şi să trateze situaţiile de posibilă

întârziere a datelor de la server. În exemplul de f aţă e posibil ca o întârziere excesivă să îl facă peutilizator să tasteze oraşul şi judeţul fără să mai aştepte completarea lor automată. Apoi, la sosireaacestora de la server, datele completate de utilizator vor fi înlocuite de funcţia procesare(), ceea ce

poate produce confuzii utilizatorului. Avantajul AJAX stă în faptul că, chiar în condiţii de latenţăsesizabilă a conexiunii, utilizatorul poate utiliza alte porţiuni ale aplicaţiei până când datele sosesc de laserver (aplicaţia nu îngheaţă).

Una din problemele spinoase ale modelului AJAX este compatibilitatea cu browsere diferitesau versiuni ale aceluiaşi browser. Problemele apar atât la modul în care browserele implementeazălimbajele implicate, cât şi la instanţierea obiectului XHR. Din acest motiv, instanţierea se realizează

într-o structură try-catch, prin care se încearcă mai multe instanţieri corespunzătoare diferitelor tipuride browsere:

function createXHR(){var xtry

{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ă funcţie implementează trei tipuri alternative de instanţiere XHR, disponibile pediferite platforme: primele două corespund browserului Internet Explorer; dacă ambele eşuează(x=false) şi dacă există clasa XMLHttpRequest, abia atunci se instanţiază aceasta. Funcţia de creare aobiectului XHR va fi apelată din funcţia date(), în locul instanţierii.

O altă situaţie care trebuie prevăzută este posibilitatea ca serverul să răspundă cu o eroareHTTP tradiţională – XHR foloseşte HTTP şi recepţionează codurile de diagnosticare clasice (404 încaz de resursă indisponibilă, 200 în caz de succes). În acest sens, funcţia de procesare a răspunsului ar trebui să prevadă situaţiile de eroare HTTP, verificând proprietatea status a obiectului XHR:

func t ion procesare(){i f (xhr . readyState == 4){

i f (xhr .s ta tus == 200){

var dates t r ing=xhr. responseTextvar datevec t=dates t r ing.sp l i t ( ' , ' )document .getE lementById("TXoras" ) .va lue=datevec t [0 ]



35

document .getE lementById("TXjudet" ) .va lue=datevec t [1 ]document .getE lementById("TXadresa" ) .va lue=datevec t [2 ]document.getElementById("Eroare") . innerHTML=""

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

}}

Acesta este momentul la care se apelează la paragraful vid cu id=Eroare. În caz de eroare, segenerează conţinut textual pentru paragraful respectiv, cu ajutorul proprietăţii innerHTML. Pe aceastăcale, practic se generează marcatori noi în structura paginii (conţinutul textual atribuit lui innerHTMLpoate fi oricât de complex).

Notă: Insistăm asupra ideii ca pachetul Firebug să fie instalat înFirefox încă de la primele exemple testate. În timpul execuţieiscripturilor, consola Firebug afişează datele care se schimbă întreclient şi server, ceea ce oferă un ajutor semnificativ în localizareaerorilor care pot să apară la tastarea codului sursă. Struc tura datelorschimbate între client şi server poate indica dacă o eventuală eroareapare în modulul client sau în scriptul server. Imaginea de mai josafişează datele schimbate prin metoda GET, în cele trei rubrici aleconsolei:

Params (datele trimise de la client) Response (raspunsul serverului)

Headers (antetul HTTP)Firebug este disponibil gratuit ca pachet add-on Firefox.

2.2. Fundaţia AJAX

2.2.1. JavaScript

JavaScript este un limbaj dedicat scripturilor client (interpretate şi executate direct în browser,deci însoţesc codul HTML fiind integrate în marcatorul SCRIPT). În cadrul tehnologiilor Web limbajula avut dintotdeauna o reputaţie proastă, datorită lipsei tipizării datelor, a naturii dezorganizate a codului

Clic pe adresa scriptului serverpentru afişarea datelor transferate

Butonul de deschiderea consolei Firebug



36

sursă integrat cu HTML şi a implementărilor inconsistente în diverse browsere. AJAX a revigoratsemnificativ rolul JavaScript, oferindu-i în sfârşit un cadru de exploatare matur.

Lipsa tipizării 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 seatribuie. 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 erorilordevine mai dificilă.

Limbajele puternic tipizate atrag atenţia asupra erorilor de tip. De exemplu tastarea greşită anumelui unei variabile generează o eroare datorită faptului că variabila cu numele greşit nu e declarată.În JavaScript, tastarea greşită a numelui unei variabile nu va genera eroare, ci va crea o nouă variabilă(cu numele greşit). Disciplina JavaScript recomandă ca variabilele să fie declarate formal cuinstrucţiunea var (deşi nu li se indică tipul) pentru a face depanarea codului sursă mai facilă, mai exact

pentru a separa mai clar variabilele create intenţionat şi cele create neintenţionat (prin erori de tastare anumelui).

Mecanismul conversiei implicite din expresii e exemplificat de atribuirea:

a=2b="a"c=a+b

Un limbaj tipizat generează o eroare type mismatch datorită tentativei de adunare între ovariabilă numerică şi o variabilă string. În JavaScript, rezultatul va fi "2a", numărul 2 fiind convertitautomat la tipul variabilei b, iar operaţia efectuată nu va fi adunarea, ci concatenarea. Din nou, aceastăsituaţie devine convenabilă sub aspectul comodităţii (nu sunt necesare conversii explicite) dar poateface dificilă detectarea unor erori de tip (conversii implicite neintenţionate). Tipurile datelor cu carelucrează JavaScript sunt boolean, numeric, string, referinţe la obiecte şi funcţii. La acestea se adaugătipul undefined, ce caracterizează o variabilă declarată (cu var) dar căreia nu i s -a atribuit încă valoare.Tipul pe care îl are la un moment dat o variabilă poate fi aflat cu ajutorul funcţiei typeof().

Datorită faptului că o variabilă e creată ad-hoc la prima sa atribuire, fără o declarare prealabilă, se poate deduce că acelaşi comportament îl suportă şi proprietăţile obiectelor. O simplăatribuire obiect.proprietatenoua=valoare va crea o nouă proprietate în obiect, fără a fi necesarădeclararea noii proprietăţi în clasa (prototipul) obiectului. Mai departe, constructorii de obiecte suntfuncţii obişnuite care preiau argumente şi le oferă proprietăţilor obiectului this:

function Obiect(arg1,arg2,...){this.proprietate1=arg1this.proprietate2=arg2.....return this}

a=Obiect(valoare1,valoare2)alert("prima proprietate a obiectului are valoarea:"+a.proprietate1)a.proprietatenoua=valoarenouaalert("obiectul a primit o noua proprietate!")

Funcţiile JavaScript sunt similare cu alte limbaje (se declară prin cuvântul cheie function, potavea 0 sau mai mulţi parametri, returnează o valoare la apelul acestora). Datorită lipsei tipizării, spredeosebire de C sau Java, nici la funcţii nu se declară tipul valorii returnate înaintea cuvântului cheiefunction. Aşadar, o funcţie va putea returna alternativ (pe diferite ramuri de execuţie), valori de diferitetipuri (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) funcţiilor. Considerăm exemplul:

function f1(a) {...........}

function f1() {..........}a=f1("aaa")



37

Intr-un limbaj care suportă polimorfismul funcţiilor, funcţia f1 ar exista în două forme diferite,diferenţiate prin apelul funcţiei – cu un argument sau fără argumente (altfel spus, identificarea funcţieice trebuie executată la un apel se face atât prin nume cât şi prin argumente ). In JavaScript, a douadefinire a funcţiei f1 o va înlocui pe prima (identificarea funcţiei de executat se face doar prin nume).

După cum am sugerat anterior, funcţiile sunt considerate în JavaScript tipuri de date. Altfel

spus, definirea unei funcţii are ca efect crearea unei variabile cu numele funcţiei şi valoarea dată deînsuşi blocul de execuţie al funcţiei (typeof va indica tipul function pentru această variabilă, iar afişareavariabilei va afişa în format text definiţia funcţiei, fiind vorba practic de un pointer în sens clasic).Aceasta are drept consecinţă un alt comportament care contribuie la reputaţia de limbaj "dezorganizat"pe care o are JavaScript.

function f() {......}f=10;a=f();

Majoritatea limbajelor vor accepta o astfel de secvenţă, neexistând nici un conflict întrevariabila f şi funcţia f(). În JavaScript se obţine o eroare, deoarece pe ultima linie, f nu mai este ofuncţie, ci o variabilă cu valoarea 10. Aşadar, dacă există o variabilă şi o funcţie cu acelaşi nume, cele

două sunt considerate a fi aceeaşi variabilă, care îşi poate schimba valoarea între tipul function şi oricealt tip. Exemplul următor creează o astfel de variabilă de tip function (pointer spre o definiţie defuncţie):

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 funcţie5 (de tip întreg), iar b va primi valoarea "function(){return 2+3}" (de tip function). Prin urmare,variabila b preia blocul funcţiei şi nu valoarea sa, devenind la rândul său o funcţie apelabilă prin construcţia b(). Cu alte cuvinte, b devine pointer al aceleiaşi funcţii ca şi v1. Prezenţa sau absenţa

parantezelor indică dacă e vorba de valoarea returnată de funcţie sau de blocul definiţiei funcţiei (accesat prin pointer).

Una din caracteristicile cele mai neplăcute ale JavaScript este legată de vizibilitateavariabilelor locale din funcţii. În majoritatea limbajelor, exemplul următor va provoca o eroare:

function f(){local=2x=local/2return x}

a=f()b=localalert(b)

Majoritatea programatorilor se aşteaptă ca ultima linie de cod să provoace o eroare devizibilitate a variabilei local. În mod normal, o variabilă creată într -o funcţie este accesibilă doar îninteriorul acelei funcţii şi se distruge după execuţia funcţiei . În JavaScript în schimb, variabilele localeale unei funcţii nu sunt distruse după execuţia sa. Se spune că apelul unei funcţii creează o închidere (closure), adică o stare a memoriei interne (incluzând variabilele locale funcţiei) care rămâne accesibilă după execuţia funcţiei. Insistăm asupra faptului că închiderea e creată de apelul funcţiei, şi nu dedeclaraţia sa. Deci următorul exemplu va provoca eroare de vizibilitate chiar şi în JavaScript (lipseşteapelul care creează închiderea):

function f(){local=2x=local/2return x

}b=localalert(b)



38

Închiderile sunt un aspect problematic, văzut adesea ca un pericol de securitate şi de depăşirede memorie în schimb programatorii avansaţi văd în aceasta o oportunitate, un nou mod de a gândicodul sursă al algoritmului – de exemplu, o funcţie poate avea acces la valorile variabilelor locale alealtei funcţii18.

Combinând închiderile cu faptul că orice funcţie poate fi tratată ca o variabilă, devin posibile: definirea de funcţii în funcţii:

function f(){a=2functielocala=function ()

{b=a+areturn b}

}v=f()function f3()

{

alert(functielocala())}

f3()

În acest caz funcţia functielocala, văzută ca variabilă locală a funcţiei f() rămâneaccesibilă (datorită închiderii) chiar şi în blocul funcţiei f3(). Aşadar o funcţie poate încapsulamai multe funcţii ce vor deveni accesibile codului sursă după execuţia funcţiei părinte.

funcţii care returnează funcţii:

function f(){a=2functielocala=function ()

{

b=a+areturn b}

return functielocala}

v1=f()()v2=f()v3=v2()

În acest caz, v1 primeşte rezultatul rezultatului funcţiei f , deci valoarea 4, iar v2 primeşte rezultatul funcţiei f , deci blocul funcţiei functielocala (return functielocala nu are paranteze, deci se returnează blocul funcţiei şi nu valoarea sa). v3 preia mai departe rezultatulacestui bloc, deci valoarea 4. Acest exemplu e elocvent pentru a diferenţia cazurile în care evorba de rezultatul unei funcţii faţă de cazurile în care e vorba de blocul său de execuţie (deci

de o valoare de tip function).

Interacţiunea JavaScript-HTML e posibilă pe două căi: prin încadrarea scripturilor înmarcatorul 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')" >

18 Există şi lmbaje de programare ce permit, prin sintaxe diferite, atât creare de funcţii cât şicreare de închideri (văzute ca funcţii cu stare persistentă)



39

Lansarea în execuţie a scripturilor JavaScript se poate realiza independent de pagina HTML – fiind un limbaj interpretat, codul JavaScript se execută instrucţiune cu instrucţiune, în ordinea în careacestea apar în codul sursă, până la final sau până la întâlnirea unei erori. Legarea cu pagina HTML serealizează de obicei prin intermediul evenimentelor - declanşarea unui eveniment pe suprafaţadocumentului se asociază unui apel de funcţie sau unui grup de instrucţiuni JavaScript. În exemplul

anterior, evenimentului clic al unui buton HTML i s-a asociat instrucţiunea / funcţia care afişează unmesaj. Una din probleme spinoase JavaScript, moştenite şi de AJAX, este faptul că diferite tipuri de browser recunosc diferite seturi de evenimente (deşi setul de bază, definit în standardul HTML 4.0, esterecunoscut azi de toate browserele).

2.2.2. XML şi DOM

XML este o paradigmă, un model pentru limbajele ce folosesc marcatori. Rolul modeluluiXML este să garanteze o structură internă arborescentă pentru documente. Structura arborescentă estegarantată prin impunerea aşa-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 înaltul, deci nu se permit construcţii precum:

<img><li>...........<b>...<i>...</b>...</i>

...acestea trebuind convertite la

<img></img><li>............</li><b>....<i>....</i>....</b>

Este evident că, datorită imbricării corecte, a doua variantă generează o structurăarborescentă pornind de la ideea că marcatorul I este inclus (subordonat) marcatorului B (aşa cumposibilitatea de a include un folder în altul generează structura arborescentă a directoarelor de pe un

disc). Dacă toţi marcatorii unei pagini Web sunt închişi şi imbricaţi corect, pagina poate fi reprezentatăprintr-un arbore de marcatori, având ca rădăcină marcatorul HTML, cu nodurile fiu HEAD şi BODY,care la rândul lor au alte noduri subordonate (alţi marcatori imbricaţi). În scopul alinierii paginilor Webla acest model, s-a definit limbajul XHTML care nu este altceva decât o variantă HTML care respectăregulile de bună-formare. Aceste reguli nu se referă doar la imbricare, ci şi la alte aspecte decompatibilizare cu modelul XML, cum ar fi:

sintaxa XHTML este case-sensitive, cu litere mici; marcatorul rădăcină este unul singur (deci nu se poate neglija marcatorul HTML, care ar fa ce

ca pagina să conţină doi marcatori pe primul nivel: HEAD şi BODY); orice marcator trebuie închis, chiar dacă nu are conţinut între etichetele sale; pentru marcatorii fără conţinut, 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 capătă rol de cheie primară – nu potexista doi marcatori cu aceeaşi valoare ID;

atributele XHTML au obligatoriu valorile cuprinse între ghilimele (în timp ce HTML permiteconstrucţii cu atribute fără ghilimele sau prescurtate precum <INPUT TYPE=CHECKBOXCHECKED>, XHTML permite doar <input type="checkbox" checked="checked"/>);

codul sursă trebuie să înceapă cu un antet de instrucţiuni care să confirme că documentul estede tip XML:

<?xml ?><!DOCTYPE ...><html>......</html>

19 În continuare vom utiliza forma XML pentru marcatorii cu etichetă unică



40

Instrucţiunea xml indică faptul că documentul respectă regulile XML. InstrucţiuneaDOCTYPE are rolul de a particulariza acest lucru, indicând faptul că e vorba de un document XHTML- adică respectă regulile XML şi în plus foloseşte vocabularul de instrucţiuni HTML20.

Este recomandat ca paginile Web să se conformeze regulilor de bună-formare XML. Totuşi,browserele moderne sunt capabile să convertească la XML orice cod HTML clasic, motiv pentru care

în majoritatea exemplelor nu vom respecta întru totul regulile XHTML21

. Dacă pagina are cod sursăbine-format (sau a fost convertită de browser la un cod bine-format), acesta poate fi reprezentat înmemoria internă a clientului sub forma unui arbore cu noduri - fiecare nod corespunzând unuimarcator, cu un nod rădăcină unic şi cu nodurile-frunte corespunzând conţinutului textual almarcatorilor:

<html><head></head><body>Text1<font face=arial>Text2</font><img src=..../></body></html>

Va duce la un arbore de forma:

Arborele poate fi accesat de JavaScript prin intermediul funcţiilor, capabile să parcurgăarborele şi să manipuleze nodurile acestuia pe cale obiectuală (fiecare nod e un obiect care conţinenodurile subordonate). Modificând prin DOM arborele paginii, practic se manipulează structuradocumentului – orice porţiune de document va putea fi mutată, ştearsă, modificată, se pot crea porţiuninoi în document (adăugând noduri noi în arbore). Porţiunile documentului sunt identificate cu ajutorulmarcatorului care le încadrează (şi a atributului id pe care acesta îl are). Modelul arborescent al paginiimai poartă şi denumirea de model DOM sau arbore DOM (preferabil faţă de denumirea mai generală

de "arbore XML"). Toate componentele arborelui sunt subordonate obiectulu i ce reprezintă pagina înansamblu (deci conţine întregul arbore) – e vorba de obiectul document. Acesta conţine obiecte de tipelement (corespunzătoare marcatorilor) şi fiecare obiect-element are o serie de proprietăţi ce stocheazăatributele şi conţinutul textual al marcatorului.

Manipularea prin DOM poate fi aplicată chiar şi ca înlocuitor pentru handlerele deevenimente. Aşadar, legarea unei funcţii JavaScript la evenimentul clic al unui buton, ar putea arăta,prin intermediul DOM, astfel:

20 XHTML nu este singurul limbaj al paradigmei XML, oricine îşi poate defini propriul limbajXML în măsura în care asigură un mecanism de interpretare a instrucţiunilor acestuia. În cazulXHTML, semnificaţia instrucţiunilor este cea oferită de HTML.

21 În special vom neglija pentru simplificare antetul XHTML, dar se vor putea remarca şi alteabateri care nu afectează funcţionarea exemplelor în principalele browsere – Internet Explorer 7 şiFirefox 2.

html

head body

Text1 Font Img

Text2



41

<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 când designul paginii şi programarea paginii sunt asigurate de persoane diferite(care vor trebui să-şi comunice reciproc doar identificatorii elementelor). Altfel spus, designerul nu vamai fi nevoit să ştie cum se numeşte funcţia handler de care are nevoie (programatorul va trebui oricumsă ş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 funcţia getElementById nu va detecta nimic. Acest dezavantaj poate fi îndepărtat prin ascultareade evenimente: funcţia attachEventListener() asociază un eveniment cu o funcţie (sau chiar mai multe).Pentru evitarea acestor complicaţii, vom apela în continuarea la asocierea tradiţională a evenimentelor prin atribute HTML precum onclick.

Exemplu:

<html><head><script type="text/javascript">

function modificaPagina(){var v1 = document.documentElementvar vector = v1.childNodesvar nodbodyfor (i = 0; i < vector.length; i++)

if (vector[i].nodeName == "BODY"){nodbody = vector[i]break;}

vector = nodbody.childNodesvar noddivfor (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, conţinutul vizibil al paginii este un buton care reacţionează la clic şi un textmarcat cu marcatorul div. Efectul clic-ului pe buton este înlocuirea textului cu un alt text şi modificareaformatului (alinierea la dreapta a textului).

Spre deosebire de majoritatea marcatorilor HTML care au rol de formatare sau definire a unorcomponente de pagină, există doi marcatori cu rol strict de delimitare: div şi span. Rolul lor este sădelimiteze porţiuni ale documentului în vederea accesării lor ulterioare prin JavaScript (prin atribute id)

sau în vederea formatării cu stiluri CSS (prin atribute class). Porţiunile de document încadrate în divsau span pot să aibă orice complexitate – de la un caracter până la conţinutul integral al corpului



42

paginii, cu condiţia să respecte regulile de bună-formare XML (deci nu se permit construcţii ca<div><table></div>...</table>).

Diferenţa între div şi span e că blocul definit cu div ocupă toată lăţimea paginii, deci are unefect vizual similar cu un paragraf (conţinutul din faţa şi de după div apare pe rânduri diferite).Marcatorul span nu are nici un efect vizual, blocul span nu ocupă toată lăţimea paginii, ci doar

suprafaţa ocupată de caracterele încadrate, de aceea e frecvent folosit pentru a face delimitări mai fine,la nivel de caracter. Un document HTML poate conţine oricâte blocuri div şi span în orice combinaţiedar, pentru AJAX, imbricarea acestora trebuie să respecte regulile de bună formare XML.

Cu alte cuvinte, cei doi marcatori nu se folosesc din raţiuni de format, ci din raţiuni destructură – se folosesc pentru a împărţi documentul în unităţi structurale care să devină în memoriainternă noduri ale arborelui DOM (deci vor putea fi accesate direct şi manipulate independent unele dealtele).

Structurarea documentului are un rol important şi în ce priveşte formatarea prin stiluri CSS.Fiecare bloc div sau span poate fi asociat unui stil CSS pentru a fi formatat (atributul class). Apoi, prinintermediul JavaScript, asocierea div-CSS sau span-CSS poate fi modificată pentru a modifica în moddinamic formatul paginii. Pentru a înţelege mai uşor diferenţa între div şi span, recomandăm afişarea în

browser a următorului exemplu, în care un bloc div şi un b loc span sunt asociate unor stiluri CSS ce leformatează fundalul:

<html><head><style type=text/css>

.S1 {background:red}

.S2 {background:blue}</style></head><body>

Text oarecare care conţine <div class=S1> un <br> bloc <br> div </div> Text oarecare care conţine <span class=S2> un <br> bloc<br> span </span>

</body></html>

Ambele blocuri delimitează o porţiune din fraza afişată. S-au inserat marcatori br pentru asugera că un bloc div sau span se poate întinde pe mai multe rânduri şi poate conţine orice combinaţiide marcatori permise de regulile de sintaxă XML. Culoarea fundalului indică porţiunea de documentafectată de cele două blocuri. Se observă că blocul div ocupă toată lăţimea paginii iar blocul span doar suprafaţa ocupată de caracterele încadrate.

Se va remarca ulterior că în modelul AJAX blocurile div în special joacă un rol esenţial, motiv pentru care paginile HTML în AJAX nu au, la prima vedere, o structură tradiţională. În paginile HTMLclasice, 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 colecţie de blocuri div (şi mai rar span) însoţite de stilurile CSS care le definesc formatarea şi atributele idnecesare accesării 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 aplicaţiilor Web – cele 4nivele pot fi gestionate de persoane diferite, cu un minim de interferenţă între acestea iar depanareaaplicaţiei se realizează mult mai uşor, odată ce se identifică pe care nivel au apărut eventualele erori.

Funcţia din exemplul anterior înlocuieşte conţinutul 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. Căutarea are loc prin parcurgerea tuturor nodurilor fiu (a tuturor marcatorilor imediat

subordonaţi). Odată ce blocul div a fost identificat şi stocat în variabila noddiv, conţinutul său textualeste înlocuit prin metoda DOM replaceChild() iar alinierea sa se modifică prin crearea atributului



43

align=right. Se observă că din punct de vedere DOM, conţinutul textual al unui element este consideratnod fiu al acestuia şi nu valoarea acestuia. Proprietăţile şi funcţiile DOM folosite au fost:

documentElement – stochează nodul rădăcină al paginii; childNodes – stochează un vector cu toate nodurile fiu ale obiectului curent, numerotate

începând cu 0; pentru parcurgerea arborelui, DOM mai oferă o firstChild şi lastChild – acces la primul şi ultimul nod fiu,

o hasChildNodes() - testează existenţa nodurilor fiu,o parentNode – acces la nodul părinte, o nextSibling şi previousSibling – acces la următorul şi precedentul nod frate;

nodeName – stochează numele nodului curent (eticheta marcatorului); pentru obţinere deinformaţii 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 (conţinut textual); pentru creare de noduri,

DOM mai oferă createElement() (creează un nod de tip element); replaceChild() – înlocuieşte 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 sfârşitul 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 - citeşte valoarea unui atribut, o removeAttribute() - şterge atribut, o createAttribute() – creează un atribut, o hasAttribute() -testează existenţa unui atribut,

la acestea mai adăugăm o serie de funcţii pentru manipularea şirurilor de caractere, utile înmodificarea conţinutului textual al marcatorilor:

o appendData () – adaugă caractere la conţinutul textual,

o data – similar cu nodeValue pentru nodurile de tip text,o deleteData() – şterge caractere din conţinutul textual, o insertData() – inserează caractere în conţinutul textual, o replaceData() – înlocuieşte un subşir al conţinutului textual cu altul, o subStringData() – citeşte un subşir al conţinutului textual, o normalize() – concatenează conţinuturi textuale adiacente, pentru a obţine un unic

nod fiu de tip text,o splitText() – separă un nod de tip text în două noduri de tip text (inversul funcţiei

normalize).

În continuare se vor indica o serie de diferenţe între codul AJAX din acest exemplu faţă deexemplul precedent, al formularului cu codul poştal .

1.Definirea porţiunilor 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 roşu), s-a rezervat zona respectivă sub forma unui paragraf vid cu identificator unic. Înexemplul actual, zona ce s-a dorit a fi manipulată s-a definit ca un bloc div – avantajul fiind că acesta

poate încadra o porţiune oricât de complexă şi nu interferează cu formatul documentului (P defineşteun paragraf, deci lasă un rând gol înaintea şi după conţinutul său textual).

2.Localizarea porţiunii 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 atr ibut de identificare (nuînseamnă că nu ar putea avea), aşadar e localizat prin parcurgerea arborelui DOM începând de la

rădăcină: mai întâi se caută, printre fiii rădăcinii, acel fiu cu numele BODY, apoi se caută între fiiinodului BODY, primul fiu cu numele DIV. Aceasta implică două cicluri de parcurgere şi reprezintă undezavantaj, nu doar sub aspectul complexităţii codului. Mai exact, browserele care convertesc cod



44

HTML în cod compatibil XML apelează la diferite metode de conversie. Unele browsere conve rtesccaracterele albe în noduri de tip text. Mai exact, marcatorul body din exemplul de mai jos va avea treinoduri fiu şi nu unul, cum ar dicta intuiţia:

<body><b>xxxxxxx</b>

</body>

Cele trei noduri vor fi, în ordine, un nod de tip text (caractere albe din faţa lui b), un nod de tipelement (marcatorul b) şi un al doilea nod de tip text (Enterul de după închiderea lui b) – generareaacestor noduri poate fi verificată cu instrumente DOM Inspector. Aşadar, chiar dacă rolul caracterelor albe este de a indenta codul sursă pentru o citire mai facilă, există riscul ca acestea să fie convertite înnoduri DOM. Pentru a nu obţine 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 operaţiilor de parcurgerea a arborilor DOM (de exemplu, afectează lungimea vectorului childNodes). Un alt exemplusimilar este faptul că prin conversie la XML, unele browsere adaugă în mod forţat marcat ori noi: deexemplu e posibil ca în cadrul unui tabel să se adauge forţat marcatorii thead şi tbody (antet şi corp detabel, o separare neglijată de mulţi designeri HTML care se rezumă la a descrie rândurile tabelului printr)!

Dacă parcurgerea arborelui DOM se face pe bază de poziţie (de exemplu parcurgereavectorului childNodes sau cu nextSibling) este posibil ca numărul nodurilor fiu să nu fie exact cel lacare se aşteaptă programatorul, problema fiind agravată de faptul că nu toate browserele aplică acelaşitratament codului HTML. În acest caz, recomandăm 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 acestcaz este că e posibil ca documentul să conţină mai mulţi marcatori similari (mai multe paragrafe, maimulte blocuri div), caz în care metoda returnează un vector al tuturor nodurilor găsite. Vector care,evident, va trebui parcurs în căutarea blocului dorit. Totuşi, aici nu mai avem pericolele parcurgeriivectorului childNodes, ci avem efectiv un vector cu toţi marcatorii cu aceeaşi etichetă, î n ordineaapariţiei lor în document. Desigur, rămâne incomodă necesitatea de a cunoaşte poziţia marcatoruluicăutat. În unele situaţii, în care se doreşte manipularea simultană a tuturor marcatorilor cu aceeaşietichetă, getElementsByTagName devine soluţia ideală (spre exemplu, dacă se doreşte manipulareaidentică a tuturor câmpurilor unui formular, a tuturor paragrafelor sau blocurilor div dintr -undocument). Mai mult, getElementsByTagName devine necesară atunci când getElementById nu sepoate folosi (exem plu: atunci când se manipulează alţi arbori XML decât arborele paginii).

3.Generarea de conţinut nou în zona de document localizată

O altă diferenţă între cele două exemple este mecanismul prin care se creează conţinut nou în

pagină (marcatori şi/sau conţinut textual). În exemplul cu codul poştal, mesajul de eroare şi formatulsău sunt create cu ajutorul proprietăţii innerHTML a marcatorului localizat (al paragrafului). Înexemplul actual, conţinutul 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). ProprietateainnerHTML a fost introdusă în Internet Explorer dar a fost ulterior adoptată şi de Mozilla. Este,evident, mai comodă decât apelarea metodei replaceChild (sau addChild) pentru fiecare nodmodificat/creat deoarece poate crea un subarbore XML din conţinut HTML oricât 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 poştal, atribuirea textului "<font color=red>...</font>" nua avut ca efect doar inserarea de text, ci chiar crearea unui nod-element nou, la rândul său cupropriul nod fiu de tip text. În schimb, innerText are performanţe superioare, de aceea e

frecvent folosită pentru adăugare de conţinut textual, iar innerHTML pentru adăugare deconţinut complex, ce include marcatori;



45

În timp ce innerHTML înlocuieşte conţinutul marcatorului/nodului curent, outerHTMLînlocuieşte complet marcatorul/nodul curent, deci etichetele şi conţinutul/fiii acestuia! Avândîn vedere că datele serverului sunt cele care determină modificări precum innerHTML şiouterHTML, putem spune că outerHTML conferă o putere mai mare serverului în arestructura pagina, în timp ce innerHTML conferă responsabilitatea structurii clientului,serverul manipulând doar conţinutul.

La enumerarea proprietăţilor DOM, am sugerat şi alte căi de a accesa şi manipula conţinutulmarcatorilor.

4.Manipularea de atribute

Exemplul cu codul poştal accesează şi modifică atributul value al marcatorilor input princalificarea proprietăţii value:

document.getElementsById("idcamp").value="valoarea noua a campului"

Al doilea exemplu accesează şi modifică (creează) atributul align al blocului div prin metodasetAttribute:

noddiv.setAttribute("align","right")

Metoda setAttribute este înrudită cu getAttribute, care citeşte valoarea unui atribut.

În consecinţă exemplul actual poate fi scris într-o formă mai comodă astfel:


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) corespunzător marcatorului. Această afirmaţie are un caracter general, dar nu unulabsolut – există cazuri în care numele atributului nu este acelaşi cu numele proprietăţii. În general laacest capitol apar diferenţe supărătoare între browsere. Probabil cele mai importante excepţii suntatributele class şi style, care asociază marcatorilor stiluri CSS.

Mozilla Firefox permite o construcţie precum

<html><head>

<style type="text/css">.stil1 {background:blue}.stil2 {background:red}</style>

<script type="text/javascript">



46

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, prinaceea că asocierea div-stil1 e înlocuită cu asocierea div-stil2 (diferenţa între cele două stiluri e culoareade fundal, după cum arată descrierile de stil din antetul paginii). Acesta e mecanismul de bază prin care

paginile AJAX capătă dinamică din punct de vedere vizual – modificarea atributelor class pot aveaefecte majore asupra modului în care arată interfaţa iar legarea acestor modificări la evenimenteleutilizatorului conferă o interactivitate mărită documentelor HTML. Totuşi, modificarea atributului class

în acest mod funcţionează doar în Firefox!

Mai mult, nici în Firefox, nici în IE, NU funcţionează modificarea atributului de stil princealaltă metodă:

noddiv.class="stil2" nu are nici un efect!

În schimb, Internet Explorer permite modificarea atributului de stil prin modificarea proprietăţii className:

noddiv.setAttribute("className","stil2")

Pe de altă parte, această metodă nu e tolerată de Firefox! În ciuda ignorării acestei

incompatibilităţi de către producătorii de browsere, s-au găsit soluţii de compromis: -soluţia 1: prezenţa ambelor metode în acelaşi script (neelegantă)

noddiv.setAttribute("class","stil2")noddiv.setAttribute("className","stil2")

-soluţia 2: folosirea ambelor metode alternativ, în funcţie de existenţa unui obiect specificunuia 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 etrue, se foloseşte argumentul pentru IE, altfel, cel pentru Firefox; acest gen de verificări poartădenumirea de browser sniffing şi nu sunt foarte fiabile – e posibil ca în noi versiuni ale browserelor

situaţia existenţei sau inexistenţei unui astfel de obiect să se schimbe22)- soluţia 3, recomandată:

noddiv.className="stil2"

Această construcţie va funcţiona în ambele browsere: className există ca proprietate a unuiobiect-element în ambele browsere, în timp ce class există ca proprietate doar în Firefox, iar classNameexistă ca atribut doar în IE.

O problemă similară apare la folosirea celuilalt atribut de aplicare a stilurilor CSS, style – princare stilul se descrie direct în marcator şi nu se apelează din antetul paginii. Pentru style, metoda carefuncţionează în ambele browsere este:

22 http://www.quirksmode.org/js/detect.html oferă o funcţie complexă pentru detectarea precisă a browserului şi platformei clientului



47

noddiv.style.cssText="background:red"

Mai mult, JavaScript are acces direct la oricare din proprietăţile stilurilor CSS 23. Aşadar,ultimul exemplu ar putea arăta şi astfel, în ambele browsere:

noddiv.style.background="red"

Unul din cele mai frecvente mecanisme în manipularea paginii AJAX este controlulvizibilităţii unor porţiuni de document (de obicei blocuri div). Aceasta se obţine printr -o funcţie carecomută un bloc div între stările 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 incompatibilităţile dintrebrowsere în ce priveşte manipularea atributelor, recomandăm

http://www.quirksmode.org/dom/w3c_core.html

2.2.3. XML DOM versus HTML DOM

S-a demonstrat până aici că accesul la elementele paginii prin intermediul modelului DOM poate avea loc pe mai multe căi. Aceasta se datorează pe de o parte versatilităţii modelului DOM, dar şifaptului că acesta e disponibil în două variante:

XML DOM, modelul fundamental, ce poate fi folosit pe orice tip de cod XML (inclusiv codulXHTML 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.); funcţiile XML DOM pot fi utilizate atât asupraarborelui paginii cât şi asupra altor arbori XML (date primite prin proprietatea responseXML).Modelul XML DOM este suportat de majoritatea limbajelor de programare ce permitprelucrare de cod XML;

HTML DOM, o versiune DOM optimizată pentru paginile XHTML, ce oferă, în plus faţă deXML DOM, versiuni prescurtate sau metode mai directe decât cele generale; funcţiile HTMLDOM pot fi folosite asupra arborelui paginii AJAX, dar nu pot fi folosite asupra altor arboriXML, cum ar fi răspunsul serverului în format XML (proprietatea responseXML a obiectuluiXHR).Detaliem o parte din facilităţile 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 conţinutului unui marcator prin innerHTML şi a marcatorului împreună cu

conţinutul său prin outerHTML; XML DOM impune să se folosească în acest scop nodeValuesau 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 funcţionalitatea browserului (istoricul paginilor vizitate, butoanele Back şiForward, etc.);

prescurtarea accesului la o serie de marcatori unici sau frecvent întâlniţi, 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);

23 Prin acces direct ne referim la faptul că orice proprietate CSS devine proprietate JavaScriptşi accesul la acestea nu mai trebuie intermediat de cunoaşterea numelui stilului (deci p roblemaatributului class e ocolită).



48

o document.links[ ] – un vector cu toate hiperlegăturile şi hărţile de imagini (marcatoriiarea) ale paginii;

o document.form[0].elements[ ] – un vector cu toate elementele din primul formular alpaginii (getElementsByTagName("form")[0].childNodes[] în XML DOM, cuevitarea "nodurilor albe");

o document.anchors[ ] – un vector cu toate ancorele (marcatorii a cu atributul name);

o tabel.rows[] un vector cu elementele tr ale obiectului tabel (creat anterior);o tabel.rows[0].cells[] – un vector cu celulele primului rând al obiectului tabel.

Notă: Referinţa oficială HTML DOM completă poate fi consultată laadresa: http://www.w3schools.com/HTMLDOM/dom_reference.asp

La aceste diferenţe adăugăm o excepţie deosebită: getElementById poate fi folosită doar înarborele DOM al paginii, deşi teoretic este definită şi în modelul XML DOM. Explicaţia 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 însoţeşte un document XML şi descrie pentru acesta listamarcatorilor permişi, a imbricărilor permise şi eventual a semnificaţiei lor. E un caz particular faptul căvocabularul XHTML (vocabularul XML care reglementează utilizarea marcatorilor HTML), defineşteatributul id ca având rol de identificator într-o pagină HTML. La modul general, pachetele de date

structurate prin marcatori XML trebuie să fie însoţite de vocabularul aferent. Operaţia prin care undocument XML este comparat cu regulile unui vocabular este similară cu cea prin care un documentHTML este interpretat conform sintaxei HTML şi poartă numele de validare.

Validarea HTML (faţă de vocabularul XHTML) este integrată implicit în browsere dar nu şivalidarea de cod XML generic (faţă de diverse vocabulare). Aşadar browserul nu are cum să determine,

în lipsa vocabularului aferent, care atribut are rol de identificator într-un cod XML non-HTML, ceea ceface ca getElementById să nu funcţioneze pe răspunsul obiectului XHR!

Notă: getElementById funcţionează în alte medii de programare, ceinclud validare şi gestiunea vocabularelor XML. În generalvalidatoarele XML sunt instrumente off-line - o validare aplicată lafiecare transfer XHR ar afecta grav performanţa aplicaţiei (arpresupune un dublu transfer – al datelor XML şi al vocabularului faţăde care se validează, la care se adaugă efortul de validare). ExtensiaFirefox numită XML Developer Toolbar oferă instrumente de validare în

browser şi poate fi descărcată gratuit de pe site -ul oficial albrowserului. Acestea sunt însă validatoare off -line, inaccesibileobiectului XHR.

2.2.4. Obiectul XHR

Detaliile legate de mecanismul de transfer al datelor între clientul AJAX şi server vor fidiscutate pe un exemplu simplificat din cele anterioare:


var xhrfunction modifica(){

try

{xhr = new ActiveXObject("Msxml2.XMLHTTP")} catch (e){try

{xhr = new ActiveXObject("Microsoft.XMLHTTP")} catch (e){xhr = false

}}

if (!xhr && typeof XMLHttpRequest !="undefined"){



49

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 conţine un bloc div gol, care este completat la apăsarea unui buton cu textul primit dela server. Sintetizăm în continuare componentele mecanismului XHR:

1. Crearea obiectului XHR

- are loc prin trei tentative de instanţiere, 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 va riabilePOST); în exemplul de faţă open nu trimite nici o variabilă, send trimite caracterul null, aşadar tot ce setransmite spre server e o solicitare a unui script PHP.

3. Generarea datelor de către server

- scriptul PHP nu primeşte date de la client, aşa că exemplul poate fi verificat cu un scriptsimplu care generează un şir de caractere:

<?phpprint "textul mesajului";

?>

4. Recepţionarea datelor de la server

- are loc doar când proprietatea readyState capătă valoarea 4 (condiţie care poate fi completatăcu status != 200 dacă se doreşte prevenirea erorilor de conexiune);

în exemplul de faţă, datele sunt preluate de proprietatea responseText sub formă de text brut, pe care se pot aplica operaţii de manipulare a şirurilor de caractere;

în alte situaţii, pe care le vom exemplifica în alte contexte, datele pot fi preluate prin proprietatea responseXML, direct ca arbore DOM, pe care se pot aplica operaţii de manipulareDOM;

în ultimii ani, adepţii AJAX au promovat şi un al treilea format de date, JSON , care se preiadin responseText şi se converteşte în obiect JavaScript prin funcţii specifice de conversie;JSON are faţă de XML avantajul simplităţii iar faţă de textul brut avantajul complexităţiistructurilor de date – capitolele ce urmează vor prezenta şi exemple în acest sens;

Notă: Nu toate funcţiile şi proprietăţile DOM cu care se lucreazăasupra paginii HTML pot fi folosite şi asupra pachetului de dateresponseXML. Răspunsul serverului va fi prelucrat obligatoriu prin XMLDOM, metodele HTML DOM returnând erori. În paragraful XML DOM vs. HTMLDOM s-au detaliat o parte din diferenţe.

5. Utilizarea datelor de la server



50

- are loc prin utilizarea datelor extrase din responseText; în acest caz, valoarea sa este atribuităconţinutului textual al marcatorului cu id=mesaj

- fiind vorba de comunicare asincronă (metoda open nu a folosit argumentul false), momentulla care are loc citirea lui responseText este declanşarea evenimentului readystatechange cureadyState=4

6. Reacţia paginii HTML la datele serverului

- blocul div anterior definit în pagină ca o zonă vidă a documentului e completat cu dateleserverului; acest proces e declanşat de evenimentul click pe butonul paginii.

În plus faţă de acest mecanism de bază obiectul XHR poate trimite şi recepta date direct prinantetul HTTP (care în mod normal e construit de către protocol, atât în browser cât şi la server, pentrua descrie mediul de comunicare dintre cele două părţi). 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 încât serverul să nu mai poatăextrage din variabile de mediu identitatea browserului:

xhr.setRequestHeader("User-Agent","Browserul meu!")

"User-Agent" este câmpul din antetul HTTP care indică tipul de browser care a trimis cererea,folosit adesea de către scripturile server pentru a returna conţinut diferit în funcţie de browser."Browserul meu!" este valoarea pe care o inserăm forţat î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 phpdestinatar încât să returneze valoarea câmpului User-Agent din antetul HTTP:

<?phpprint $_SERVER["HTTP_USER_AGENT"];

?>

În urma modificărilor, exemplul anterior va afişa în blocul div textul "Browserul meu!" laapăsarea butonului. Dacă ştergem apelul metodei setRequestHeader, textul afişat în blocul div va fiidentitatea browserului.

Notă: Pentru lista câmpurilor antetului HTTP, recomandăm consultareaadresei http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. Deasemenea, o multitudine de instrumente de tip HTTP Header Viewer suntdisponibile pentru descărcare gratuită, pentru a permite vizualizareaantetului HTTP direct în browser. Exemple de astfel de instrumente suntTamper Data – extensie add-on instalabilă de pe site -ul oficial MozillaFirefox sau HTTP Watch (www.httpwatch.com) pentru Internet Explorer – gratuit în versiunea Basic Edition.

Exemplul cu completarea codului poştal declanşa un schimb de date cu serverul fără cautilizatorul să fie neapărat conştient de asta. În aplicaţiile Web tradiţionale, schimbul de date cu

serverul e declanşat prin acţiuni conştiente ale utilizatorului: clic pe un buton submit sau pe ohiperlegătură. Obiectul XHR permite, după cum s-a văzut, ca schimbul de date să aibă loc la oricemoment în moduri mult mai subtile şi care nu interferează cu experienţa utilizării aplicaţiei. Totuşi,aplicaţiile AJAX trebuie şi pot să implementeze transferul complet al datelor unui formular prinapăsarea unui buton de trimitere. Obiectul XHR poate fi utilizat pentru a trimite datele unui formular prin metoda POST, operaţiune frecventă în aplicaţiile Web. În acest caz, modificările în procedura detrimitere a datelor vor fi:

formularul nu va mai avea un buton submit, ci un buton oarecare de tip button, căruia i se vaasocia funcţia de trimitere a datelor ca handler onclick; folosirea unui buton submit ar realizaun transfer de date în sens clasic, sincron, cu refresh sau încărcare de pagină nouă!

formularul nu va mai avea atributele method şi action, deoarece acestea sunt fixate de obiectulXHR;

datele se preiau una câte una, prin intermediul DOM, din atributele value ale câmpurilor

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 funcţie encodeURIComponent(),



51

pentru a conserva anumite caractere speciale care ar putea fi tastate în for mular şi ar puteainduce confuzii în interpretarea şirului de interogare (=, +, &);

se modifică o serie de câmpuri ale antetului HTTP (care, în aplicaţiile tradiţionale, se modificăautomat la apăsarea butonului Submit) - obligatoriu se modifică tipul conţinutului postat ,opţional se pot modifica numărul de variabile şi tipul conexiunii (dacă scriptul server arenevoie de astfel de informaţii);

se trimit datele ca argument al funcţiei send().

Exemplu:

<html><script type="text/javascript">

function creareXHR(){................// instantierea xhr}

function trimite(){creareXHR()valori=new Object()valori["nume"]=document.getElementById("TXnume").valuevalori["codpostal"]=document.getElementById("TXcodpostal").valuevalori["adresa"]=document.getElementById("TXadresa").valuevalori["oras"]=document.getElementById("TXoras").valuevalori["judet"]=document.getElementById("TXjudet").valuesir=""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=procesarexhr.send(sir)

}

function procesare(){if (xhr.readyState!=4) returnalert("serverul a raspuns cu:"+xhr.responseText).................//procesarea raspunsului serverului}

</script></head>

<body><h1>Introduceti datele</h1><form>

<table><tr>


</tr><tr>

<td>CodPostal</td><td><input type=text id=TXcodpostal></td>

</tr><tr>


</tr><tr>

<td>Oras</td>

<td><input type=text id=TXoras ></td></tr><tr>



52


</tr><tr>

<td></td><td><input type=button value=Trimite onclick="trimite()" ></td>

</tr>

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

Scriptul server:

<?phpprint "datele primite la server sunt:".$_POST["nume"].

",".$_POST["codpostal"].",".$_POST["adresa"].",".$_POST["oras"].",".$_POST["judet"];?>

Notă: Avertizăm că în timpul testării metodei POST, consola Firebug nuafişează o eroare atunci când scriptul server nu primeşte variabilelePOST aşteptate (de exemplu pentru că s -a tastat greşit numele lor). Înschimb, rubrica Response din Firebug afişează mesajul "Loading..." caresemnifică faptul că serverul se află într-o stare de aşteptare.

2.2.5. Cadrele interne invizibile

Cadrele interne invizibile sunt folosite ca alternativă de comunicare cu serverul, atunci cândobiectul XHR nu este instalat în browser24. Cadrele interne s-au folosit frecvent înainte apariţieiobiectului XHR pentru a schimba date cu serverul şi sunt chiar şi în prezent preferate de uniidezvoltatori AJAX. Acestea prezintă totuşi o serie de dezavantaje:

Cadrele interne nu au fost create în acest scop; rolul lor este, asemeni cadrelor normale, săafişeze o pagină Web în interiorul altei pagini – diferenţa faţă de cadrele normale este că celeinterne nu se definesc prin împărţirea ferestrei browserului pe orizontală sau verticală (cuFRAMESET), ci prin definirea unei suprafeţe dreptunghiulare în interiorul paginii (cuIFRAME). Cadrele interne devin invizibile dacă sunt create cu dimensiunea 0x0, ceea ce

permite ca pagina încărcată de cadru să nu fie o pagină HTML propriu-zisă, ci un set de dateinvizibil utilizatorului. Acest set de date poate fi apoi accesat prin JavaScript, din proprietăţilecadrului intern;

Împrospătarea conţinutului unui cadru, fie şi unul invizibil, generează un sunet în unelebrowsere care poate deveni iritant pentru utilizator;

Accesul la conţinutul unui cadru intern e mai dificil decât accesul la răspunsul XHR; browserul presupune că un cadru intern, fie şi invizibil, conţine o pagină HTML completă (cuhead, body etc.). Chiar dacă pagina respectivă este doar un şir de caractere cu dateleserverului, acesta se accesează prin proprietatea innerHTML a marcatorului BODY al paginiiconţinute în cadru;

Un cadru intern poate stoca doar şiruri de caractere interpretabile ca HTML. Cadrul intern nuaplică parsing DOM implicit la pachete XML, aşa cum face obiectul XHR prin proprietatea

responseXML. În consecinţă, dacă aplicaţia trebuie să gestioneze date XML, trebuie săinstanţieze explicit un arbore DOM în care să salveze răspunsul XML. Instanţierea unui arboreDOM se realizează în JavaScript prin două metode, ce vor trebui incluse într -o structură try-catch:

arbore=new document.implementation.createDocument() – pentru Firefoxarbore=new ActiveX("Microsoft.XMLDOM") – pentru Internet Explorerarbore.load(raspuns) – variabilei raspuns in prealabil i-a fost atribuit conţinutul cadrului

Notă: În timpul depanărilor în Firefox cu extensia Firebug, opţiuneaConsole nu mai poate fi folosită pentru monitorizarea schimburilorîntre client şi server (aceasta monitorizează doar cererile XHR). Înschimb, se poate folosi opţiunea Net care monitorizează schimburile

24 Poate fi vorba de browsere ce nu suportă XHR dar şi de browserul Internet Explorer cuobiectele ActiveX dezactivate.



53

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

Cadrele interne invizibile au şi un alt rol, deosebit de importan t, pe care obiectul XHR nu îl poate îndeplini. Cu ajutorul cadrelor se pot depăşi limitările AJAX cu privire la upload-ul de fişiere şimecanismul Back/Forward al browserului.

Modelul AJAX implementat prin cadre invizibile diferă categoric de modelul baza t pe XHR.Unii autori consideră că folosirea cadrelor invizibile nu ar trebui încadrată în modelul AJAX, fiind maidegrabă o simulare a sa. Alţi autori consideră că nu este nimic în denumirea Asynchronous JavaScript

and XML care să excludă cadrele interne şi să impună obiectul XHR. Într -adevăr, acronimul AJAXînglobează elementele:

Comunicare asincronă cu serverul (schimb de date care nu întrerupe aplicaţia şi experienţa deutilizare);

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 cerinţe. Ultimele două sunt utilizate similar, diferenţa

apare doar la modul în care e implementată comunicarea asincronă: într -un site cu două cadre,

funcţionarea unui cadru nu este afectată de faptul că al doilea cadru suferă un refresh sau o reîncărcarede pagină. Acest al doilea cadru poate fi folosit pentru a schimba date cu serverul, în timp ce utilizareaaplicaţiei se desfăşoară neîntrerupt în primul cadru.

Reluăm exemplul cu codul poştal, î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.documentraspuns=documentcadru.body.innerHTMLprocesare(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>


</tr><tr>

<td>CodPostal</td><td><input type=text id=TXcodpostal onblur="trimite(this.value)"></td>

</tr><tr>

<td>Adresa</td>



54

<td><input type=text id=TXadresa size=50></td></tr><tr>


</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>

</body></html>

Se remarcă: În interiorul paginii s-a definit un cadru intern, identificat prin id. Dimensiunile iniţiale ale

cadrului vor permite, în scopul testării exemplului, să se observe direct în cadru răspunsulserverului. După ce exemplul se dovedeşte funcţional, dimensiunile cadrului se pot modificala valoarea 0 pentru a obţine un cadru invizibil, ce nu interferează cu experienţa utilizăriiaplicaţiei;

Alt atribut esenţial al cadrului este src, ce indică pagina pe care trebuie să o afişeze cadrul.Iniţial, atributul este vid, aşadar cadrul va fi gol în prima fază. Apoi, după completarea codului

poştal, în cadrul funcţiei trimite(), datele sunt trimise prin modificarea valorii src a cadrului.Desigur, metoda nu este foarte intuitivă (acesta fiind unul din motivele optării pentru variantaXHR). Teoretic, rolul cadrului este de a afişa pagina indicată de src. Practic, acea pagină poatefi un script server a cărui adresă conţine variabile GET concatenate! Aşadar, trimiterea de date

prin metoda cadrelor are loc de câte ori JavaScript modifică valoarea atributului src; Răspunsul soseşte în format text, ca rezultat al scriptului server a cărui adresă s -a trecut în

atributul src. Răspunsul este imediat afişat în cadru. În paginile Web clasice, acest răspunseste chiar o pagină generată dinamic în scopul afişării. În AJAX, acest răspuns este un şir decaractere care va fi ascuns atunci când cadrul devine invizibil. Scopul acestui şir de cara cterenu mai este să fie afişat, ci să fie accesat prin JavaScript, ceea ce se întâmplă imediat dupăsosirea răspunsului (prin handlerul onload al cadrului);

Răspunsul este capturat de JavaScript în handlerul onload pentru a avea garanţia că datele ausosit înainte să înceapă procesarea lor. În timpul receptării datelor, pagina principală poate fiutilizată fără întrerupere, ceea ce asigură caracterul asincron al schimbului de date.Extragerea datelor a fost multă vreme aspectul cel mai problematic în modelul AJAX cucadre, deoarece fiecare tip de browser folosea alte metode pentru a accesa conţinutul unuicadru. În prezent se pot folosi două tehnici în acest scop:

o tehnica pull (extragerea datelor din cadru): conţinutul cadrului se accesează dinpagina principală prin nodcadru.contentWindow.document.body.innerHTML, dupăcum se remarcă în funcţia citestedate();

o tehnica push (împingerea datelor dinspre cadru): codul sursă cu care serverulalimentează cadrul va conţine cod JavaScript care apelează funcţia de pre lucrare arăspunsului din pagina principală.

Modificarea prin DOM a atributului src al cadrului nu e singura metodă de a încărca date (saudocumente) într-un cadru. În acelaşi scop se pot folosi orice operaţii care permit încărcarea unei pagini

într-un cadru ţintă (prin atributul target): <a href=script.php?variabila=valoare target=cadru>....</a> - o hiperlegătură a cărei pagină

ţintă va fi afişată în cadrul indicat prin target; ca şi în exemplul anterior, pagina ţintă poate fiun script server la a cărui adresă se pot concatena variabile GET;

<form action=script.php target=cadru>....</form> - un formular ale cărui date vor fi trimisespre un script al cărui răspuns va fi afişat în cadrul indicat prin target; aceasta este, dealtfel,metoda prin care modelul AJAX bazat pe cadre interne permite trimiterea de variabile POSTsau uploadul de fişiere.

Totuşi, cele două metode sunt replici ale metodelor tradiţionale prin care utilizatorul decide,prin clic-uri, când are loc trimiterea de date spre server. Modificar ea dinamică a atributului src conferă



55

o dinamică superioară şi o subtilitate a schimburilor de date mai apropiată de cea promovată demodelul AJAX.

Se poate remarca o oarecare simplitate comparativ cu metoda XHR. Totuşi, pentru a seasigura compatibilitatea cross- browser, funcţia citestedate() devine mult mai complicată, pentru agaranta faptul că se extrage conţinutul cadrului indiferent de browser. Ca şi în cazul XHR, aceasta se

obţine printr -o structură try-catch.

2.3. Platforme şi biblioteci AJAX

2.3.1. Rolul platformelor AJAX

Modelul AJAX a dus inevitabil la apariţia unor platforme de dezvoltare a aplicaţiilor cuinstrumente şi componente de nivel înalt, uşor de integrat şi reutilizabile. Pe scurt, e vorba deinstrumente menite să accelereze procesul de producţie a unui site AJAX. Exemplele anterioare audemonstrat nucleul oricărei aplicaţii AJAX – de la instanţierea prin tentative şi excepţii a obiectuluiXHR până la recepţionarea datelor de la server. Deoarece acest mecanism e folosit de majoritatea

aplicaţiilor AJAX în mod identic, dezvoltatorii Web au definit funcţii de nivel mai înalt care să încapsuleze acest mecanism, mascând detaliile sale. Mai mult, s-au creat componente care săcompenseze şi să mascheze neajunsuri AJAX precum imposibilitatea de a face upload de fişiere sau dea crea semne de carte pentru stări diferite ale aplicaţiei. Această tendinţă a dus la apariţia uneimultitudini de "platforme" AJAX bazate pe pachete ce implementează diverse funcţionalităţi alemodelului, asigurând nivele de abstractizare şi o separare a sarcinilor echipelor de lucru chiar mai

puternică decât cea sugerată de structura internă a codului AJAX (structură cu blocuri div, formatări cuCSS, manipulare cu JavaScript, conectare la server cu XHR) . Majoritatea platformelor AJAX suntconstruite pe nivelele:

Nivel 0: mecanisme de nivel scăzut, reutilizabil, de conectare asincronă la server: obiectulXHR sau cadrele interne;

Nivel 1: instrumente de nivel înalt de comunicare cu serverul (ce maschează detaliile nivelulu i0) – Dojo, JSON-RPC, Prototype, Direct Web Remoting;

Nivel 2: instrumente de nivel înalt de construire a interfeţei cu utilizatorul (construite pestenivelul 1) – Dojo oferă instrumente şi la acest nivel, SmartClient, Script.aculo.us (bazat pePrototype);

Nivel 3: medii de dezvoltare a aplicaţiilor AJAX: Rails, Tapestry, AJAX.NET, SAJAX.

Instrumentele de nivel 1 nu sunt altceva decât biblioteci de funcţii sau interfeţe de programare(API) care împachetează instanţierea şi comunicarea asincronă prin obiectul XHR (sau prin alternativă

– cadrele interne, folosite pentru browserele care nu suportă nici una din tentativele de instanţiereXHR). Majoritatea instrumentelor de nivel 1 sunt create independent faţă de tehnologia folosită deserver. Unele, precum Direct Web Remoting, instalează şi o componentă Java pe server pentruascultarea ş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 obiectel or server direct

din scripturi client.Instrumentele de nivel 2 sunt medii de generare a interf eţei cu utilizatorul – componente GUI,

cu funcţionalităţi, animaţii preprogramate şi chiar suport pentru operaţii desktop tradiţionale precumdrag-and-drop. Unele instrumente extind gama de componente GUI pentru a o apropia cât mai mult decea a interfeţei formularelor Windows sau Mac. Instrumente precum Backbase sunt de fapt limbaje demarcare (limbaje XML) ce folosesc proprii marcatori, superiori celor din HTML , împreună cu funcţiicu rol de interpretor.

Instrumentele de nivel 3 sunt medii de dezvoltare complexe bazate pe generatoare de cod JavaScript (Ruby on Rails generează cod şi funcţii 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 evoluţiamediilor de programare Web, asigurând o productivitate înaltă şi minimizând efortul conceperii şi



56

scrierii codului sursă pentru funcţionalităţi frecvent reutilizate. Se afirmă că istoria AJAX a parcursetapele:

pionieratul – corespunde apariţiei celor două soluţii convergente, apărute iniţial independent: o paginile DHTML ce permiteau manipularea conţinutului şi formatului unei pagini

accesând stiluri CSS primitive prin JavaScript;o mecanismele de comunicare asincronă – cadrele interne invizibile utilizate frecvent şi

obiectul XHR, disponibil începând cu anul 2000 şi versiunea 5 a browserului InternetExplorer. perioada entuziastă – corespunde promovării 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 scăderea rolului limbajuluiJavaScript propriu-zis şi creşterea rolului funcţiilor şi obiectelor JavaScript oferite de

bibliotecile AJAX în efortul de programare Web. Bibliotecile cu cea mai puternică adopţiesunt cele de tip open-source: Prototype (niv.1), Script.aculo.us (niv.2), Dojo (niv.1 şi 2) şiRails (niv.3).

2.3.2. Comunicarea cu serverul prin pachetul Dojo

Pachetul Dojo e rezultatul unui proiect open-source şi poate fi descărcat gratuit lawww.dojotoolkit.org. Pachetul include instrumente de nivel 1 şi 2 pentru facilitarea dezvoltării deaplicaţii AJAX scalabile, precum şi o serie de facilităţi ce maschează aspectele problematice din AJAX

– upload de fişiere, creare semne de carte şi altele. Componentele pachetului Dojo sunt biblioteca DojoCore pentru gestiunea comunicării cu serverul şi gestiunea evenimentelor (nivelul 1), biblioteca deanimaţii, efecte şi gestiune drag and drop Dijit (nivelul 2) şi biblioteca de extensii DojoX cuinstrumente diverse, experimentale şi extensibile, pentru ambele nivele.

În continuare reluăm exemplul cu formularul în care se completează automat oraşul, judeţul şistrada la completarea de către utilizator a codului poştal. Codul sursă al exemplului este:

<html>

<head><title>Formular</title><script type="text/javascript">

function createXHR(){var atry

{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]



57

document.getElementById("TXadresa").value=datevect[2]document.getElementById("Eroare").innerHTML=""

}else document.getElementById("Eroare").innerHTML="<font color=red>Eroare de

conectare la server!</font>"}}

function date(cod){xhr=createXHR()xhr.onreadystatechange=procesarexhr.open("GET","script.php?CodPostal="+cod)xhr.send(null)}

</script></head><body>

<h1>Introduceti datele</h1><form><table><tr>


</tr><tr>

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

</tr><tr>


</tr><tr>


</tr>

<tr><td>Judet</td><td><input type=text id=TXjudet ></td>

</tr><tr>




Pentru convertirea paginii la platforma Dojo, pachetul trebuie descărcat de la site-ul

www.dojotoolkit.org.25 Arhiva obţinută se extrage într -un folder din rădăcina 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 operaţiile de prelucrare a datelor îndouă funcţii: cea care procesează datele şi cea care procesează erorile serverului:

25 La momentul redactării acestui material, pachetul Dojo se află la versiunea 1.1.0, sub careau fost testate toate exemplele. Avertizăm asupra faptului că modificările de la o versiune la alta pot fimajore (funcţii noi, funcţii cu nume schimbate) şi că există numeroase tutoriale Dojo on -line sau în

literatură care sunt depăşite şi pot produce confuzii. În acest sens, recomandăm consultareadocumentaţiei oficiale de pe siteul www.dojotoolkit.org pentru a sesiza eventualele modificări care ar

putea să apară faţă de exemplele din acest material.



58

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 funcţii primesc obligatoriu două argumente – primul reprezentândrăspunsul serverului (date sau mesaj de eroare26), al doilea reprezentând o referinţă a obiectul Dojo cegestionează conexiunea cu serverul, pentru a permite acces la o serie de proprietăţi a le sale dininteriorul acestor funcţii.

Pentru comunicarea cu serverul, Dojo oferă funcţiile xhrGet şi xhrPost, corespunzătoare

metodelor GET şi POST. Ambele funcţii încapsulează instanţierea şi utilizarea obiectului XHR (inclusiv testarea stării răspunsului). Noua formă a funcţiei date(), pentru transfer GET, va fi:

function date(cod){

dojo.xhrGet({url: "script.php?CodPostal="+cod,handleAs:"text",load: procesare,error: proceroare})

}

Ascunzând partea de instanţiere, funcţia xhrGet() solicită precizarea argumentelor: url – singurul argument obligatoriu, adresa scriptului server solicitat; load – funcţia ce preia datele de la server pentru prelucrare în caz de succes (înregistrarea

evenimentului, testarea stării şi codului de eroare sunt mascate de funcţia bind()); error – funcţia ce gestionează erorile privind receptarea datelor; handleAs – formatul în care se aşteaptă 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 câmpurilor unui formular.

În cazul de faţă nu a fost nevoie să apelăm la ultimele argumente, datele fiind concatenate cavariabile GET la url. Aşadar, forma finală a antetului de pagină folosind biblioteca Dojo, va fi (corpul

paginii rămâne 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)

26 Mesajul de eroare e explicitat (text şi cod de eroare) doar în Firefox, IE îl tratează ca pe oreferinţă la un obiect-eroare.



59

{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ă funcţii handler,obiectDojo. Acesta permite ca din interiorul funcţiilor să se acceseze proprietăţile argumentului xhrGet

prin construcţii de forma:

adresa=obiectDojo.url

Una din proprietăţile acestui obiect este chiar obiectul xhr, deci accesul direct la răspunsulserverului 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>



document.getElementById("confirmare").innerHTML=raspuns}


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>



60

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

</tr><tr>

<td></td><td><input type=submit></td>

</tr>

</table></form><p id=confirmare></p>

</body></html>

Am simplificat formularul pentru claritate. La testare, se va completa în formular numele şicodul poştal. La evenimentul blur (părăsirea câmpului) pentru TXcodpostal, are loc un transfer spreserver a tuturor datelor formularului. Pentru verificare, modificăm scriptul PHP astfel încât să testezedacă au ajuns la server două variabile POST corespunzătoare celor două câmpuri:

<?phpprint "La server au ajuns numele ".$_POST['nume']. " si codul postal ".$_POST['cp'];

?>

Observaţii: S-a folosit dojo.xhrPost în loc de xhrGet; În argumentul funcţiei xhrPost s-a adăugat proprietatea form, cu identificatorul formularului; Formularul a primit un atribut id, pentru a fi identificat de funcţia xhrPost; Atributele method şi action ale formularului sunt ignorate! Acestea sunt valabile doar pentru

evenimentul submit (apăsarea butonului submit sau o funcţie handler pentru onsubmit). Ori încazul nostru, obiectul XHR realizează transferul la evenimentul blur, folosind un alt scri ptserver şi o altă metodă decât cele declarate de formular (proprietatea url e preferată atributuluiaction, funcţia xhrPost e preferată atributului method!). Practic, după cum s-a observat şi înexemplele precedente, prezenţa atributelor method şi action e redundantă;

Scriptul server receptează datele de la XHR în variabile POST; Răspunsul serverului este stocat direct în paragraful cu ID=confirmare; Variabilele POST la server îşi primesc numele din atributele name ale câmpurilor de formular

corespunzătoare, motiv pentru care s-a adăugat, alături de id (cu rol de identificare în DOM) şiatributul name (cu rol de generare a variabilelor POST). Se poate comenta faptul că e primadată când apelăm la atributul name. În exemplele anterioare, acestea nu au fost necesaredeoarece variabila GET CodPostal fusese construită pe altă cale: onblur="date(this.value)"

prelua valoarea câmpului şi o transmitea ca argument funcţiei, care o concatena la adresascriptului server, odată cu numele variabilei GET "script.php?CodPostal="+argument. Acestmecanism de transmitere a variabilelor GET direct în adresa scriptului server e facil şi uzualcând nu se transmite un număr mare de date. Dacă dorim să transmitem întreg formularul prinGET, singura modificare necesară la ultimul exemplu este înlocuirea lui xhrPost cu xhrGet(care acceptă la rândul său 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ă funcţie 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 câmp deformular cu id=camp. Scriptul server care va confirma acest lucru are forma:



61

<?phpprint "La server au ajuns ".$_GET['v1']. " si ".$_GET['v2'];

?>

Am amintit anterior că uzual serverul returnează răspunsul în două forme: text sau XML,

diferenţiate în proprietăţile responseText şi responseXML ale obiectului XHR. Folosind Dojo, tipulrăspunsului e fixat prin argumentul handleAs. Mai mult, Dojo acceptă şi alte două formate puternicedrept răspuns: cod JavaScript pentru execuţie imediată sau date în format JSON (JavaScript ObjectNotation).

Reluând exemplu cu completarea automată a formularului la introducerea codului poştal,scriptul server ar putea arăta astfel:


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. Deoarececodul returnat e un şir de caractere ce conţine multiple instrucţiuni, acestea au fost delimitate prinpunct-virgulă (caracter care e obligatoriu în JavaScript doar dacă mai multe instrucţiuni apar pe aceeaşilinie – aşa cum e cazul şirului trimis de server). În aceste condiţii, funcţia dojo.xhr Get poate ficonfigurată pentru a recepta datele în format JavaScript şi a le executa imediat, cu ajutorulargumentului handleAs:

<head>




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 iniţială şi un acces maidirect din codul PHP direct asupra paginii HTML. Este important de remarcat faptul că argumentulfuncţiei xhrGet este de fapt un obiect, ale cărui proprietăţi (url, handleAs, load, error etc.) sunt definiteîn mod inline, direct în parantezele funcţiei. Acest lucru este permis de sintaxa JavaScript, dar nu esteobligatoriu. Forma în care e iniţializat argumentul funcţiei xhrGet poartă de numirea de format JSON.



62

Formatul JSON27 pentru transferul de date este o alternativă tot mai populară şi multsimplificată faţă de XML. Atât XML cât şi JSON sunt, la bază, şiruri de caractere, diferă doar structurainternă a acestor şiruri. În timp ce XML impune ca datele să fie definite într -o structură de marcatori cerespectă regulile de bună formare, JSON permite gruparea datelor în manieră obiectuală (seturi de

proprietăţi încapsulate pe mai multe nivele) – modelul JSON este inspirat chiar de modalitatea deiniţializare a variabilelor masive:

A[2][3]=[[1,2,3][4,5,6]]

Pentru definirea de obiecte, iniţializarea foloseşte acolade şi perechi nume:valoare separate prin virgulă:

obiect={proprietate1:valoare1, proprietate2:valoare2}

...unde fiecare valoare poate fi la rândul său un obiect sau un masiv.

De fapt, sintaxe de tip JSON au fost deja folosite în situaţiile: descrierea argumentului funcţiei xhrGet, unde s-au enumerat url, handleAs, load şi error –

toate fiind proprietăţi iniţializate ale obiectului ce serveşte 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 asemănătoare şirurilor JSON:

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

Diferenţa e caracterul de delimitare punct-virgulă. Similar cu şirul JSON, descriereaCSS e convertită implicit în obiect JavaScript pentru a avea acces direct la proprietăţile CSS

prin construcţii de forma nod.style.proprietatecss;

Notă: Revenim cu câteva explicaţii asupra unor detalii de sintaxă Dojo.Am arătat că argumentul unor funcţii ca xhrGet sunt obiecte ce pot fidescrise prin JSON. Aceasta explică motivul pentru care funcţiilehandler sunt indicate doar prin numele lor, nu şi prin argumente:

obiect={url:....,handleAs:....,load: procesare ,error: proceroare}în loc deobiect={url:....,handleAs:....,load: procesare() ,error: proceroare() }

Explicaţia constă în faptul că la construirea unui obiect definit prin

sintaxă JSON fiecare proprietate a obiectului devine o variabilă careprimeşte o valoare evaluată de interpretorul JavaScript.

Dacă valoarea uneia din aceste proprietăţi are forma funct ie(),aceasta va fi chiar valoarea returnată de funcţie, deci funcţiava fi apelată şi executată chiar la construirea obiectului. Ori,scopul unui handler e să fie executat doar la declanşareaevenimentului asociat!

În schimb, dacă proprietatea primeşte valoarea funct ie, aceasta vadeveni o variabilă de tip function ce va stoca blocul de execuţiea funcţie şi nu valoarea sa!

Pentru clarificare, reamintim modul în care JavaScript diferenţiază ofuncţie de valoarea sa prin absenţa sau prezenţa argumentelor şiparantezelor:

a=f()b=f

27 http://json.org



63

În urma acestor atribuiri, a va primi valoarea returnată de funcţie,iar b devine la rândul său funcţie (e o variabilă de tip function) şiva putea fi apelată cu b().

În concluzie, funcţiile handler din argumente de tip JSON nu vor puteaprimi argumente explicite, ci doar pe cele implicite (raspunsul şiobiectul Dojo).

În cele ce urmează vom realiza o comparaţie între formatele JSON şi XML aplicate asupradatelor trimise de server. Prezentăm în continuare acelaşi 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 câtedouă proprietăţi. Insistăm asupra faptului că valorile masive se enumeră între paranteze pătr ate, iar

proprietăţile obiectelor între acolade, fiind posibilă orice combinaţie de imbricare între acestea (ex:vector de obiecte, obiect cu proprietăţi vectori, obiect cu proprietăţi obiect, vector cu elemente vector 28 etc.). După unii autori, obiectul JSON nu este decât o variabilă masivă de tip asociativ (care foloseştenume de proprietăţi în loc de număr 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 făcându-se pe bazaimbricărilor. Relaţia tată-fiu în arbore e implementată astfel:

XML – prin imbricarea marcatorilor sau prin subordonarea atributelor la un marcator; JSON – prin imbricarea parantezelor.

Relaţia frate-frate e implementată astfel: XML: elemente fiu ale aceluiaşi părinte sau atribute separate prin spaţiu ale aceluiaşi element; JSON: şiruri de perechi nume:valoare separate prin virgulă sau elemente de vector separate

prin virgulă; Avantajele JSON sunt:

performanţa, atunci când se transferă strict seturi date (în schimb XML devine esenţial atuncicând se transferă porţiuni de documente ce vor fi manipulate prin DOM);

compatibilitatea cu obiectele JavaScript – Dojo oferă chiar o serie de funcţii de conversiefacilă între şiruri de caractere JSON şi obiecte JavaScript;

accesul facil la proprietăţile JSON prin sintaxa JavaScript, comparativ cu accesul mai dificil laXML prin DOM – în exemplul JSON, al doilea preţ poate fi accesat prin produse[1].pret, întimp ce în exemplul XML ar fi necesară parcurgerea vectorilor getElementsByTagName sauchildNodes pentru nodul rădăcină, 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 reprezentareastructurilor de date. Deşi creat pe baza modului în care JavaScript iniţializează variabile complexe,JSO N se doreşte a fi un format universal pentru transferul datelor independent de platforma părţilor între care are loc transferul. Aşadar, e vorba de un veritabil concurent pentru XML în acest sens, deşirenunţă la conceptele XML avansate (vocabular, instrucţiuni de procesare, spaţii de nume). Suporterii

28 Practic o matrice nu este altceva decât un vector cu elemente vectori.



64

JSON susţin că oricum conceptele XML sunt inutile: spaţiile de nume devin inutile dacă nu se maifolosesc marcatori iar validarea prin vocabulare e considerată o delegare inutilă a responsabilităţiilor:

Principiul XML este că aplicaţiile trebuie să fie restrictive la receptarea datelor (datele fiindvalidate sau transformate conform regulilor unui vocabular predefinit de destinatar) şi

permisive la generarea lor (fiecare aplicaţie poate genera orice structură de date XML); Principiul JSON este că orice aplicaţie trebuie să fie permisivă la receptarea datelor şi

restrictivă la generarea lor , adică să poată prelucra orice structuri de date primite şi să fixezenişte reguli stricte pentru structurile de date gener ate;Aşa cum sunt necesare programe de tip parser pentru a converti un şir de caractere XML într -

un arbore de obiecte DOM, parserele JSON convertesc şiruri de caractere JSON în obiecte. Site -ulhttp://json.org întreţine o listă la zi cu site-urile de la care pot fi procurate parsere JSON pentru diverselimbaje de programare. Pentru JavaScript, parsingul se poate face în mod nativ – funcţia eval()converteşte un şir de caractere într -o expresie sau un bloc de instrucţiuni JavaScript, aşadar prinaplicarea funcţiei asupra unui şir JSON stocat în responseText se obţine chiar un obiect JavaScript,mult mai facil de accesat decât un arbore DOM. Există şi parsere avansate pentru JavaScript, cu metodecomplexe de manipulare a structurii JSON, dar acestea trebuie instalate şi invocate ca biblioteci defuncţii JavaScript (vezi biblioteca http://json.org/json2.js). Conversia unui şir JSON în obiect serealizează în JavaScript astfel:

obiect=eval('('+xhr.responseText+')')saueval('obiect='+xhr.responseText)

Aceasta se realizează în mod nativ29. Folosirea funcţiei eval ridică probleme de securitatedatorită faptului că argumentul funcţiei va fi evaluat şi executat chiar dacă este un bloc de instrucţiuniJavaScript în locul unui şir JSON. Atunci când sursa datelor din responseText nu e de încredere (ex:responseText conţine informaţii tastate de un vizitator într -un formular), se recomandă folosireaparserelor JSON propriu-zise, disponibile gratuit ca biblioteci de funcţii invocate cu SCRIPT SRC.Aceste parsere realizează înaintea evaluării o verificare a structurii argumentului, astfel încât să seasigure că e o structură JSON şi nu un cod sursă potenţial maliţios. Biblioteca json2, propusă de DavidCrockford, promotorul modelului JSON, oferă funcţiile:

obiect=xhr.responseText.JSON.parse() – conversie din şir JSON în obiect sir=obiect.JSON.stringify() – coversie din obiect în şir JSON

Aşa cum există protocoale orientate pe transferul de date XML (SOAP, XML-RPC), există şiprotocoale de transport JSON (JSON-RPC). Mai mult, comunitatea JSON a propus înlocuireaobiectului XHR cu un obiect similar, JSONRequest, optimizat pentru transferuri JSON (la adresahttp://json.org există legături spre instrumente de acest gen, inclusiv o extensie add -on pentru Firefoxce implementează obiectul JSONRequest). În contextul înlocuirii XML cu JSON ca format de transferal datelor structurate, susţinătorii JSON arată că până şi litera X din acronimul AJAX îşi pierdesemnificaţia. Deşi există o tendinţă de migrare a modelului AJAX spre structu ri de date JSON, XMLrămâne un standard puternic când nu e vorba de structuri de date, ci de documente – spre exemplu,atunci când serverul generează marcatori XML ce trebuie integraţi în arborele DOM al paginii.

Pachetul Dojo include un suport puternic pentru formatul JSON, incluzând protocol JSON-RPC şi parser (proprietatea handleAs poate lua valoarea "json" în funcţiile xhrGet şi xhrPost, pentru carăspunsul 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 rândul său funcţii pentru procesare şi generare deşiruri JSON.

Reluăm exemplul cu completarea automată a formularului pe baza codului poştal. De dataaceasta, datele sunt împachetate de server în format JSON, sub forma:

{adresa:....., oras:...., judet:......}

29 Necesitatea concatenării parantezelor în prima variantă e dată de prezenţa acoladelor în şirul

JSON. Funcţia eval interpretează acoladele ca fiind delimitatori ai unor blocuri de instrucţiuni şi provoacă o eroare dacă în loc de instrucţiuni întâlneşte valori JSON. Încadrarea în paranteze rotundeanulează acest comportament.



65

Şirul JSON sunt convertite automat în obiect de către parserul JSON inclus în Dojo. Scriptul server care generează şirul JSON este:


$date=array("oras"=>"Cluj Napoca","judet"=>"Cluj","adresa"=>"Aleea Azuga...(completatidetaliile)");

else$date=array("oras"=>"cod incorect","judet"=>"cod incorect","adresa"=>"cod incorect");

print json_encode($date);?>

Se observă utilizarea funcţiei json_encode(), care converteşte un vector asociativ (sau unobiect PHP) într-un şir de caractere JSON30. Funcţia este membră a extensiei JSON disponibilăimplicit începând cu PHP 5.2.0. Funcţia pereche este json_decode(), care converteşte un şir decaractere JSON în obiect sau vector.

Notă: Mai multe detalii despre extensia JSON pentru PHP suntdisponibile la http://www.php.net/manual/en/book.json.php. Informaţiidespre extensii JSON pentru alte limbaje (şi despre extensii JSON PHPalternative celei instalate implicit) sunt disponibile la site-uloficial JSON: http://json.org

Pagina AJAX va fi modificată pentru a accesa proprietăţile obiectului JSON primit de laserver (nu mai reproducem corpul paginii):

<head><title>Formular</title>




// se elimina linia - var vect=raspuns.split(',') – deoarece raspunsul nu mai e de tip text // ci de tip obiectdocument.getElementById("TXoras").value=raspuns.oras document.getElementById("TXjudet").value=raspuns.judet document.getElementById("TXadresa").value=raspuns.adresa document.getElementById("Eroare").innerHTML=""

}



}

function date(cod){

dojo.xhrGet({url: "script.php?CodPostal="+cod,handleAs:"json",load: procesare,error: proceroare})

}</script></head>

Următorul exemplu primeşte aceleaşi date în format XML, sub forma:

<detalii adresa=......>

30 Utilizarea funcţiei nu e obligatorie în exemplul de faţă. Şirul JSON e un şir de caracteresimplu, deci putea fi returnat de server direct sub formă de string cu structura cerută de JSON. Am dorittotuşi să exemplificăm funcţiile PHP care convertesc date din şi în şiruri JSON.



66

<oras>...</oras><judet>....</judet>

</datepersonale>

Notă: Flexibilitatea XML permite ca datele să fie stocate în oricecombinaţie de atribute, conţinut textual şi elemente imbricate. Dinraţiuni de performanţă, se preferă ca, de câte ori e posibil, datele să

fie stocate în atribute ale unui element vid (fără închidere), caz încare datele exemplului vor avea forma <detalii adresa=.... oras=.....judet=.... / >. În situaţia dată am preferat o formă mai complicatăpentru a exemplifica atât accesul la atribute cât şi accesul laelemente imbricate şi conţinutul lor textual.

Datele pot fi returnate din PHP ca un şir de caractere cu structura indicată, sau împachetate înobiect XML printr-un script ce exploatează aceleaşi funcţii DOM ca şi cele folosite la nivelul clientului(modelul DOM e suportat de majoritatea limbajelor de programare moderne, inclusiv PHP, prin clasaDOMDocument):

<?phpheader("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 răspunsul serverului ca fiind de tip xml, altfel obiectul XHR nu va

aplica parsing XML şi modelul DOM nu se va obţine la client31; folosirea clasei DOMDocument pentru a instanţia 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 rădăcină ca fiu al obiectului $xml; aceasta sugerează că rădăcina

arborelui şi documentul XML nu sunt echivalente: documentul mai conţine, alături derădăcină, cel puţin instrucţiunea-antet <?xml...?>, care se adaugă automat (mai poate conţineşi apeluri de vocabular);

31 Aspectele discutate aici rămân valabile şi atunci când datele XML se obţin direct prinxhr.responseXML, nu doar la transferurile gestionate de funcţiile Dojo.



67

în final, obiectul XML e convertit în şir de caractere cu metoda saveXML(), pentru a putea fireturnat cu print.

În cazul receptării datelor în format XML reamintim faptul că obiectul XML primit de laserver e mai restrictiv decât modelul XML al paginii. Nu toate funcţiile DOM folosite la manipulareapaginii pot fi folosite la manipularea arborelui DOM al obiectului XML. Nu sunt posibile, printre

altele:

- getElementById (se va folosi getElementsByTagName sau navigare de arbore cuchildNodes, firstChild, lastChild etc.);

- calificarea atributelor în forma nod.id (se va folosi nod.getAttribute(), setAttribute());- innerHTML sau outerHTML (se va folosi nodeValue şi funcţiile de manipulare la nivel de

nod fiu – replaceChild, appendChild etc. ).

În consecinţă, modulul client exemplificat mai jos nu se bazează pe localizarea datelor prinatributele id (nu s-a mai trecut corpul paginii, nemodif icat faţă de exemplele anterioare):

<head><title>Formular</title>


<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.nodeValueradacina=raspuns.documentElementdocument.getElementById("TXadresa").value=radacina.getAttribute("adresa")

}



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 câte un singur element); se observă că getElementById s-a folosit doar pe arborele paginii iar

getElementsByTagName şi firstChild pe arborele XML generic;



68

folosirea proprietăţii firstChild pentru a accesa conţinutul textual al marcatorilor XML,deoarece aceştia sunt consideraţi noduri fiu; în cazul arborelui XML construit în PHP nuexistă pericolul nodurilor cu "caractere albe" despre care am discutat la convertirea paginiiHTML în arbore DOM, aşadar childNodes şi proprietăţile aferente nu dau rezultateimprevizibile; "caracterele albe" apar doar atunci când codul XML e tastat (de exemplu, dacă

pachetul XML în loc să fie construit în PHP ar fi fost receptat direct dintr -un fişier de tip xml

cu cod sursă indentat prin tastare de Tab-uri şi Enter -uri); folosirea proprietăţii documentElement care conţine rădăcina arborelui DOM recepţionat, în

scopul extragerii atributului său; folosirea metodei getAttribute în condiţiile în care fo rma raspuns.adresa nu e utilizabil pe cod

XML generic; folosirea proprietăţii nodeValue în condiţiile în care innerHTML nu e utilizabilă pe cod XML

generic.

Notă: Pentru mai multe detalii legate de manipularea DOM în PHP,consultaţi adresa http://www.php.net/manual/en/refs.xml.php. PachetulDOM Extension conţine clasa DOMDocument utilizată în acest exemplu ş i especific versiunilor PHP mai noi de 5. Pentru versiunile PHP mai vechidecât 5, se utilizează pachetul DOM XML 32. Pachetul SimpleXML este oalternativă la DOM mult simplificată. Mai exact, SimpleXML încearcă să

apropie metodele de acces la date de formatul JSON. De exemplu,conţinutul textual al unui marcator e accesibil direct prin calificareapărintelui (nodparinte->nodfiu), în loc să folosească met odele DOM(nodparinte->firstChild->nodeValue). Deşi simplifică mult codul sursă,SimpleXML are performanţe mai reduse decât DOM şi e folosit frecvent pepachete de date de dimensiuni reduse (arbori cu n umăr redus de nivele).Recomandăm familiarizarea cu DOM mai degrabă decât cu SimpleXMLdatorită valabilităţii universale a funcţiilor şi proprietăţilor DOM.

Aceste exemple evidenţiază caracterul mult mai facil al generării şi accesării de date JSONcomparativ cu XML, fără să se piardă structura datelor. În ambele situaţii, proprietatea responseTextrămâne accesibilă şi conţine forma brută, de dinaintea operaţiei de parsing, a şirului de caractere primitde la server.

Am sugerat anterior că pachetul Dojo elimină o parte neajunsurile AJAX. Pentru uploadul def işiere prin formulare, Dojo oferă funcţia dojo.io.iframe, ce maschează o funcţionalitate bazată pe cadreinterne invizibile ce conţin fişierul de uploadat (deoarece JavaScript şi XHR nu permit acces direct ladiscul clientului). Exemplu:

Într-o aplicaţie Web tradiţională, fiecare stare a aplicaţiei 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 areloc prin încărcarea unei pagini noi. În AJAX, browserul primeşte o singură pagină pe care o modificădinamic pe baza datelor transferate de la server prin XHR. Aceasta înseamnă că adresa aplicaţiei AJAXrămâne neschimbată pe toata durata utilizării sale, iar un semn de carte tradiţional, creat prin stocareaadresei URL curente nu va putea face diferenţa între diferite stări ale aplicaţiei. Trecerea de la o stare laalta are loc la fiecare transfer XHR.

Pentru a permite crearea de semne de carte, Dojo apelează la soluţia: la fiecare transfer XHR se generează o marcă unică (şir de caractere generat de programator sau în mod automat – ca marcă detimp). Marca e concatenată în momentul transferului la adresa aplicaţiei. Fiecare astfel de marcă devinereprezentativă pentru o stare a aplicaţiei. Atunci când utilizatorul creează un semn de carte, în acesta sestochează adresa aplicaţiei (care e unică) concatenată cu marca stării curente. Considerăm funcţia detransfer:

dojo.xhrGet({url: "script.php",load:error:changeURL: "starea1"

32 Articolul http://www.ibm.com/developerworks/xml/library/x-xmlphp3.html?ca=dgr-lnxw09PHP5-XSLT oferă o viziune de ansamblu asupra bibliotecilor PHP pentru procesare XML,inclusiv o comparaţie utilă între DOM şi SimpleXML



69

})

La executarea acestui transfer, adresa URL a aplicaţiei AJAX se va modifica în browser laforma http://localhost/aplicatiamea.html#starea1. Această adresă va putea fi stocată în Favorites sauBookmarks, ca semn de carte ce va aduce aplicaţia la starea imediat următoare transferului respectiv.Dacă se doreşte generarea automată a mărcii de stare, changeURL se setează la valoarea true.

Legat de folosirea butoanelor Back/Forward, acestea se bazează pe istoricul paginilor vizitatede browser (şi implicit pe adresele acestora). Ori, după am arătat anterior, aplicaţia AJAX e o paginăunică, deci cele două butoane vor părăsi complet aplicaţia în loc să navigheze între stările sale. În acestcontext devine avantajoasă exploatarea cadrelor interne în locul obiectului XHR, deoarece fiecaremodificare a conţinutului unui cadru defineşte o stare nouă în istoricul browserului.

Numeroase pachete de funcţii AJAX oferă mecanisme de simulare a istoricului de pagini pedurata utilizării aplicaţiei, folosind principiul anterior explicat, de definire a stărilor aplicaţiei princoncatenare de mărci unice la adresa paginii. Pachetul Dojo permite programarea comportamentului

butoanelor Back şi Forward de pe browser, prin funcţii handler 33:

backButton: function() {..........}

forwardButton: function() {...........}

Notă: Ca şi în cazul upload -ului de fişiere, şi în acest cazimplementarea pe care o maschează Dojo e complicată şi bazată pe uncadru intern invizibil. Cadrul invizibil suferă la creare două operaţiiforward şi o operaţie back pentru a se afla, din punct d e vedere alistoricului, între un forward şi un back (astfel încât nici una dincele două operaţii să nu provoace părăsirea aplicaţiei). Apoi, celedouă funcţii Dojo sunt legate de evenimentul onload asociat operaţiilorback ş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 instanţierea corectă. Mai mult, dacă obiectulXHR nu este disponibil sub nici o formă, Dojo încapsulează şi comunicarea cu serverul prin cadreinterne invizibile, fără nici un efort suplimentar din partea programatorului AJAX. Acest mecanism deimplementare a mai multor variante de cod pentru a preîntâmpina limitările de platformă care pot săapară duce la aşa-numitul cod sursă degradabil. Codul degradabil este un cod sursă ce conţine ramuride execuţie alternative pentru fiecare funcţionalitate care ar putea să lipsească din browserulvizitatorilor, ceea ce asigură o robusteţe şi o fiabilitate mărită faţă de resursele utilizatorului. Structuratry-catch de verificare a existenţei claselor necesare instanţierii XHR este un exemplu de astfel de coddegradabil. Adăugarea unui suport suplimentar ce apelează la cadre interne invizibile atunci când XHR lipseşte aduce un plus de degradabilitate şi, implicit, de robusteţe iar pachetul Dojo este foarte bineconstruit în acest sens. În plus, am sugerat şi faptul că în unele situaţii cadrele invizibile devinobligatorii şi anume în implementarea upload-ului de fişiere sau a gestiunii butoanelor Back/Forwardîntre stările aplicaţiei AJAX.

2.3.3. Comunicarea cu serverul prin biblioteca

Prototype

Prototype este una din soluţiile concurente pentru Dojo, axată pe extinderea obiectelor JavaScript urmând un model inspirat de limbajul Ruby. Biblioteca poate fi descărcată gratuit şi seinstalează similar cu Dojo. Începând de la versiunea 1.5.1 oferă suport pentru date în format JSON.

Presupunem că am creat în rădăcina serverului Web folderul protoroot, în care copiem biblioteca care e un fişier unic cu un nume de forma prototype – nrversiune.js. La începutul paginiiAJAX se apelează biblioteca, similar cu cazul Dojo:

<head><script type="text/javascript" src="protoroot/prototype-1.6.0.2.js">

33



70

</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",

{asynchronous: true,method: "get",parameters: "CodPostal="+cod,onSuccess: procesare,onFailure: proceroare})

}

</script></head>

Notă: Atenţie la numărul de versiune al bibliotecii Prototype, careapare chiar în numele fişierului şi care se modifică uneori cufrecvenţă lunară. După ce downloadaţi biblioteca, verificaţi numelefişierului şi folosiţi-l întocmai în apelul de includere a bibliotecii.

O diferenţă importantă faţă de Dojo este că funcţiile handler pentru onSuccess (echivalentul

proprietăţii load în Dojo) şi onFailure (echivalentul proprietăţii error în Dojo) primesc un singur argument, şi acela este chiar obiectul XHR, nu răspunsul, cum e cazul Dojo. Mai departe, se remarcăfaptul că parameters este echivalentul proprietăţii content. Aici valoarea parameters e construită ca şi rde caractere, dar e acceptată şi sintaxa JSON. Mai iese în evidenţă faptul că adresa scriptului server eun argument separat (nu face parte din obiectul-argument cu restul proprietăţilor, aşa cum era cazul înDojo). Ajax.Request poate primi numeroase argumente, dintre care cele mai importante sunt adresascriptului şi obiectul (aici în descriere JSON) cu descrierea cererii.

Notă: Având în vedere că şi funcţiile Prototype au c a argumente obiectedefinite prin JSON, rămâne valabilă regula discutată la prez entareaDojo: funcţiile handler sunt indicate doar prin nume, nu şi prinparanteze, deci nu pot primi argumente explicite. Aşadar, o construcţieprecum

onSuccess: functiehandler(argument1,argument2)

va funcţiona eronat: va executa funcţia la construirea argumentuluiAjax.Request şi nu la declanşarea evenimentului pentru care s -a creathandlerul! Handlerele Prototype au obligatoriu ca argument implicitobiectul XHR, ca în exemplul:

new Ajax.Request(....{...onSuccess: functiehandler}).....function functiehandler(obiectxhr) {//blocul de execuţie a handlerului }

În consecinţă, singura cale de a transmite argumente handlerelor esteintermedierea printr-un handler anonim (o valoarea de tip function):

onSuccess: function (obiectxhr) {functiehandler(argument1,argument2)}



71

Din interiorul funcţiei handler vor putea fi accesate atât argumenteleexplicite cât şi obiectul XHR.

Dacă se doreşte receptarea de cod JavaScript de la server, se poate apela la funcţia careconverteşte şiruri de caractere în construcţii JavaScript: eval (utilă şi la obţinerea obiectelor JSON înmod 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 codJavaScript, după cum s-a exemplificat în cazul Dojo.

Platforma care exploatează biblioteca Prototype, numită Ruby on Rails, promovează unmodel aparte de aplicaţii AJAX: generarea de cod HTML la nivelul serverului, care apoi este inclus înstructura 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>


</tr><tr><td>CodPostal</td>



72

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


</tr><tr>

<td>Oras</td><td><input type=text id=TXoras ></td></tr><tr>


</tr><tr>




Se observă că, în cazul folosirii obiectului Ajax.Updater, nu mai e necesară precizareahandlerului onSuccess. Obiectul Ajax.Updater permite totuşi utilizarea handlerului onSuccess şi a altor handlere ce corespund stărilor transferului de date (vezi valorile xhr.readyState). Poate fi nevoie de unhandler onSuccess pentru Ajax.Updater atunci când primirea răspunsului de la server are şi alteconsecinţe decât 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 mar catorului.

Ajax.Updater(element, url, {........., insertion:top})

Revenind la exemplu, acesta se bazează pe faptul că serverul oferă cod HTML care poate fiintrodus prin innerHTML în locul conţinutului marcatorului al cărui atribut id e precizat în primulargument 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><td>Nume</td><td><input type=text id=TXnume ></td>

</tr><tr>

<td>CodPostal</td><td><input type=text id=TXcodpostal value='$cod'

onblur='date(this.value)'></td></tr><tr>



73

<td>Adresa</td><td><input type=text id=TXadresa size=50 value='$adresa'></td>

</tr><tr>

<td>Oras</td><td><input type=text id=TXoras value='$oras'></td>

</tr>

<tr> <td>Judet</td><td><input type=text id=TXjudet value='$judet'></td>

</tr><tr>


</tr>";

?>

În scriptul PHP se observă integrarea variabilelor direct în şirul de caractere, fără concatenare.Sintaxa PHP 5.0 permite acest lucru, variabilele fiind detectate şi substituite cu valorile lor datorită

prefixului $. Porţiunile 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 reproşa este tocmai refreshulredundant pe care modelul AJAX ar trebui să îl elimine. O parte din codul HTML (trei dintrerândurile tabelului) e reîncărcat de la server, deşi nu conţine nici o modificare. În alte situaţii însă,generarea de snippet HTML non-redundant de la server, care să se poată cupla la restul paginii cuminim de efort, este un instrument deosebit de puternic. Pentru a realiza acest lucru, intuiţia ar dicta cacele trei celule care se recreează la server să fie delimitate într -un bloc div sau span care apoi să fierescris cu Ajax.Updater:

<form><table>

<tr>....</tr><div id=blocinlocuit>

<tr>.....</tr><tr>.......</tr></div>

........</table></form>

Din păcate aceasta nu e o soluţie. Blocurile div şi span pot teoretic să delimiteze orice porţiunede document, atâta timp cât nu încalcă regulile de imbricare ale vocabularului XHTML. Aceste reguliimpun o structură rigidă a marcatorului table – acesta poate conţine doar marcatori tr, thead, tbody sautfoot. Orice text inserat între marcatorii table şi tr (sau între tr şi td) este fie ignorat de unele browsere,fie mutat forţat înaintea tabelului. Aşadar, în cazul de faţă, la convertirea paginii în arbore DOM,

browserele vor muta blocul div în faţa tabelului iar substituirea sa cu un snippet va da rezultatenedorite. Soluţiile reale sunt:

formularul să fie aliniat pe alte căi decât prin includerea sa într -un tabel; câmpurile 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 răspunsului ca şir JSON sau XML este , în Prototype, intuitivă, datorită faptului că

funcţiile handler au ca argument chiar obiectul XHR, cu proprietăţile responseText şi responseXML.Obţinerea unui obiect JavaScript dintr -un răspuns JSON e posibilă cu ajutorul unei funcţii de conversiea răspunsului de tip text:



74

obiect=obiectxhr.responseText.evalJSON(true)

Această atribuire va apare în funcţia handler pentru OnSuccess. Argumentul true are rolul de aactiva protecţia faţă de codul maliţios. Spre deosebire de funcţia nativă eval(), argumentul true face cafuncţia Prototype să testeze dacă şirul de caractere are o structură JSON sau este un bloc de instrucţiuni

JavaScript, urmând ca în al doilea caz să împiedice, printr -o eroare de sintaxă, operaţia de conversie.

Conversia inversă, din obiect în şir JSON, se poate realiza cu:

sir=obiect.toJSON()

Obţinerea unui arbore XML nu necesită efort explicit, acesta fiind preluat direct dinproprietatea responseXML.

2.4. Interfaţa cu utilizatorul

Dacă ne referim strict la partea de interfaţă cu utilizatorul din AJAX, aceasta exista în anii 90sub denumirea Dynamic HTML, care semnifica tocmai mecanismul de manipularea a unei interfeţeHTML prin JavaScript şi CSS. Din nefericire, la momentul la care Dynamic HTML s-a lansat, a fostrespins de comunitatea Web datorită lipsei de maturitate – CSS nu devenise încă un limbaj în sine, cidoar o sintaxă de formatare complementară limbajului HTML, modelul DOM era încă primitiv iar diferenţele de implementare între browsere erau descurajante. La ora actuală există încă diferenţe deimplementare între browsere, care afectează AJAX, dar sunt mult mai ameliorate decât în anii 90.Oricum, ceea ce aduce propriu-zis AJAX în plus faţă de Dynamic HTML este faptul că manipulareainterfeţei cu utilizatorul e dictată de datele obţinute asincron de la server prin XHR sau cadre interne.

Interfaţa cu utilizatorul în AJAX aduce un plus de utilizabilitate aplicaţiilor Web.Utilizabilitatea reprezintă uşurinţa de utilizare a unei aplicaţii software, măsurată printr -o serie de

proprietăţi: curba de învăţare a utilizării, caracterul intuitiv, preîntâmpinarea nevoilor utilizatorilor,fiabilitatea şi consistenţa interfeţei, calitatea şi promptitudinea dialogului cu utilizatorul. În aplicaţiiledesktop, utilizabilitatea a evoluat de la începutul anilor 90 până în prezent, pe măsură ce s-a trecut de lasistemele de operare şi aplicaţiile cu linie de comandă la cele cu meniuri şi apoi la cele vizuale, bazatepe componente GUI reutilizabile şi standardizate. În prezent, o aplicaţie desktop poate obţine un grad

înalt de utilizabilitate prin programarea evenimentelor (click, mouseover, drag-and-drop etc.) care audeschis noi orizonturi comparativ cu aplicaţiile în care interacţiunea se baza strict pe introducere dedate/comenzi sau selecţia din meniuri. În schimb, aplicaţiile Web au fost limitate în acest sens de gamaredusă de evenimente programabile şi de latenţa reţelei, adică de faptul că declanşarea evenimentului şidatele necesare se aflau pe calculatoare diferite. Apariţia scripturilor client JavaScript şi a modeluluiDynamic HTML au permis tratarea anumitor evenimente exclusiv la nivelul clientului, evitând latenţade reţea (vezi validarea formularelor), reducând dialogul client-server şi asigurând astfel o experienţăde utilizare mai fluidă, deci o utilizabilitate mărită. Mai departe, modelul AJAX, prin comunicareaasincronă asigură faptul că modulul client funcţionează neîntrerupt ş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 atenţia că diverse browsere potobţine arbori DOM diferiţi din acelaşi cod HTML, ceea ce face parcurgerea arborelui problematică.

Standardul DOM actual, suportat de modelul AJAX, permite astfel de parcurgeri ale arboreluidar oferă şi căi de acces mai facile la noduri, pe bază de atribut id (getElementById) sau prin vectorulgetElementsByTagName. În plus, atributele marcatorilor HTML sunt mapaţi în proprietăţi aleobiectelor-element, după cum s-a văzut deja în exemplele acestui material. Pachete de funcţii precumDojo, Prototype sau Script.aculo.us oferă metode de nivel chiar mai înalt pentru accesul lacomponentele arborelui DOM. Aceste pachete au avut un rol esenţial în adoptarea rapidă a modelului

AJAX pe principiul reutilizabilităţii astfel că în prezent majoritatea aplicaţiilor AJAX nu sunt direct programate în JavaScript, ci sunt programate prin funcţiile pachetelor amintite, ce pot fi considerateblocuri reutilizabile de cod sursă.



75

2.4.1. Manipularea interfeţei cu utilizatorul prin bibliotecaPrototype

Un număr mare de pachete de funcţii JavaScript pentru AJAX sunt construite pe funcţiilepachetului Prototype. S-a arătat anterior că pachetul este uşor de instalat (e vorba de un singur fişier detip .js ce conţine definiţiile tuturor funcţiilor, iar numele fişierului conţine numărul de versiune albibliotecii).

Detaliem câteva din facilităţile Prototype: prescurtarea sintaxei JavaScript; metode noi de localizare a nodurilor DOM (pe bază de stiluri); extinderea claselor JavaScript; funcţii noi pentru lucrul cu colecţii de date (masive, obiecte); ascunderea şi eliminarea facilă de noduri DOM prin clasa Element; inserare facilă de cod HTML în orice poziţie a paginii prin clasa Insertion;

activarea, dezactivarea şi focalizarea facilă a câmpurilor formularelor prin clasele Form şiField; determinarea poziţiei 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")

Funcţia $ poate primi chiar mai multe argumente, returnând un vector: vector=$("id1","id2","id3")

Notă: Prescurtarea $F() e valabilă doar pentru nodurile ce au atributvalue (marcatorii input).

Localizarea în arborele DOM: Prototype oferă o metodă suplimentară de localizare aelementelor din document: getElementsByClassName() identifică elementele prin numele stilului CSSdin atributul class! Metoda e mai degrabă asemănătoare cu getElementsByTagName() prin aceea căreturnează un vector de elemente, datorită posibilităţii ca mai multe porţiuni de document să foloseascăacelaşi stil CSS. Metoda e folosită mai degrabă în versiunea prescurtată sintactic:

noduri=$$("numestil")

Prescurtarea indicată are un caracter mai general decât getElementsByClassName, prin aceeacă poate înlocui şi getElementsByTagName:

noduridiv=$$("div")

Extinderea claselor JavaScript: Prototype adaugă la clasa String proprietatea escapeHTML,similară cu innerHTML, cu diferenţa că browserul nu va mai interpreta marcatorii din şirul decaractere, ci îi va afişa (de exemplu, atunci când e necesară afişare de cod HTML în textuldocumentului):

nod.innerHTML="<b>aaa</b>" afişează în conţinutul nodului aaa nod.escapeHTML="<b>aaa</b>" afişează în conţinutul nodului <b>aaa</b>

Anularea efectului escapeHTML se poate obţine cu funcţia inversă, unescapeHTML.



76

O altă funcţie este stripTags(), care elimină marcatorii din argumentul său de tip string,operaţie utilă atunci când dorim să lucrăm cu conţinut textual ignorând formatul.

Extinderea sintaxei în lucrul cu colecţii de date: Urmând modelul limbajului Ruby,Prototype adaugă un pachet de funcţii numit Enumerables, pentru prelucrarea colecţiilor (masive,obiecte, mulţimi etc.), construite în jurul funcţiei each(), care aplică iterativ o funcţie fiecărui element

din colecţie. Acest fapt este posibil cu ajutorul variabilelor de tip funcţ ie specifice limbajuluiJavaScript.

Exemplul de mai jos calculează suma elementelor unui vector în mod clasic:

suma=0for (i=0;i<numere.length();i++)

{suma=suma+numere[i]}

alert(suma)

Funcţia each() permite ca iteraţia să aibă loc în felul următor, evitând explicitarea ciclului for:

suma=0function aduna(numar)

{suma=suma+numar}

numere.each(aduna)alert(suma)

Se observă că argumentul lui each() este o variabilă de tip function, care apelează funcţiaaduna() pentru fiecare element al vectorului. Aşadar, elementele vectorului care califică each() sunttransferate funcţiei din argumentul acesteia.

Alte funcţii similare cu each() definesc operaţii care să se execute iterativ asupra elementelor unei colecţii de date:

inject() – similar cu each(), dar în plus asigură o iniţializare şi returnează o valoare unicăacumulată în urma apelului repetat al funcţiei -argument; exemplul anterior, cu calculul sumei,va fi simplificat prin injectarea variabilei iniţializate:

function aduna(suma, numar){return suma+numar}

alert(numere.inject(0,aduna))

grep() – argumentele sale vor fi o expresie regulată şi o funcţie ce va fi apelată pentru fiecareelement din colecţie care respectă condiţia dată de expresia regulată; aşadar, e similar cueach() dar foloseşte în plus şi un criteriu de filtrare34;

all() – argumentul va fi o funcţie ce testează o condiţie şi returnează valori booleene; all()returnează true dacă funcţia-argument returnează true pentru toate elementele colecţiei; dacăfuncţia-argument lipseşte, se testează dacă valorile au valoarea true;

numere=[-1,2,3]function pozitive(numar)

{return numar>=0}

alert(numere.all(pozitive))

34 Expresiile regulate sunt măşti de căutare aplicate asupra şirurilor de caractere pentru a face

testarea acestora mai concisă decât prin folosirea funcţiilor de prelucrare a şirurilor de caractere. Pentrusintaxa expresiilor regulate recomandăm tutorialul aflat la adresa http://www.regular-expressions.info/repeat.html.



77

any() – argument similar, dar returnează true dacă există măcar un element în colecţie carerespectă condiţia;

detect() – argument similar; dar returnează primul element pentru care funcţia-argumentreturnează true;

findAll () – argument similar, dar returnează sub formă de vector toate elementele pentru carefuncţia-argument returnează true;

reject() – argument similar, dar returnează sub formă de vector toate elementele pentru carefuncţia-argument returnează false;

partition() – argument similar, dar returnează o matrice care are pe primul rând elementele colecţiei pentru care funcţia-argument returnează true, iar pe al doilea rând cele pentru carefuncţia-argument returnează false:

numere=[-2,-1,2,3]function pozitive(numar)

{return numar>=0}

matrice=numere.partition(pozitive)

include() – similar cu any(), dar argumentul său nu e o funcţie, ci o valoare care va fi căutatăîn colecţie (comparaţia e strictă: case sensitivă şi senzitivă la tipul valorii);

collect() – argumentul va fi o funcţie ce returnează o valoare; valorile returnate pentrufiecare 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 colecţiei; exemplul de mai jos ascunde toate elementele din pagină stocate învectorul a (vectorul b va stoca aceleaşi elemente deoarece invoke, ca şi collect, returnează unmasiv):

a=$("id1","id2","id3")b=a.invoke("hide")

pluck() – argumentul va fi un nume de proprietate (în format string) a cărei valoare va ficitită pentru toate elementele colecţiei, valorile obţinute fiind stocate într -un masiv, ca în cazulcollect; 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 funcţie ce returnează o valoare; max() va returna valoarea maximădintre toate valorile returnate de funcţia-argument în timpul parcurgerii colecţiei;

min() – similar, pentru mini; sortBy() – argumentul va fi o funcţie aplicată fiecărui element din colecţie; sortBy()

returnează un vector cu elementele colecţiei sortate după valoarea funcţiei -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 primeşte argument, converteşte orice tip de colecţie în masiv:



78

obiect.toArray()

Facilităţi Prototype privind interfaţa utilizatorului

Definirea clasei Element. Prototype defineşte această clasă în mod static, deci nu trebuie

instanţiată, proprietăţile sale fiind direct accesibile oricărui obiect-element. Clasa Element încapsuleazănumeroase mecanisme frecvente în manipularea paginii AJAX. Spre exemplu, oferă o funcţie pentrucontrolul vizibilităţii 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') >

Funcţia Element.toggle() comută vizibilitatea nodului din argument. Similar, clasa Elementoferă funcţiile show() şi hide() pentru afişare şi ascundere de noduri.

Notă: Avertizăm asupra faptului că nodurile ascunse pot să influenţezetotuşi comportamentul paginii. Spre exemplu dacă se ascund câmpuri ale

unui formular, acestea vor trimite totuşi date serverului la folosireabutonului submit. De asemenea, JavaScript va continua să aibă acces lanodurile ascunse.

Un alt mecanism frecvent este eliminarea de noduri DOM, realizată de regulă prin resetarea proprietăţii innerHTML sau cu metoda removeChild(), acestea fiind precedate de necesitatea de alocaliza nodul dorit. Clasa Element oferă Element.remove() care preia ca argument atributul id alnodului de şters.

Definirea clasei Insertion. Rolul clasei este de a oferi metode de inserare în grupuri deelemente consecutive. Poziţiile de inserare sunt sugerate de numele funcţiilor:

Top – începutul grupului; Bottom – sfârşitul 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=AdaugaInceputonclick="new Insertion.Top('lista','<li>'+$F('valoare')+'</li>')"><input type=button value=AdaugaSfarsitonclick="new Insertion.Bottom('lista','<li>'+$F('valoare')+'</li>')"><input type=button value=AdaugaInainteonclick="new Insertion.Before('lista','<b>'+$F('valoare')+'</b>')"><input type=button value=AdaugaDupaonclick="new Insertion.After('lista','<b>'+$F('valoare')+'</b>')">

Exemplul defineşte patru butoane ce execută funcţiile Insertion, inserând relativ la o listăvaloarea tastată în câmpul cu id=valoare.

Clasa Insertion poate primi ca argument orice grup de noduri consecutive. Alte scenarii uzualear fi:

inserare relativ la rândurile unui tabel – în loc de blocul ul se va crea un bloc table iar funcţiilede inserare vor conţine, în loc de li, marcatori pentru rând şi celulă;

inserare relativ la elementele unui formular; inserare relativ la componentele unui bloc div.

Exemple:



79

<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=AdaugaInceputonclick="new Insertion.Top('formular','<input type=text value='+$F('valoare')+'><br>')"><input type=button value=AdaugaSfarsitonclick="new Insertion.Bottom('formular','<input type=text value='+$F('valoare')+'><br>')">

În acest caz butoanele AdaugaInceput şi AdaugaSfarsit inserează noduri noi la începutul şisfârşitul unui formular. Nu am mai reluat exemplele pentru inserare Before şi After, acesteafuncţionând oricum, independent de tipul grupului de elemente despre care e vorba. Grupul deelemente poate f i ş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=AdaugaInceputonclick="new Insertion.Top('blocdiv','<b>Imagine0<b><img src='+$F('numefisier')+'><br>')">

Deoarece funcţiile Insertion permit explicitarea codului HTML ce va fi inserat (al doileaargument), utilizarea lor nu e limitată la colecţii omogene de noduri (formulare, tabel e, liste) ci e

permisă la orice grup de noduri fraţi grupate sub un marcator identificabil, după cum se vede în ultimulexemplu.

Notă: Avertizăm asupra faptului că funcţiile Insertion permit doar inserare de cod HTML ce reprezintăunul sau mai multe noduri complete şi NU noduri parţiale. Spre exemplu, nu e posibilă încapsulareagrupului manipulat prin două apeluri de genul...

Insert.Before("bloc","<div id=blocnou>") Insert.After("bloc","</div>")...deoarece nici una din cele două funcţii nu inserează noduri complete. Regula e valabilă pentru toatefuncţiile Insertion.

Extinderea metodelor de lucru cu formulare. Prototype încurajează abordarea formularelor ca şi colecţii de date mai degrabă decât ca şi subarbori ai arborelui DOM. Pentru aceasta, oferă metod ede acces mai rapid la conţinutul formularelor sau la formulare în ansamblul lor:

Field.select() – selectează valoarea curentă a unui câmp; Field.focus() – mută cursorul de focalizare pe câmpul dorit; Field.activate() – combinaţie între select() şi focus(); Form.disable(), Field.disable() – dezactivează câmpurile formularului; Form.enable(), Field.enable() – face accesibile câmpurile formularului;

Form.focusFirstElement() – mută cursorul de focalizare la începutul formularului, pe primulcâmp.<html><head><script type=text/javascript>

.........function campurinoi(){Element.toggle('detalii')Field.activate('TXadresa')Field.disable}...........

</script></head>

<body>........<form>



80

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 defineşte un formular cu o porţiune vizibilă implicit, cu două câmpuri, şi o adoua porţiune care devine vizibilă doar la clic pe textul afişat cu roşu (inclus în blocul div ce apeleazăfuncţia de activare a câmpului Adresa.

Funcţiile enable() şi disable() sunt disponibile atât la nivel de formular cât şi la nivel de câmp,având o utilitate deosebită în a converti un formular între stările read -only şi editabil, de exemplu ca şiconsecinţă a apăsării de către utilizator a unui buton de editare.

Accesul la poziţia elementelor pe pagină. Prototype oferă o serie de mecanisme pentru aidentifica poziţia relativă a elementelor, inclusiv poziţia faţă de suprafaţa vizibilă a paginii într -ofereastră cu bare de derulare. Nu insistăm asupra acestor mecanisme, deoarece ele sunt dejaîmpachetate în funcţii de nivel şi mai înalt, precum cele oferite de biblioteca Scrip.aculo.us.

2.4.2. Manipularea interfeţei cu utilizatorul prin bibliotecaScript.aculo.us

Script.aculo.us este una din cele mai cunoscute biblioteci JavaScript orientate spre interfaţa cuutilizatorul, ce încapsulează instrumentele oferite de pachetul Prototype în funcţii de nivel şi mai înalt.Componentele pachetului vizează:

Efecte de animaţie aplicabile oricăror şi oricâtor elemente din pagină, similare celor din prezentările Powerpoint; Emularea unui mecanism drag-and-drop similar celui consacrat de aplicaţiile desktop; Componente ce încapsulează funcţionalităţi de nivel înalt precum mecanismele avansate de

editare sau completare a casetelor de text; Componente ce permit testarea interfeţei utilizatorului.

Autorul pachetului este Thomas Fuchs. Succesul Script.aculo.us e garantat de adoptareapachetului în designul unor site-uri de renume. Pachetul poate fi descărcat gratuit la adresahttp://script.aculo.us. Instalarea sa presupune:

Identificarea a 9 fişiere de tip js în arhiva descărcată. În versiunea actuală, 1.8.1, acestea seaflă în folderul src al pachetului (8 dintre ele) şi în folderul lib (fişierul prototype.js). Fişierulprototype.js este chiar biblioteca Prototype care este aşadar inclusă în bibliotecaScript.aculo.us;

Copierea celor 9 fişiere într -un folder dedicat stocării bibliotecii, în cazul nostru acesta vaavea numele scriptaroot, în rădăcina serverului Web;

Scripturile ce vor folosi funcţii Script.aculo.us vor include două apeluri de biblioteciJavaScript, una pentru Prototype (versiunea Script.aculo.us) şi una pentru Script.aculo.us (careconţine apelurile celorlale 7 fişiere):

<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 instalareaversiunii din pachetul Script.aculo.us, pentru a evita risculincompatibilităţilor între Script.aculo.us şi Prototype. În exemplele

materialului de faţă ultima versiune Prototype e apelată din folderulprotoroot iar versiunea Script.aculo.us pentru Prototype e apelată dinfolderul scriptaroot.



81

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. Fiecareefect este o tranziţie între două stări, aşadar fiecare efect permite fixarea unui punct iniţial şi a unui

punct final, precum şi durata desfăşurării. Unele efecte sunt parametrizate cu coordonate ale ecranuluisau distanţe. Toate efectele sunt asincrone în sens AJAX35, deci execuţia lor nu întrerupe execuţia şi

experienţa utilizării, deci multiple efecte pot fi aplicate simultan aceluiaşi element. EfecteleScript.aculo.us sunt o resursă deosebită pentru promovarea utilizabilităţii aplicaţiilor Web.

Sintaxa generală a unui efect este:

new Effect.NumeEfect(element,parametri,{optiuni})

Cuvântul cheie new este opţional (ca şi var la declararea variabilelor), rolul său fiind să indiceun obiect nou creat.

Opţiunile sunt enumerate în format JSON. Cele mai uzuale dintre ele sunt: duration – în secunde; fps – frecvenţa de afişare a stărilor intermediare ale animaţiei (numărul de afişări pe secundă,

implicit 25);

sync – boolean, pentru sincronizarea frecvenţei de afişare la efecte simultane; from – punctul de start al efectului; to – punctul de stop al efectului; transition – algoritmul tranziţiei, cu variante precum (se prefixează cu Effect.Transitions):

o sinoidal – viteză accelerată până la un punct, apoi decelerată; o linear – viteză constantă; o reverse – viteză constantă cu inversarea punctelor de start şi stop; o wobble – mişcare dus-întors repetată pe distanţe aleatoare; o flicker – salt între poziţii intermediare dintre start şi stop; o pulse – mişcări 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 peextremităţile animaţiei. Considerăm un efect MoveBy ce deplasează un element cu 100 de pixeli ladreapta şi în jos:

new Effect.MoveBy("idelement",100,100,{from:0.0,to:0.5})

Deplasarea suferită de element e definită pe distanţa 100x100 (distanţe negative vor permitedeplasări la stânga sau în sus; prima valoare e verticala, a doua orizontala36). Se observă enumerareaopţiunilor în format JSON, aşadar acestea pot fi anterior stocate într -un obiect. Opţiunile acestuiexemplu fixează:

punctul de start 0.0 corespunde poziţiei curente; punctul de stop 0.5 indică faptul că deplasarea se va opri la jumătatea distanţei prevăzute,

aşadar distanţa parcursă va fi de fapt 50x50. Prin urmare, opţiunile unei animaţii funcţionează şi ca modificatori pentru parametrii funcţiei.

O facilitatea foarte puternică este posibilitatea de a asocia funcţii JavaScript ca handlere pentru diverse stări intermediare ale efectelor . Caracterul asincron al efectelor trebuie pus în balanţă cucu mecanismele de dialog cu utilizatorul. Spre exemplu, dacă derularea unei animaţii afişează o casetăalert(), animaţia nu se va fi întrerupe implicit în timpul interacţiunii cu caseta de dialog.

Exemplu:

<html><head><script type=text/javascript src=scriptaroot/prototype.js></script><script type=text/javascript src=scriptaroot/scriptaculous.js>

35 A nu se confunda execuţia asincronă a efectelor cu posibilitatea afişării lor sincronizate,

care se referă strict la aspectul lor vizual. 36 Atragem atenţia că ordinea este inversă faţă de cea intuitivă, consacrată. E posibil să fievorba de un bug.



82

</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 funcţia handler a evenimentului click, unui bloc div. Pentru a înţelege ce se ascunde în spatele efectelor Script.aculo.us, recomandăm observareacodului sursă a paginii cu instrumentul de depanare Firebug.

Imaginea indică faptul că, la nivel de cod, efectul s-a obţinut prin modificarea /creareaatributului style a blocului div ce marchează paragraful! Mai exact, prin MoveBy s -au modificat

proprietăţile CSS legate de poziţie. În lipsa bibliotecii Script.aculo.us, efecul s-ar fi putut obţine princonstrucţia:

stilnou="position:relative; left:50px; top:50px"document.getElementById("blocdiv").style.cssText=stilnou

Evident, efectele Script.aculo.us oferă o economie semnificativă de efort atât în editareacodului sursă cât şi în gândirea algoritmilor de tranziţie. Spre exemplu, algoritmul flicker se obţineprintr-o formulă matematică de randomizare a poziţiilor intermediare ce implică funcţii JavaScriptprecum cos(), random() şi chiar Math.PI.

În cele ce urmează, detaliem efectele fundamentale oferite de Script.aculo.us:

Opacity() – modifică opacitatea (transparenţa) unui element al paginii, între extremele 0%(0.0, invizibil) şi 100% (1.0, opac). Avertizăm că opacitatea 0 nu e acelaşi lucru cu comutareavizibilităţii elementului (deci funcţii Prototype ca Element.show() sau Element.toggle() nu vor avea



83

efect asupra unui element transparentizat până la invizibilitate!). Aceasta se datorează faptului căopacitatea şi vizibilitatea sunt proprietăţi CSS diferite (opacity şi display sau visibility). Mai exact, unobiect complet transparent ocupă totuşi o porţiune din suprafaţa afişată a paginii. Un obiect ascuns nuocupă spaţiu în pagina afişată. Din acest motiv multe animaţii de transparentizare sunt finalizate printr -o operaţie explicită de ascundere a obiectului prin comutarea proprietăţii display la valoarea "none" sauvisibility 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 stări intermediarealeatoare</div></div></body></html>

Exemplul poate fi verificat tot prin clic pe paragraful afişat. De data aceasta, paragraful devinetransparent (from 1 to 0!) trecând prin stări intermediare aleatoare (flicker). Efectul de pâlpâire seobţine dacă în loc de flicker se folosesc tranziţii de alternare între punctul de start şi de stop (pulse,wobble).

MoveBy() – asigură poziţionarea elementelor pe pagină. Parametrii săi obligatorii sunt

distanţele orizontală şi verticală relativ la poziţia curentă (deci valori negative indică deplasare sprestânga sau sus). Un efect frecvent întâlnit este scuturarea elementului pentru a atrage atenţia asupra sa(pulse aplicat pe o distanţă scurtă).

Scale() – la dimensionarea elementelor paginii trebuie să se ţină cont de două aspecte: fixareaunui colţ al elementului care să rămână fix în timpul dimensionării şi comportamentul elementelor imbricate în timpul dimensionării elementului care le conţine. Pentru aceasta, opţiunile funcţiei sunt:

scaleX: boolean (implicit true), stabileşte dacă e permisă dimensionarea pe lăţime; scaleY: boolean (implicit true), stabileşte dacă e permisă dimensionarea pe înălţime; scaleContent: boolean (implicit true), stabileşte dacă elementele conţinute se redimensionează

proporţional cu elementul părinte; există o serie de limitări în ce priveşte dimensionareaelementelor conţinute:

o funcţia nu dimensionează elementele img (acestea trebuie să sufere propriul efect dedimensionare);

o în unele browsere funcţia dimensionează textul doar dacă acesta a fost formatatexplicit cu dimensiunea exprimată în unităţi em (dimensiunea standard a literei m);

scaleFromCenter: boolean (implicit true), stabileşte dacă centrul elementului rămâne fix întimpul dimensionării;

scaleMode: valoarea box implicită stabileşte să se dimensioneze doar porţiunile elementuluice sunt vizibile fără derulare; valoarea content dimensionează complet elementul;

scaleFrom: procentajul din dimensiunea curentă de la care să înceapă dimensionarea, implicit100%.

<html><head><script type=text/javascript src=scriptaroot/prototype.js>

</script><script type=text/javascript src=scriptaroot/scriptaculous.js></script>



84

<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ă mărirea imaginii la clic pe bara de titlu a unei ferestrei simulate. Prinaceasta sugerăm posibilitatea de a crea în AJAX o interfaţă bazată pe ferestre simulate, în care fiecare

fereastră e definită ca un bloc div de conţine alte două blocuri div, pentru bara de titlu şi pentruconţinutul ferestrei. Diverse efecte pot reacţiona prin handlere la diverse evenimente ale utilizatorului,

pe diverse porţiuni ale paginii, în cazul de faţă, clic pe bara de titlu. P reluarea acestei sarcini de către unelement de tip imagine (un buton, o bară de scalare) poate aduce interfaţa AJAX mai aproape deinterfeţele aplicaţiilor desktop, aducând un semnificativ plus de utilizabilitate!

Highlight() – acest efect schimbă culoar ea de fundal a elementelor trecând prin spectrulculorile intermediare. În forma implicită, efectul aplică modelul Yellow Fade, adică tranziţie rapidă, detip flash, la galben şi înapoi, pentru a atrage atenţia utilizatorului asupra unui element al paginii. Efectulnu afectează elementele care au deja o culoare de fundal stabilită prin CSS. Opţiunile suplimentare aleefectului permit modificarea culorilor:

startcolor: culoarea iniţială 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 doreşte să fie alta decât culoarea

implicită de fundal a paginii. Valorile culorilor trebuie să fie coduri RGB hexazecimale introduse ca şiruri de caractere.

Animaţia Highlight este, la bază, un algoritm de modificare a codului de culoare pentru proprietateaCSS "background-color" în cadrul unui ciclu for care modifică sincron valorile R, G şi B din codulculorii.

Se poate remarca faptul că Script.aculo.us oferă instrumente de un nivel atât de înalt încât percepţia progamatorului asupra documentului se mută dinspre structura DOM (necesară atunci cândse gândeşte în termeni de noduri şi localizarea lor în arbore) spre suprafaţa ocupată pe ecran deelementele formatate (necesară atunci când 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>



85

Continutul ferestrei</div>

</div>

</body></html>

În acest exemplu, la clic pe bara de titlu, fereastra primeşte un flash de culori variind de laroşu la verde. Se poate remarca faptul că bara de titlu rămâne neafectată datorită stilului CSS predefinit.

Parallel() – permite aplicarea simultană a mai multor efecte şi primeşte ca argument listaefectelor sub formă de vector în sintaxă JSON. Permite aplicarea de opţiuni comune tuturor efectelor,de exemplu fixarea unei durate comune. Exemplul de mai jos creează 4 efecte simultane asupraaceluiaşi element, sincronizate ca durată şi frecvenţă de afişare (frame-rate). Animaţiile se declanşează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 pebaza celor fundamentale:

Effect.Appear() – opacitate iniţială 0, crescută la 100 şi asigurarea vizibilităţii (dacă elementul

a fost definit ca ascuns prin proprietatea CSS display care, reamintim, nu poate fi controlatăprin opacitate); Effect.Fade() – opacitate iniţială 100, coborâtă la 0 şi ascunderea elementului în final; Effect.Puff() – explozie: dublarea dimensiunii simultan cu transparentizarea şi în final

ascunderea elementului; Effect.BlindUp() – micşorare verticală la 0, fără micşorarea conţinutului şi în final ascundere; Effect.BlindDown() – mărire verticală la maxim, fără mărirea conţinutului şi în final

asigurarea vizibilităţii; Effect.SwitchOff() – colapsarea elementului cu pâlpâire (implică micşorare centrată şi

opacitate flicker); Effect.DropOut() – deplasare simultană cu transparentizare; Effect.SlideDown() – alunecare în jos şi dispariţie a unui element div fiu din cadrul suprafeţei

unui unui element div părinte; Effect.SlideUp() – opusul efectului anterior; Effect.Squish() – micşorare bruscă şi ascundere;



86

Effect.Shrink() – idem, cu micşorarea conţinutului; Effect.Grow() – mărirea centrată elementului începând de la 0; Effect.Pulsate() – pâlpâire pulsatorie, alternanţă de Appear şi Fade; Effect.Shake() – scuturarea orizontală (deplasare de tip pulse); Effect.Fold() – împăturire (combinaţie 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 cunoştinţelor Care sunt avantajele paradigmei Rich Client față de siteurile tradiționale? Ce aspecte din siteurile tradiționale nu sunt suportate de obiectul XMLHttpRequest? Ce instrumente oferă biblioteca Prototype? Ce instrumente oferă biblioteca Scriptaculous? Ce instrumente oferă biblioteca Dojo?

În ce fel deservește AJAX paradigma Rich Client? Ce rol are instrumentul Firebug?



87

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 comerţului electronic 3.3. Tipologia pieţelor electronice globale 3.4. Categorii de tranzacţii electronice 3.5. Modele de afaceri electronice 3.6. Caracteristici ale comerţului electronic 3.7. Componentele comerţului electronic 3.8. Arhitectura de bază 3.9. Managementul relaţiei cu clienţii 3.10. Managmentul liniei de aprovizionare 3.11. Modalităţi 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

Recomandări

Parcurgerea unor articole din presa on-line Parcurgerea de studii de caz pe Internet

Rezultate aşteptate

Asimilarea conceptelor specifice domeniului e-business Asimilarea modelelor de afaceri electronice consacrate Asimilarea modelelor de management implicate în e-business

RecapitulareModulul anterior a prezentat principiile de implementare a modelului AJAX, oferind totodată

încadrarea modelului în paradigma Rich Client și compararea sa cu soluțiile de nivel superior – Dojo,Prototype și Scriptaculous. S-a insistat asupra mecanismelor de comunicare asincronă prin structuri dedate XML și JSON.

În continuare se prezintă sintetic modelele de afaceri electronice consacrate și, în contextulacestora, o serie de detalii privind comerțul electronic, avantajele și limitele fenomenului.



88

3. Categorii de afaceri pe Internet

3.1. Concepte de e-afaceri

Piaţa electronică (marketspace) reprezintă spaţiul virtual ce permite stabilirea unor relaţii de parteneriat între cumpărători şi vânzători, unde se tranzacţionează afaceri electronice. Apariţia acestuispaţiu extrem de vast în care firmele îşi pot desfăşura activitatea transformă pieţele locale ale diferitelor

produse în pieţe naţionale sau chiar internaţionale, competiţia se intensifică pe fondul concurenţeifirmelor din întreaga lume care au acces la spaţiul virtual, asistând astfel la o adevărată revoluţie adomeniului economic. Reacţia firmelor la aceste tendinţe se manifestă prin modificarea modului deorganizare şi de acţiune, începând să comprime vechile structuri ierarhice şi să elimine bariereleexistente între compartimentele operaţionale. Se tinde de asemenea, spre renunţarea la barierele dintrefirmă şi clienţii sau furnizorii acestora.

Tendinţa actuală a multor firme este utilizarea Web-ul pentru a se face cunoscute, prinintermediul celei mai importante surse de informare din societatea informaţională – Internetul. Pentru adeveni un furnizor de informaţii, trebuie să posede o pagină unică de pornire (home page), cu ajutorulcăreia orice firmă poate deveni parte din Web, îşi poate oferi bunurile şi serviciile şi diverse informaţiiutile vizitatorilor site-ului.

Principalele direcţii ale utilizării Internetului în afaceri pot fi concretizate astfel: comunicaţie şi administrare a informaţiilor; asistenţă tehnică şi servicii pentru clienţi; vânzări directe; cercetări de marketing; publicitate on-line; cerere on-line; întreţinerea unei imagini publice; stabilirea unor reţele pentru cumpărători.

Astfel s-au dezvoltat căteva 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) - acţiuni pe Internet şi altele.

Marketspace (piaţa electronică) reprezintă spaţiul virtual ce permite stabilirea unor relaţii de parteneriat între cumpărători şi vânzători, unde se tranzacţionează afaceri electronice. Deja estearhicunoscut faptul că mediul comercial contemporan se caracterizează prin creşterea continuă a

producţiei, accentuarea concurenţei globale şi creşterea gradului de diversificare a cerinţelor consumatorilor. Reacţia firmelor la aceste tendinţe se manifestă prin modificarea modului deorganizare şi de acţiune, începând să comprime vechile structuri ierarhice şi să elimine bariereleexistente între compartimentele operaţionale. Se tinde de asemenea, spre renunţarea la barierele dintrefirmă şi clienţii sau furnizorii acestora.

Literatura de specialitate oferă o serie de definiţii ale acestui termen. Pornind de la analiza

critică a unora dintre acestea vom încerca să surprindem principalele elemente componente alecomerţului electronic şi nu în ultimul rând principalele avantaje şi dezavantaje pe care acest fenomen îlimplică.

Afacerile electronice (Electronic Business, e- business) reprezintă mulţimea afacerilor asistateşi bazate pe telecominicaţii şi informatică. Comerţul electronic este definit ca ―ansamblul tranzacţiilor comerciale în cadrul cărora părţile contractante interacţionează prin intermediul calculatoarelor şi nu

prin schimburi fizice sau contacte directe‖. Deşi este corectă, o astfel de definiţie nu poate captaintegral spiritul comerţului electronic care, în practică reprezintă una din situţiile în care nevoile tot maicomplexe şi tehnologiile noi se contopesc pentru a revoluţiona modul în care se derulează afacerile. Inconcepţia OECD (Organizaţia Economică de Cooperare şi Dezvoltare) comerţul electronic reprezintă„desfăşurarea unei afaceri prin intermediul reţelei Internet, vânzarea de bunuri sau servicii având locoffline sau online‖. Definiţia elaborata de R.Kolakota şi A.Whinston în lucrarea Frontier of electroniccommerce apărută în 1996: Comerţul electronic este o metodă modernă de efectuare a afacerilor, carese adresează nevoilor firmelor, pieţelor şi clienţilor prin reducerea costurilor concomitent cuîmbunătăţirea calităţii produselor şi serviciilor precum şi creşterea vitezei de oferire a acestora.



89

O altă definiţie este dată de NTIA - National Telecomunications and InformationAdministration, definind comerţul electronic într -un sens larg ca fiind utilizarea oricărei tehnologiielectronice în orice aspect al activităţii comerciale. Într-un sens mai restrâns termenul înseamnăutilizarea infrastructurii naţionale de informare, pentru realizarea uneia dintre următoarele funcţii:

atragerea produselor pe piaţă; intermedierea cumpărătorilor şi vânzătorilor;

comunicarea cu guvernul pentru urmărirea comerţului; cumpărarea electronică a produselor.

Kalakota şi Whinston (1997) definesc comerţul electr onic din mai multe perspective: din perspectiva tehnologiei comunicaţiilor – livrarea de informaţii, produse şi servicii sau

plata bunurilor utilizând orice metodă electronică din perspectiva proceselor de afaceri – utilizarea tehnologiei informaţionale în vederea

automatizării tranzacţiilor şi fluxurilor de afaceri din perspectiva serviciilor – posibilitatea reducerii costurilor şi în acelaşi timp al creşterii

calităţii şi vitezei serviciilor prin utilizarea tehnologiei informaţionale din perspectiva online – capacitatea de a cumpăra şi vinde produse, informaţii online

Computer Desktop Encyclopaedia (www.computer language.com) defineşte sintaxa ‖a faceafaceri online‖ astfel: ‖Acest proces include cumpărarea produselor, prin servicii online şi Internet,

precumn şi schimbul de date electronice, prin care calculatorul unei instituţii se informează şi transmite

ordine de cumpărare calculatorului altei companii. ‖ O modalitate diferită de definire a acestui concept descrie comerţul electronic atât din

perspectiva firmelor, cât şi din cea a consumatorilor . ”Pentru unele firme, comerţ electronic înseamnăorice tranzacţie financiară care utilizează tehnologia informatică . Pentru altele, noţiunea de comerţelectronic acoperă circuitul complet de vânzări – inclusiv marketing-ul şi vânzarea propriu-zisă.Indivizii consideră comerţul electronic ca fiind orice tranzacţie comercială condusă electronic pentrucumpărarea unor produse cum ar fi cărţi, CD-uri, bilete de călătorie, informaţie ş.a.m.d”37 .

Din multitudinea de definiţii ale comerţului electronic se pot desprinde câteva idei de bazăreferitoare la acest concept. În primul rând comerţul electronic poate fi considerat un proces economiccomplex, care implică mai multe componente: instituţii, procese şi infrastructura informaţională.

Componentele comerţului electronic38

Comerţul electronic produce schimbări esenţiale în cadrul organizaţiilor, 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 schimbãtor, tehnologia evolueazãrapid şi regulile competiţiei se schimbã. În aceste condiţii utilizarea Internetului şi a facilităţilor acestuia oferă o şansă firmelor de orice mărime să acţioneze pe o piaţă dinamică şi să obţină un câştigîn condiţiile unei afaceri virtuale de succes. Astfel firmele mici pot obţine o vizibilitate mai mare şiacces la clienţi din întreaga lume, în timp ce pentru firmele mari, comerţul electronic oferă posibilitatea

37 Daniela Rusu - ”Comerţul şi afacerile mobile, extensii ale comerţului şi afacerilor

electronice”, teză de doctorat, 2005 38 Sursa: Kosiur, D., Understanding Electronic Commerce (How OnlineTransaction CanGrow Your Business), Microsoft Press, Redmond, Washington, 1997, p. 6

INSTITUŢII GuvernulProducători

Comercianţi Furnizori

Consumatori

PROCESEMarketingVânzări

Plăţi Suport

REŢELE PropriiInternet

Comerciale

Comerţ electronic



90

apropierii şi a unei bune comunicaţii cu clienţii, avantaj exclusiv al firmelor mici. E -commerce oferã ooportunitate pentru a obţine un avantaj maxim, dar aceastã oportunitate trebuie sã fie planificatã.

Comerţul electronic oferă firmelor din întreag lume şi de diferite dimensiuni avantajesemnificative. În acest sens, Dave Chaffey39 identifică atât avantaje tangibile (care pot fi cuantificate),cât şi intangibile (nu pot fi cuantificate).

AVANTAJELE TANGIBILE

Creşterea vânzărilor, care conduce la creşterea veniturilor prin câştigarea de: noi clienţi, noi pieţe de desfacere clienţi existenţi (vânzări repetate) clienţi existenţi (vânzări indirecte)

Reducerea costurilor de marketing prin: reducerea timpului de servire a clienţilor vânzări online reducerea costurilor privind imprimarea şi distribuirea elementelor de publicitate

Reducerea costurilor de aprovizionare:

nivel redus al inventarului creşterea competiţiei între furnizori reducerea timpului de procesare a comenzilor

Reducerea costurilor administrative prin intermediul unor procese de afaceri mai eficiente, cum arcrutarea personalului sau plata facturilor

AVANTAJE INTANGIBILE

Prezentarea imaginii firmeiBrandulCampanii de marketing mai rapide şi mai eficiente, inclusiv PRCicluri de producţie ale produselor mai rapide, care permit o adaptare mai rapidă la cerinţele pieţei Îmbunătăţirea serviciilor oferite clienţilor

Adaptarea la cerinţele viitorului Satisfacerea dorinţelor consumatorilor cât mai bine Identificarea de noi parteneri de afaceri şi imbunătăţirea relaţiilor cu partenerii mai vechi Un management mai bun al informaţiilor de marketing şi mai ales al celor referitoare la clienţi Feedback din partea clienţilor în ceea ce priveşte produsele sau serviciile oferite

Principalele avantajele ale comerţului electronic40

Ca şi un mediu comercial, Web oferă un număr important de beneficii care pot fi examinateatât la nivelul consumatorilor cât şi la nivelul firmelor.

Un beneficiu important al consumatorilor este accesul la cantitatea mare de informaţiidinamice pentru sprijinirea luării deciziilor. În plus caracterul interactiv a Web-ului permite căutaremai adâncă, neliniară iniţiată şi controlată de clienţi. De acum încolo, comunicarea prin Web este maimult condusă de client, faţă de mass-media tradiţională, dirijată de cerinţele furnizorului.

Abilitatea Web-ului de a aduna, analiza şi controla cantităţi mari de date poate permitecompararea cumpărărilor şi accelerarea procesului de găsire a articolelor. Web-ul facilitează proba şi permite pe moment o satisfacţie, clienţii pot testa produsele online ceea ce stimulează cumpărările. Deasemenea există probabilitatea ca produsele greu de găsit să fie disponibile şi o selecţie mai largă aarticolelor datorită lărgimii şi eficienţei Web-ului. În plus avantajele pentru consumatorii industrialisunt date de costurile reduse datorită competiţiei în procurarea materiilor prime, deoarece mai mulţifurnizori 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.

39 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



91

Din poziţia de cumpărător, câştigul esenţial este timpul deoarece acelaşi produs / serviciu poate fi cumpărat mai ieftin, putând fi vizitate mai multe magazine într-un timp scurt.

Din punct de vedere al companiilor ce utilizează comerţul electronic avantajele sunt multiple: creşterea semnificativă a vitezei de comunicare, în special pentru comunicaţiile internaţionale; îmbunătăţirea eficienţei, dat fiind faptul că datele nu mai trebuie retastate manual atât în

calculatorul vânzătorului, cât şi al cumpărătorului, permiţând mâinii de lucru să fie utilizată mai

productiv; erorile de retastare se elimină; ciclurile de producţie şi cumpăr are se reduc drastic reducerea unor costuri, utilizând e-mail-ul scad costurile cu poşta sau mesagerie iar EDI poate

însemna o mare reducere a stocurilor şi a costurilor legate de ciclul de cumpărare; întărirea relaţiilor cu clienţii şi cu furnizorii, prin site-ul Web al companiei care prezintă permanent

partenerilor ultimele informaţii necesare acestora iar EDI implică lucrul într -o strânsă legătură apartenerilor;

o cale rapidă şi comodă de furnizare a informaţiilor despre o companie sau despre produsele saleprin intermediul unor site-uri www, a Intranet-urilor sau Extranet-urilor.

canale alternative de vânzare, cum sunt afacerile prin intermediul unui site Web.1. Beneficii pentru firme

Extinderea la pieţe internaţionale; Scădera costului de creare, procesare, distribuire, păstrare şi găsire a informaţiei bazată pe hârtie; Creează posibilitatea modelării produselor şi serviciilor pe nevoile cumpărătorilor;

Costuri de comunicaţie mai mici. 2. Beneficii pentru consumatori

Dă posibilitatea consumatorilor să cumpere sau să facă tranzacţii 24h/zi, în tot timpul anului dinaproape orice locaţie;

Acordă consumatorilor mai multe posibilităţi de alegere; Cumpărătorii pot să aleagă mai uşor 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 străzi şi popualre scăzută a aerului; Permite ca anumite mărfuri să fie vândute la preţuri mai scăzute, cu avantaje pentru cei cu ven ituri

mai mici; Creşte eficienţa şi/sau îmbunătăţesc calitatea.

Beneficiile firmei sunt canalizate îndeosebi în domeniul distribuţiei, comunicării, precum şi beneficiioperaţionale. Prin utilizarea Web-ului ca un canal de distribuţie, costurile de distribuţie sau costulvânzării se contractează la zero. Acesta este mai probabil în domeniul publicităţii, furnizareainformaţiilor sau produse digitale. Mai mult, cumpărătorii şi vânzătorii se pot contacta direct eliminândcheltuieli de marketing şi constrângerile impuse de asemenea interacţiuni în lumea terestră, făcânddistribuţia mai eficientă. Timpul pentru desăvârşirea tranzacţiilor comerciale se reduce, transformându-se în eficienţe adiţionale. Tehnologia oferă firmelor oportunitatea de a monitoriza aleger ileconsumatorilor prin dezvăluirea preferinţelor lor în comportamentul de navigare şi cumpărare prinWeb.

În general firmele utilizează Web-ul pentru a furniza informaţii despre firmă şi despre oferta lor, precum şi pentru comunicare internă şi externă cu alte firme şi consumatori. Site-urile Web sunt ladispoziţia clienţilor 24 de ore pe zi,7 zile pe săptămână. Caracterul interactiv al mediului poate fi folosit

de marketeri pentru atragerea atenţiei clienţilor, prin angajarea lor într -un dialog care este o comoditate pentru ambele părţi, acesta oferind oportunitatea de a croi comunicaţie precisă cu consumatoriiindividuali, permiţând clienţilor de a solicita informaţii cât doresc. Obţinerea informaţiilor relevantedespre clienţi, care sunt utilizate în scopul de a servi mai eficient în viitor permite firmelor să deainformaţii clienţilor despre ofertele lor şi de a obţine informaţii despre clienţi, despre necesităţi,

preferinţele lor. Un aspect important este oportunitatea competiţiei bazate pe axele specialităţii în locde axele preţurilor.

Beneficiile operaţionale ale Web-ului, în cazul vânzărilor, sunt erori reduse şi câştig de timp în procesarea informaţiilor; costuri reduse prin accesarea electronică a bazelor de date a ofertei. În pluseste facilitată crearea de noi pieţe şi segmente de piaţă precum şi intrarea mai uşoară pe pieţeleexistente şi timp mai redus pentru tranzacţii. Prin acesta este mai uşoară şi mai ieftină găsirea clienţilor

potenţiali eliminând şi obstacolele dintre diferiţi paşi ai subproceselor de afaceri.



92

3.2. Bariere în calea succesului comerţului electronic

Indiferent de tipul de comerţ electronic abordat, acesta întâmpină o serie de dificultăţi şi bariere mai mari sau mai mici, în funcţie 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

desfăşurarea afacerilor de comerţ electronic, identificarea acestora fiind un punct de plecare în găsireacăilor de reducere sau înlătur are a lor. Sistemul de livrare a produselor la scară globală. Una din principalele bariere în calea

dezvoltării pieţelor internaţionale îl reprezintă complicaţiile vamale, de impozitare şiformalităţile cu transportul. Principalul obstacol, care continuă să existe, este cel legat dedistribuţia globală a bunurilor şi serviciilor.Un alt obstacol se referă la dificultatea de a derulalivrarea şi/sau expediţia unor loturi (pachete) mai mici. Cercetările din ţările membre ale UEevidenţiază complicaţii ale transportului internaţional şi datorită fragmentării logisticilor inter -ţări.

Diferenţă de cultură, limbă şi practică comercială. Aceasta include, şi cultura afacerilor şipractica propriu-zis comercială. Adesea dificultăţile în comerţul electronic global sunt createde diferenţele în sistemele legislative. În domeniul serviciilor juridice, pieţele electroniceglobale nu se pot crea cu uşurinţă, excepţie făcând unele domenii -nişă, cum ar fi practica

juridică internaţională pentru cazul marilor corporaţii. Fragmentarea în industrie. În ţările în care industria este divizată în multe firme mici, poatefi deosebit de greu să se atingă economia de scară necesară creării unei pieţe electroniceglobale, chiar dacă piaţa produsului de bază, potenţial, poate fi considerată globală. Internet-ulşi pieţele electronice pot crea presiuni adiţionale în scopul consolidării industriilor fragmentate, în mod similar cu serviciile financiare asigurările, transporturile şi turismul

Cadrul global autoreglator şi juridic. În ultimii ani, au fost realizate progrese semnificativeîn adaptarea cadrului legal la realitatea comerţului electronic şi în dezvoltarea autoreglăriiacestuia prin convenirea codurilor de conduită, în cadrul dezbaterilor şi politicilor mai multor organisme internaţionale. Cu toate acestea, legile şi cadrul de conduită adesea vizează osingură ţară şi nu au o aplicabilitate globală în mai multe ţări.

De exemplu, contractele electronice încheiate între un vânzător şi un cumpărător dinţări diferite, prin intermediul unui Web site, trebuie să se supună legislaţiei uneia dintr ţări. În

cadrul UE această situaţie a fost rezolvată în 2002, prin adoptarea ‖ principiului ţării deorigine‖. Acest principiu precizează că un contract se supune legilor ţării de origine avânzătorului şi se aplică şi în cazul e-mail. [Chaffey2004]

Bariere specifice micilor întreprinderi. Micile întreprinderi întâmpină o serie de dificultăţiîn a participa sau crea pieţe electronice globale. În primul rând, acestea se referă la volumulrelativ scăzut al resurselor de capital şi personal, lipsa de vizibilitate a mărcilor de fabricaţie.În cazul IMM-urilor, problema cheie în crearea unor pieţe electronice este alegerea unor strategii specifice de genul parteneriatelor strategice, aranjamentelor privind împărţireasegmentelor de piaţă ca, de exemplu, franchising şi scheme asociate acesteia (zonecomerciale). Concentrarea asupra unor nişe de piaţă şi cooperarea cu alte firme mici (crearea

în comun a unor website-uri pentru promovarea exporturilor, aşa cum fac micii exportatori demobilă în Spania). Ca participanţi individuali la pieţele electronice, întreprinderile mici potîntâmpina mari dificultăţi deoarece, în faza iniţială a unor astfel de pieţe electronice, vor creşte

mai degrabă transparenţa preţurilor decât transparenţa caracteristicilor produselor în general(calitate, termen de livrare, nivelul serviciilor şi cunoştinţele referitoare la afaceri). Strategii de marketing insuficient adecvate. Societăţile care vor să participe la comerţul

electronic global trebuie să-şi exploateze activele de care dispun în mod global. Ele trebuie sădepăşească obstacolele din mediile lor de afaceri şi să-şi soluţioneze principalele slăbiciuniinterne. Strategiile de marketing sunt, de regulă, următoarele: - orientarea către o piaţă globală a produsului; - participarea la un lanţ global de livrare; - ofertarea unui suport lingvistic multiplu;- crearea unei zone reţea de franchising; - complementaritatea prezenţei fizice globale cu prezenţa pe Internet; - construirea unei prezenţe globale, prin fuziuni şi achiziţii.



93

3.3. Tipologia pieţelor electronice globale

Literatura de specialitate clasifică pieţele electronice globale în patru grupe: pieţe electronice intrinsec globale care se ocupă cu produse globale, consumatori, furnizori

(exemplu: întreţinere, reparaţii, automobile).

pieţe locale global organizate (de exemplu, licitaţiile de bunuri perisabile); pieţe locale cu infrastructură globală ; asociaţii de export în care produsele sunt exportate global prin colaborarea producătorilor.

Pieţe electronice intrinsec globale sunt acele pieţe care se ocupă cu produse de naturăglobală şi cu consumatori şi furnizori care sunt caracterizaţi printr -o prezenţă globală. Multe dintreschimburile B 2 B aparţin acestei categorii de pieţe. Acestea sunt necesare pentru afaceri în lumea

î ntreagă şi adesea există mulţi furnizori pe plan mondial pentru astfel de produse. Pieţele care oferă oviziune uniformă asupra produselor oferite (Trade zone, Barclays, B2B) sunt intrinsec globale.

Pieţele locale global organizate sunt în mod necesar limitate din punct de vedere geografic.Cu toate acestea, modul de abordare şi desfăşurare a tranzacţiilor într -o regiune poate fi utilizat şi înalte regiuni, în felul acesta realizându-se o legătură între pieţele respective..

Pieţele locale construite pe o infrastructură globală reprezintă un alt tip de piaţă electronicăfuncţională în plan local şi global. Când se vorbeşte despre pieţele electronice globale nu toate trebuiesă fie într -adevăr globale. Funcţia reală de reprezentare şi comercializare a acestor tipuri de pieţe poatefi în întregime locală, în timp ce funcţiile de acces, plata, securitatea şi livrarea produselor ar putea figlobale.

Asociaţiile de export reprezintă un alt tip de piaţă electronică de dimensiune globală care, cutoate acestea, este caracterizat şi printr -un puternic element local. Conceptul constă în existenţa unuinumăr de furnizori (ofertanţi), din aceeaşi regiune geografică, care caută o prezenţă globală, dar care nusunt capabili să acţioneze global în mod individual. Aceştia creează o entitate comună de export, carese ocupă, în numele lor, de complexitatea comerţului internaţional cum ar fi cataloage în mai multelimbi, reglementări de export/import, finanţări în mai multe valute, expediţii internaţionale etc.

Dar valoarea realã a e-business-ului apare în momentul în care companiile acceptă ideeacomunicãrii în douã sensuri, când ei integreazã propriile pagini Web, sistemele intranet şi extranet însistemul existent de afaceri, creând noi oportunităţi pentru clienţi, salariaţi, furnizori şi distribuitori

pentru a interacţiona cu ei în orice moment şi oriunde. Mai mult ca atât, lucrând cu intermediari,compania este capabilã sã furnizeze direct informaţii de care au nevoie şi realizeazã afaceri. Ca urmaresalariaţii, clienţii, distribuitorii şi furnizorii câştigã mai mult accesând datele mai repede şiinteracţionând direct cu nucleul sistemului de afaceri, iar companiile descoperã posibilităţi noi defolosire a resurselor. De fapt, informaţiile obţinute de firme, prin interacţiunile directe cu salariaţii,clienţii, distribuitorii şi furnizorii devin resurse pentru acestea. Firmele pot folosi aceste cunoştinţe şiexperienţe pentru a fundamenta calea spre care trebuie condusã afacerea. Acesta este adevãrata forţã ae-business-ului.

Un e- business prosper are şi o altã caracteristicã. Firmele sunt interesate sã vadã schimbareaca o oportunitate şi nu ca o provocare. Acest lucru este important pentru cã e-business-ul apare într-unmediu schimbãtor, tehnologia evolueazã rapid şi regulile competiţiei se schimbã. Dacã o firmã estemare, e-business poate ajuta ca sã se comporte ca o companie micã, mult mai agil, fãcând companiamult mai responsabilă şi oferând posibilitatea unei comunicaţii mult mai directe cu clienţii, în schimbdacă este o companie micã, e-business poate s-o ajute ca sã pară una mare, oferind o vizibilitate mare şiacces la clienţi din întreaga lumea.Deci, indiferent de mãrimea firmei, peste tot clienţii actuali şimilioanele de noi clienţi potenţiali pot sã aibã acces la afacere oricând şi oriunde. E-business oferã ooportunitate pentru a obţine un avantaj maxim, dar aceastã oportunitate trebuie sã fie planificatã.

Importanţa fundamentală a e-business-ului — reducerea costurilor, creşterea veniturilor,

satisfacerea clienţilor —se dovedeşte a fi doar vârful unui aisberg. După ce şi-au dat seama debeneficiile Web-ului se încearcă sporirea aestor beneficii prin intergrarea aplicaţiilor şi tehnologiilor

noi şi existente e- business. Aceste procedee ajută la satisfacerea clienţilor şi îmbunătăţesc eficienţa.



94

Cheia către succes, este găsirea unor mijloace, de a oferi clienţilor ceea ce -şi doresc, fără cheltuielileoperaţiilor unei afaceri tradiţionale.

Comerţul electronic reprezintă un mijloc de a susţine şi realiza aceste schimbări pe scară largăşi chiar la scară globală. El oferă firmelor posibilitatea de a fi mai eficiente şi mai flexibile înoperaţiunile interne, de a menţine legături mai strânse cu furnizorii şi de a răspunde prompt cerinţelor şi

doleanţelor consumatorilor. Firmele îşi pot selecta cei mai adecvaţi parteneri de afaceri fără a mai ţinecont de distanţele geografice şi îşi pot comercializa produsele pe o piaţă globală.

3.4. Categorii de tranzacţii electronice

Comerţul electronic este o tehnologie utilizată în scopul schimbării globale. Firmele care îl privesc doar ca pe o modalitate suplimentară de derulare a afacerilor, vor avea beneficii limitate. Celemai importante avantaje le vor obţine acele companii care sunt dispuse să -şi modifice organizarea şimodul de funcţionare, pentru a se adapta cerinţelor operaţionale ale comerţului electronic.

Comerţul electronic poate fi divizat în mai multe categorii, în funcţie de agenţii participanţi: tranzacţii între firme (business to business - B2B);

tranzacţii între firme şi consumatori (business to consumer - B2C); tranzacţii între firme şi organizaţii guvernamentale (Business to Governement -B2G);

Business-to- Administration (B2A) care se referă la relaţiile dintre o firmă şi instituţiile de

administraţie publicã; tranzacţii între consumatori şi organismele guvernamentale (Consumer to Governement -

C2G);

tranzacţiilor între două persoane private (Consumer to Consumer C2C). Business to Employee (B2E), se referă la tranzacţiile din cadrul unei firme, f olosind propriul

sistem de intranet.

Firme (B) Consumatori (C) Guvern (G) Angajaţi (E)

Firme (B)B2B

Comerţ electronic

B2C

comerţ electronic

B2G

Administraţie,

logistică

B2E

Colaborare,

coordonare

Consumatori (C)C2B

comparaţie preţuri

C2C

Licitaţii online

C2G

achitare taxe

online

Guvern (G)G2B

informare

G2C

informare

G2G

coordonare

Principalele categorii de tranzacţii electronice

41

În prezent, cele mai răspândite tipuri de comerţ electronic sunt Business -to-Business (B2B) şiBusiness-to-Consumer (B2C).

1. Tranzacţiile B2B se caracterizează prin faptul că ambele părţi participante la tranzacţiacomercială, atât vânzătorul cât şi cumpărătorul, sunt instituţii (ex rtcoffice.ro). Acoperã toatetranzacţiile efectuate între doi sau mai mulţi parteneri de afaceri. Aceste tranzacţii sunt bazate de obicei

pe sistemele extranet, adică partenerii de afaceri interacţionează prin Internet cu numele de login şiparolele de pe website-urile lor. Din punctul de vedere al unui client B2B managementul informaţieidestinate cumpărătorului ar trebui să se regăsească în site-ul cumpărătorului, în vederea integrării cucelelalte informaţii. De asemenea, informaţia destinată cumpărătorului trebuie stocată în serverul

acestuia, pentru a fi posibile plăţile electronice, fluxul de lucru, răspunsul prin Intranet. Un exemplu41 Sursa: www.moldovainomc.org/modules/mydownloads/pdf/2003-02.pdf



95

pentru această categorie îl reprezintă o firmă care utilizează reţeaua de Internet pentru a plasa comenzila furnizori, pentru a recepţiona facturi şi pentru a efectua plăţi. Acest tip de comerţ este implementatde cãţiva ani, folosind în special tehnologia EDI (Electronic Data Interchange) în cadrul unor reţele

private şi securizate. Schimbul Electronic de Date (EDI - Electronic Data Interchange) a apărut prinanii 1960 şi poate fi considerat strămoşul Comerţului Electronic (EC - Electronic Commerce). EDIoferă societăţilor comerciale posibilitatea să schimbe documente de afaceri într -o formă standard,

utilizând mijloace electronice pentru prelucrarea şi transmiterea acestora. În acelaşi timp băncileutilizează reţele dedicate pentru Transferul Electronic de Fonduri (EFT- Electronic Funds Transfer).

Reţelele ce folosesc tehnologia EDI au fost extinse în Internet. Una dintre acestea este TradingProcess Network, care are 40.000 clienti în lume şi permite cumpărătorilor să stabilească un canal sigur către principalii furnizori, să ceară cotaţii potenţialilor noi furnizori din lume. Reţeaua este folosită azide Hewlett Packard, Textron Automotive, Chrysler, suplimentar peste 1.400 î ntreprinderi mici şimijlocii din lume participă la tranzactii. Recent, odată cu creşterea accesibilităţii la Internet, EC a căptatinteresul consumatorilor individuali şi al societăţilor comerciale de orice mărime şi preocupări. Maimult decât atât, cu tehnologiile avansate disponibile acum, se vorbeşte tot mai des de EconomiaDigitală (DE- Digital Economy).

2. Tranzacţiile B2C se realizează între cumpărători individuali şi vânzători-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 cumpărare. Se referă la relaţiile dintrecomerciant şi consumatorii privaţi, activitate care este consideratã comerţ electronic cu amănuntul.Acest tip de afaceri se bazează de obicei pe tehnologii Internet. Tranzacţiile dintre firme şiconsumatori se referă la vânzarile electronice en-detail. Această categorie s-a dezvoltat foarte multodată cu apariţia şi extinderea World ide Web iar în prezent există o multitudine de magazine virtuale

pe Internet, care oferă o gamă foarte largă de produse, începând de la prăjituri şi jucării şi terminând cucalculatoare şi autoturisme.

3. Tranzacţii B2G Include toate tranzacţiile dintre firme şi organismele guvernamentale şiadministrative.(de exemplu e-licitatie.ro) Guvernele, la nivel naţional, regional şi chiar municipalutilizează canale de comerţ electronic pentru creşterea eficienţei operaţiunilor, îmbunătăţirea niveluluiserviciilor oferite clienţilor. O arie de interes pentru guverne în domeniul afacerilor este utilizarea pe

scară mai largă a Interentului şi a reţelelor VAN, pentru diseminarea informaţiei, a oportunităţilor,cotaţiilor primite de la vânzători/furnizori de bunuri şi servicii. Tradiţional, listele cu oportunităţi erautransmise furnizorilor sub forma unei scurte liste, în ziare, sau în publicaţiile guvernului. Între anii1980-1990 câteva guverne inovatoare, prin agenţiile lor au început să utilizeze folosind sistemul dial-upîn transmiterea "bulletin board services"(BBS), care asigură accesul online la cererile curente deinformaţii/oportunităţi/consultanţă. Acestă abordare a implicat din partea beneficiarului serviciilor BBS adaptarea la aceeaşi tehnologie software pentru a putea utiliza informaţia.

Departamentul de Apărare al Statelor Unite, pentru a avea o audienţă naţională şiinternaţională şi-au proiectat reţeaua VAN proprie, pentru a distribui informaţia la audienţă. Aceastăsoluţie a cerut de asemenea, furnizorilor să se aboneze la serviciile reţelelor de provideri şi să utilizezecapacităţile de comunicare cum ar fi soft-ul necesar transmisiilor EDI, dacă doreau să descarceinformaţiile în sistemele proprii. De exemplu, în SUA informaţiile cu privire la noile taxe

guvernamentale sunt publicate pe Internet, iar firmele pot reacţiona pe cale electronică. În anii '90această categorie se afla într -o stare incipientă, dar ea se dezvoltă rapid, având în vedere că uneleguverne acţionează în sensul promovării şi dezvoltării comerţului electronic. Pe lângă publicarea unor informaţii, organismele guvernamentale pot să ofere opţiunea plăţii electronice a TVA şi a altor taxe şiimpozite.

Un exemplu elocvent este site-ul www.elicitatie.ro care permite achiziţia de materialeconsumabile, echipamente şi alte categorii de mărfuri de către instituţiile bugetate, prin intermediullicitaţiei pe Internet. Totuşi, în condiţiile dezvoltării atât a tranzacţii dintre firme şi consumatori,cât şi a celor dintre firme şi administraţie, guvernele pot extinde interacţiunea electronică îndomeniul privind plata ajutoarelor sociale, returnarea taxelor etc.

4. Tranzacţii C2G, acoperă relaţii guvern-cetăţeni la nivel de informare şi prestare serviciipublice(ex plătirea taxelor online). Categoria tranzacţii dintre consumatori şi organismeleguvernamentale a fost implementată în ţara noastră la nivel local (primării). Totuşi, în condiţiile

http://www.emania.ro/



http://www.amazon.com/






96

dezvoltării atât a tranzacţii dintre firme şi consumatori, cât şi a celor dintre firme şi administraţie,guvernul a iniţiat şi va extinde interacţiunea electronică în domeniul taxelor achitate la administraţiilelocale, privind plata ajutoarelor sociale, returnarea taxelor etc.

5. Tranzacţii C2C, consumatorii care vin direct la alţi consumatori (okazii.ro, ebay.com) Înaceastă categorie se includ site-urile de licitaţii online, precum Ebay, QXL sau comunităţi virtuale..

4. Business to Employee (B2E) reprezintă tranzacţiile între o firmă şi angajaţii săi prinintermediul sistemului intranet.

Impactul comerţului electronic se face simţit atât la nivelul fiecărei firme, cât şi pe ansamblulsocietăţii. Pentru firmele care-i exploatează la maxim potenţialul, comerţul electronic oferă

posibilitatea unor schimbări fundamentale care modifică atât de radical aşteptările consumatorilor, încâtajung să redefinească piaţa sau să creeze noi pieţe. Toate celelalte firme, inclusiv cele care încearcă săignore noile tehnologii, vor fi influenţate de schimbările în aşteptările consumatorilor şi alecaracteristicilor pieţelor. În acelaşi timp, membrii societăţii vor beneficia de noi modalităţi deachiziţionare a bunurilor, de accesare a informaţiilor şi de interacţiune cu organismele guvernamentale.Posibilităţile de alegere vor fi mult mai mari, iar restricţiile de spaţiu şi timp vor fi eliminate. Impactulglobal asupra stilului de viaţă poate fi comparabil cu cel al creşterii numărului de autoturisme sau cucel al dezvoltării telefoniei mobile.

3.5. Modele de afaceri electronice

Piaţa virtuală cuprinde următoarele modele de afaceri electronice: Magazinul electronic (e-shop) reprezintă modelul sub care se desfăşoară în general comerţul

electronic de tip B2C. Un magazin electronic oferă firmelor posibilitatea de a-şi prezenta oferta prinintermediul mediilor virtuale. Avantajele acestui model de afacere este în principal acces ul la o piaţăextinsă, chiar internaţională, piaţă care în acest caz devine mai accesibilă fimelor mici şi mijlocii.

Un magazin electronic se implementează prin intermediul unui site Web, este administrat decompanie pentru activităţile de marketing şi cele de vânzare a propriilor produse şi servicii. Minimal, site-ulWeb conţine un catalog de produse sau servicii cu descrieri tehnice şi comerciale pentru fiecare poziţie 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 posibilităţilor de acces concurenţial şi securitateatranzacţiilor. Produsele care se comercializează cel mai bine prin intermediul magazinelor virtuale sunt, deregulă, cele care pot fi descrise cu uşurinţă şi nu necesită încercarea lor înainte de cumpărare. Spre deexemplu: bilete de avion sau de concert, CD-uri, cărţi, software, produse alimentare, etc. Din punctul nostrude 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 undesen/schiţă despre cum se aplicăo cremã, un ghid despre genul de fard recomandat dimineaţa, în timpulzilei şi respectiv seara. Preţurile produselor comercializate prin intermediul magazinelor virtuale sunt, îngeneral mai mici decât cele practicate în magazinele fizice.

Serviciile de informare sunt oferite gratuit la început, prin acces liber sau abonamente gratuite la publicaţii periodice. Ulterior, ofertanţii vor iniţia servicii suplimentare de tipul accesului la arhive şi vor

extinde posibilităţile de căutare, solicitând utilizatorului plata unui abonament pentru a beneficia de acestea.S-a constatat că impactul abonamentului on-line asupra utilizatorilor este foarte mic deoarece majoritatearămâne fidelă abonamentelor clasice, în general, numai clienţii noi apelează la acest nou sistem deabonament. 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 managementultuturor activităţilor de aprovizionare – primirea de oferte, comenzi, livrări şi plăţi – între o firmă şifurnizorii acesteia. În categoria aprovizionărilor electronice se includ şi licitaţiile organizate de marilefirme şi autorităţile publice pentru achiziţionarea de bunuri şi servicii. Prin publicarea pe Web aspecificaţiilor ofertei, scad atât timpul cât şi costul de transmisie, mărindu -se şi numărul de firme careiau parte la licitaţie. Astfel, creşte concurenţa şi scade preţul.

Magazin electronic universal (e-mall): reprezintă o transpunere în spaţiul virtual al marilor complexe comerciale, prin intermediul unui site Web care cuprinde oferta mai multor magazine. Aceste



97

magazine oferă spre vânzare produse diferite. Mall-ul optim se defineşte ca fiind un mall cu o reţea 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 căi e-shop-ul. Din punctul de vedere al clientului, un e-mall faciliteazăaccesul la o mulţime de magazine, cataloage de firmă, vânzători specializaţi, la produse ale unor firmede renume şi ajută clientul să găsească şi să aleagă exact produsul de care are nevoie. Există e-mall-uricare acoperă o gamă variată de produse, pot oferi produsele unui anumit producător sau pot a coperi o

zonă geografică. Un e-mall poate accepta metode de plată comune. Un magazin electronic de tip Mallreprezintă un depozit electronic conectat la o serie de baze de date ale furnizorilor săi, nu necesită spaţiu deconstrucţie, timp şi bani pentru efectuarea de inventarieri şi oferă posibilitatea de a face constant cele maimici oferte la cele mai avantajoase preţuri, oferă discount-uri între 10% şi 50%.

În concepţia generalã magazinul virtual e-mall are propriile baze de date precum şi baze de dateconectate la magazine en-detail, producători 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 vânzare-cumpărare se stabileşte modalitatea de livrare a produselor comandate. Practic une-mall oferă spaţiu pentru mai multe e-shop-uri şi poate fi realizat utilizând diverse modele de tranzacţii,în funcţie de tipul de servicii pe care doreşte să le ofere proprietarul e-mall-ului, de dezvoltarea strategiei demarketing a e-mall-ului. Un e-mall de succes se defineşte ca fiind o reuniune de magazine virtuale caredeţine o reţea puternică, o strategie de marketing foarte bine gândită, un front -end de prezentare adecvat şi

diverse modalităţi de accesare a e-shop-urilor componente. Conceptual e-mall este o afacere ce se integreazăîn modelul colaborativ de ineracţiune, comercial bazat pe acces al clienţilor la un catalog on-line.

Licitaţiile electronice (e-auctions) permit achiziţionarea prin intermediul unei licitaţii, a unor produse de care indivizii nu au nevoie în mod frecvent. O licitaţie electronică mai mulţi vânzători l a felca în cazul unui e-mall. Licitaţiile electronice pot fi de tip B2C (www.ebay.com) sau de tip B2B(www.qxl.com) Licitaţia electronică reprezintă automatizarea procesului de cumpărare sau de procurare deresurse folosind aplicaţii Web. Licitaţia electronică oferă posibilitatea diferiţilor cumpărători şi ofertanţi să seîntâlnească, să interacţioneze şi să execute tranzacţii direct pe Internet.

Licitarea produselor şi obiectelor pe Internet s-a dovedit a fi un model de mare succes, utilizat atât pentru comerţul electronic B2B cât şi pentru cel B2C şi, datorită faptului că este un domeniu de mare interes, poate fi, de asemenea integrat şi în e-shop-urile obişnuite. Produsele vândute prin licitaţie electronică pot fi bunuri de ultimă oră, de suprastoc sau cu stoc fluctuant sau obiecte de valoare pentru colecţionari

specializaţi. Prin intermediul licitaţiilor electronice se pot comercializa o gamă variată de produse, de la bunuri materiale, metale, materii prime până la obiecte de artă, de mare valoare.

Operatorul licitaţiei gestioeazã mecanismele de plasare a obiectului licitaţiei, (de obicei prin e-mail)şi poate oferi în plus servicii de plăţi şi de livrare. Într-un sistem de e-licitaţie fiecare pas se realizeazăelectronic,de la crearea şi trimiterea cererilor de ofertă până la recepţionarea şi plata bunurilor, dateletranzacţionate sunt procesate electronic, reducând astfel timpul şi costul operaţiilor de procurare, ceea cedetermină o creştere a eficienţei organizaţiilor. Aplicaţiile de tip licitaţie electronică au la bază cataloage de

produse ale diverşilor ofertanţi care sunt unificate într -o singură sursă de oferte, atât pentru bunuri cât şi pentru servicii. Inglobate în procesele de afaceri şi în sistemele informatice Intranet, atât ale vânzătorilor câtşi ale cumpărătorilor, aplicaţiile e-Procurement micşorează costurile de procesare, gestiunea cataloagelor şiîmbunătaţesc accesul clienţilor la oferte. E- procurement leagă vânzătorii şi cumparătorii într -o piaţă virtualădinamică care se bazează pe principiile economiei concurenţiale.

Comunităţi virtuale (virtual communities): oferă indivizilor posibilitatea de a se întâlni şidiscuta subiecte de interes pentru ei. Comunităţile virtuale sunt grupuri de discuţii interactive sau liste decorespondenţi pentru dezbaterea subiectelor din diferite domenii de interes ale participanţilor. Discuţiile potfi pe diferite teme, de la cele de divertisment până la cele ce vizează un anumit domeniu de activitate. Astfelde discuţii au loc prin intermediul forumurilor (forums), grupurilor (chat) sau listelor (mailing lists) dediscuţii. Acest sistem permite firmelor să participe la comunităţi permanente sau temporare (asociaţii,consorţii, echipe de lucru la un proiect. Comunităţile virtuale de afaceri reprezintă un astfel de exempluşi se pot împărţi în comunităţi B2B sau B2C.

Pe Internet se întrunesc oamenii care au interese comune în comunităţi, pentru a discuta sau aasculta tematicile preferate42 Calitatea de membru al unei comunităţi virtuale presupune de obicei plata

unei taxe. Instrumentele necesare comunităţilor virtuale sunt oferite uzual ca servicii gratuite, în scopul

42 http://www.euro-info.ccir.ro/com-el.htm

http://www.ebay.com/



http://www.qxl.com/

http://www.qxl.com/

http://www.qxl.com/

http://www.qxl.com/




98

creşterii traficului pe site-ul Internet şi dar pentru stimularea fidelitãţii şi ataşamentului emoţional faţă deaceasta. Comunicările de afaceri în schimb pot fi realizate prin intermediul unui serviciu contra cost.

Canalul de comunicare directă sau video-conferinţele sunt instrumente atractive care reduccosturile de călătorie şi sunt utilizate de firmele mari, atât pentru comunicări ştiinţifice cât şi pentru celecomerciale1.În funcţie de statutul organizatorului conferinţei, firmă, prestator de servicii sau asociaţie

subiectele de discuţii pe care le propune acesta pot fi taxate sub for ma unei taxe de participare sau specificeevenimentului sau nu se percep taxe deloc.

Platformele de colaborare oferă firmelor şi indivizilor, experţilor posibilitatea colaborării într-un anumit domeniu. Scopul unei astfel de platforme este unul precis şi implică în general sarcini decercetare dezvoltare (proiectarea produselor, realizarea unor planuri, etc.). Platformele pot fi

proprietatea unei firme sau organizaţii sau neutre, caz în care confidenţialitatea se oferă prinmecanisme precum semnătura digitală. Câştigurile provin din managementul platformei (taxa demembru sau taxa de utilizare), şi din vânzări de instrumente specializate (pentru proiectare, workflow şigestiunea 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 experţi, acţionând ca o intreprindere virtualăfaţă de lumea exterioară. În cazul în care platforma nu aparţine unei anume întreprinderi, operatorul tr ebuie

să acorde o atenţie specială statutului de neutralitate, protecţiei datelor şi siguranţei comunicării, pentru a nu permite scurgeri de informaţii de interes pentru concurenţă. Viteza de transmisie are o importanţă majoră,mai ales în domeniul tehnic iar semnătura digitală devine un instrument indispensabil pentru derulareaactivităţii în general sau pentru domeniul contractual, în special1.

Piata unui terţ (Third-party marketplace) oferă vânzătorilor o interfaţă Web pentrucatalogul de produse al companiei, se ocupă de promovarea acestora, preluarea comenzilor, logistică,efectuarea plăţilor şi asigurarea securităţii tranzacţiilor. Site-ul Amazon.com este un exemplu în acestsens.

Furnizor de servicii cu valoare adaugată (Value chain service provider) oferă diferitefuncţii specifice din cadrul lanţului de aprovizionare al unei firme. Astfel de funcţii sunt logistica, plataelectronică, etc. Plata acestor servicii se face pe baza unor tarife sau a unei cote procentuale.

Brokeraj de informaţii (information brokerage) oferă consumatorilor şi vânzătorilor informaţii – cataloage de clienţi clasificaţi pe profil, vânzarea de oportunităţi de afaceri, consultanţă îndomenii specializate – asistându-i în decizia de cumpărare. Serviciile Internet diversificate adaugăvaloare volumului de informaţii existent prin:

furnizarea unor cataloage de clienţi, clasificaţi pe profile; vânzarea unei oportunităţi de afaceri; sfaturi pentru investiţii; consultanţă în diferite domenii specializate; servicii de încredere furnizate de autorităţile de certificare sau de notariatele electronice; înfiinţarea unor unităţi şi agenţii de cercetare care încearcă să creeze mecanisme de detectare

semantică (semantici WEB, agenţi inteligenţi, ontologii,etc); serviciile de informare, care se bazează pe experienţa umană, respectiv experţi în domeniu, rămân

în continuare servicii de importanţă vitală pentru lumea afacerilor (knowledge management).

Aceste servicii comerciale sunt desfăşurate contra cost în mare parte, fie în baza unui sistem deabonament, fie prin intermediul banilor electronici de tipul e-cash sau cybercash. Au fost înfinţate unităţi şiagenţii de cercetare care încearcă să creeze mecanisme de detectare semantică, dar serviciile de informarecare au la bază experienţa umană, respectiv experţi în domeniu rămân în continuare servicii de importanţăcapitală pentru lumea afacerilor.

Servicii de securitate(trust services) sunt serviciile care certifică calitatea produselor sauserviciilor oferite de firmele care acţionează pe piaţa electronică. Un exempul de astfel de servicii suntoferite de TRUSTE (www.truste.org )

http://www.truste.org/






99

3.6. Caracteristici ale comerţului electronic

Comerţul electronic poate fi implementat la o multitudine de niveluri, începând de la o simplă

prezenţă pe reţea şi terminând cu suportul pentru afaceri distribuite la mai multe firme, putându-seobserva diferenţe între tranzacţiile naţionale şi cele internaţionale, ale căror cauze nu sunt de naturătehnică ci, mai de grabă, de natură legislativă. Comerţul electronic este mai complex la nivelinternaţional datorită unor factori diverşi: sistemul de impozitare, legea comercială, taxe vamale,diferenţele dintre practicile bancare, etc.La nivelurile mai simple firma se preocupă de prezenţa pe reţeade promovarea imaginii firmei şi de asistenţa pre şi postvânzare, folosind tehnologii deja existente şitestate, care sunt uşor de implementat şi implică costuri minime dar acesta nu reprezintă un real comerţelectronic. Comertul electronic, în concepţia Organizaţiei Economice de Cooperare şi Dezvoltare(OECD), reprezintă desfaşurarea unei afaceri prin intermediul reţelei Internet, vânzarea de bunuri şiservicii având loc offline sau online. În tranzacţiile comerciale clasice distingem patru etape diferite:

informarea comercială referitoare la tranzacţie: cercetarea de marketing; încheierea contractului comercial; vânzarea produsului sau a serviciului; plata produsului sau a serviciului.

Multe organizaţii care au implementat sisteme de comerţ electronic au ajuns la concluzia căcele mai mari probleme apar nu la pregătirea ordinelor de cumpărare şi livrare, ci la selectarea şiidentificarea partenerilor de afaceri. Pentru aceasta este necesară accesarea unor baze de date cu

produse şi servicii care pot fi achiziţionate, 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‖. Diferiţi utilizatori pot folosi criterii diverse pentru căutările lor în acestenomenclatoare, funcţie de numele producătorilor, sau numele exact al produsului dar majoritatea deţindoar o descriere generică a produsului sau a unui standard internaţional pe care bunul solicitat trebuiesă-l respecte. Multe firme descoperă că nomenclatoarele, datorită bunei structurări şi funcţionalităţi,asigură avantaje concurenţale importante.

O utilizare specială a nomenclatoarelor o constituie înregistrarea contractelor pe care oorganizaţie de mari dimensiuni le încheie cu furnizorii săi, caz în care toţi achizitorii din cadrulorganizaţiei pot cumpăra în baza acestor contracte, utilizând clauze şi condiţii predefinite.

Există o mare varietate de moduri în care cumpărătorii şi vânzătorii se pot întâlni şi în care se poate derula negocierea preţurilor, calităţii, condiţiilor de livrare şi de transport. Unul dintre principaliifactori care determină forma de încheiere a contractelor o reprezintă categoria de bunuri şi servicii carefac obiectul tranzacţiei: produse, mărfuri fungibile, bunuri şi servicii proiectate la comandă, produse şiservicii adaptate etc.

Comertul electronic reprezintã o posibilitate de expandare a oportunitãţilor de afaceri,îmbogãţirea de noi pieţe, mergând dincolo de graniţele şli limitele fizice a pieţei, pentru a ajutaafacerile, de a realiza noi valori tangibile şi cuantificabile în afacere. E -commerce-ul furnizeazã unacces interactiv şi comod în întreaga lume, cu informaţii de profunzime, incluzând disponibilitatea

produselor, de a ajuta clienţii să facă şi mai rapid deciziile de cumpãrare. Aceasta, pânã la urmã, ajutãla accelerarea ciclului vânzãrilor. E-commerce poate ajuta afacerile sã-şi reducã costurile prinîmbunãtãţirea eficienţei procesãrii comenzilor, reducerea costurilor inventarilor şi depozitelor şireducând costul actual al unei vânzări E -commerce este mai mult decât deschiderea unei canal devânzare online. Ea înseamnă utilizarea tehnologiilor pentru fuzelarea modelului de afaceri, obţinereaeconomiilor, şi creşterea eficienţei, ea înseamnă reducerea costurilor şi stabilirea unor relaţii maistrânse şi sensibile cu clienţii, furnizorii şi partener ii.

B2C, adică Business-to-Consumer este aplicată în orice afacere sau organizaţie care îşi vinde produsele şi serviciile consumatorilor prin Internet, pentru utilizare proprie, pentru consum. În adiţie lavânzarea în detaliu online, B2C include servicii bancare, de transport, de licitaţie, de sănătate. Businessto Business înseamnă cumpărarea şi vânzarea online între companii, incluzând 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 căi specifice care includ:guvernarea mai eficientă a inventarului, reglarea mai rapidă la cererile clienţilor, oferirea mai rapidă a



100

produselor pe piaţă, reducerea sau eliminarea cheltuielilor presupuse de lucrul cu documente manuale(hârtia), obţinerea preţurilor mai scăzute a stocurilor.

3.7. Componentele comerţului electronic

În cazul comerţului electronic, se întâlnesc aceleaşi componente ca şi în cazul comerţuluiclasic, dar care au caracteristici specifice şi anume: produsul - material sau digital; locul de vânzare - un website pe Internet, care prezintă produsele sau serviciile oferite; modalitatea de a atrage potenţialii clienţi să viziteze un anumit site; modalitatea de a primi comenzile, reprezentată de un formular on-line, cu legătură directă

la baza de date a firmei; modalitatea de a încasa contravaloarea serviciilor sau produselor în care se poate folosi şi

metoda clasică a facturării, on-line sau prin poştă sau varianta modernă printr -un cont bancar, cu plăţi prin card de credit, sau alte modalităţi electronice de plată. Acesteasolicită o soluţie sigură pentru preluarea şi gestionarea comenzilor şi conexiunea la o

bancã prin sisteme de securitate ale tranzacţiilor. modalitatea de livrare clasică sau direct prin reţeaua Internet dacă marfa este intangibilă

(software, muzică, informaţie, etc); modalitatea de a accepta retururi de mărfuri gestionate de formulare on-line legate la

aplicaţia server; modalitatea de acceptare a eventualelor reclamaţii obţinute tot prin formulare on-line; modalitatea de service prin email, formulare on-line, baze de cunoştinţe on-line etc..

Există o singură diferenţă majoră între B2B şi B2C -clienţii. In B2B clienţii sunt altecompanii, iar în B2C clienţii sunt persoane fizice. Aceasta determină alte implicaţii deoar ece în generaltranzacţiile B2B sunt mai complexe şi necesită un nivel mai înalt de securitate. Pe lângă acest aspect, în

proiectarea şi realizarea aplicaţiilor de e-commerce apar două elemente esenţiale:negocierea şisintetizarea. Vânzarea către o altă firmă implică o serie de negocieri asupra preţurilor, condiţiilor delivrare şi specificare a produselor. În cazul aplicaţiilor B2C negocierea nu are loc, ceea ce facilitează

crearea cataloagelor de produse. În cazul vânzărilor în detaliu nu este necesară in tegrarea cu sistemulclienţilor dar sintetizarea şi integrarea sunt cerinţe esenţiale în B2B.

Caracteristicile aplicaţiei fiecărui partener care participă la comerţul electronic şi fluxulinformaţional dintre aceştia sunt elementele de bază necesare pentru realizarea unei aplicaţii de comerţelectronic. Implementarea unei aplicaţii pentru comerţul electronic prin Internet, trebuie să ţină cont demodalităţile de plată existente, cunoscut fiind faptul că majoritatea acestor tranzacţii se fac prinintermediul cărţilor de credit, pentru realizarea operaţiilor de vânzare-cumpărare. După publicaţiaeMarketer produsele care se vând cel mai bine prin e-comerţ sunt: tehnicã de calcul (hardware,software, accesorii); cărţi; muzică; divertisment; servicii financiare; electronică de uz casnic; cadouri şiflori; servicii turistice; jucării; bilete pentru spectacole şi călătorie;informaţii.

E-commerce include:

Prezentarea electronică a produselor şi serviciilor; Preluarea on-line a comenzilor şi a notelor de plată; Informaţii despre contul clientului obţinute în mod automat; Plata on-line;

Furnizarea automată de soluţii de management. Companiile care realizează afaceri cu altecompanii (B2B), trebuie să fie siguri că pot comunica între ei fără intervenţie umană. La realizareaaplicaţiei se au în verdere cei trei parteneri: vânzătorul, cumpărătorul şi intermediarul (aquirer gateway), care se ocupă cu asigurarea securităţii informaţiilor cărţii de credit pe Internet.

3.8. Arhitectura de bază

In prezent există numeroasele modele de derulare a afacerilor pe Internet pot fi clasificate înfuncţie de numărul de furnizori, prestatori de servicii către clienţi, astfel:



101

e-shop (1-către-1); e-mall (mai mulţi-către-1); e-licitaţie (mai mulţi-către-mai mulţi).

Apare astfel, un lanţ de servicii în cadrul căruia fiecare participant poate fi dominant,respectiv:

1. furnizorul de produse sau servicii;

2. furnizorul de servicii Internet, care poate pune la dispoziţie de la spaţiu pe pagina web până laposibilitatea integrarii într-un e-mall;

3. clientul, cu o anumită formare profesională, interese proprii şi preferinţe. Acest client poate fiun consumator (B2C), o altă firmă (B2B), administraţia publică (B2G) sau un angajat (B2E),analizând contextul tranzacţiilor interne din cadrul unei firme. Cele mai răspândite modele deafaceri pe Internet vor fi tratate în detaliu.Majoritatea site-urilor de comerţ electronic de tip B2C utilizează modelul magazinului virtual,

astfel încât se impune o cercetare amănunţită a acestuia. Magazinul virtual reprezintă o transpunere înspaţiul virtual al unui magazin care oferă clienţilor săi diferite produse. În funcţie de procentul dinafacerea fizică transpus în spaţiul 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 lângă catalogul de produse şi posibilitatea comenzii online prin

utilizarea unui coş de cumpărături. Magazine care oferă catalog de produse, coş de cumpărături şi posibilitatea plăţii online cu

ajutorul cărţii de credit sau al portofelului digital.

Tehnologia coş de cumpărături Una dintre cele mai des folosite tehnologii de implementaree-commerce este coşul de cumpărături. Această tehnologie de procesare-comandă permite clienţilor săacumuleze produsele sau servicii pe care vor să le achiziţioneze pe măsură ce continuă să cumpere.Tehnologia coşului de cumpărături este un catalog de servicii care oferă posibilitatea alegerii unui

produs şi introducerea lui în cadrul unui formular de comandă. Clientul are posibilitatea modificăriiacestei comenzi pe parcursul întregii sesiuni de cumpărăturii, adică să adauge produse în coş, sămodifice cantitatea comandată, să elimine un produs din coş în orice moment. Coşul de cumpăraturi

poate fi vizualizat pe întreg parcursul procesului de cumpărare. Comanda este apoi validată, clientul îşiintroduce datele de contact :adresă, cod poştal, telefon, fax, email, iar în cazul în care este posibilărealizarea plăţii online, se introduc datele referitoare la cartea de credit. Procesul de achiziţionare aproduselor online prin intermediul unui magazin virtual pot fi sintetizate prin figura de mai jos, în careoperaţiile realizate sunt împărţite în activităţi anterioare comenzii şi activităţi realizate după procesareacomenzii.

Pentru a construi un sistem de comerţ electronic, din punct de vedere arhitectural este nevoiede colaborarea a patru componente (subsisteme electronice/informatice) corespunzătoare următoarelor roluri:

Client. Un echipament, clasic un PC, conectat direct (via un ISP) sau indirect (o reţea a uneicorporaţii) la Internet. Cumpărătorul foloseşte acest echipament pentru a naviga şi a face cumpărături.

Comerciant. Sistem informatic (hard & soft), situat de regulă la sediul comerciantului, caregăzduieşte şi actualizează catalogul electronic de produse disponibile a fi comandate on-line peInternet.

Sistemul tranzacţional. Sistemul informatic (hard & soft) responsabil cu procesareacomenzilor, iniţierea plăţilor, evidenţa înregistrărilor şi a altor aspecte de business implicate în procesulde tranzacţionare.

Dispecer plăţi. (Payment Gateway). Sistem informatic responsabil cu rutarea instrucţiunilor de plată în interiorul reţelelor financiar -bancare, cu verificarea cărţilor de credit şi autorizarea plăţilor;acest sistem joacă rolul unei porţi care face legătura dintre reţeaua globală Internet şi subreţeauafinanciar- bancară. Indiferent de tipul de afacere abordat în cadrul aplicaţiilor de comerţ electron ic apartrei componente majore: aplicaţia cumpărător, aplicaţia vânzător şi aplicaţia intermediarului.

3.9. Managementul relaţiei cu clienţii

Legătura dintre clienţi şi departamentele unei companii nu este posibilă decât prin intermediulunui software specializat destinat managementului relaţiilor cu clienţii (Customer RelationshipManagement-CRM). Acesta urmăreşte toate aspectele relaţiei pe care o firmă le poate avea cu clienţii



102

săi: interacţiunea cu aceştia, produsele cumpărate, problemele care pot apă rea la un moment dat. Lanivelul Internetului, CRM-ul transformat în e-CRM foloseşte tehnologia Web pentru a comunica îninterior, între departamente şi clienţi. Cele mai complexe sisteme de e-CRM sunt cele produse de cătrefirma GoldMine Software Corporation, Commence Corp, şi MultiActiv Software. Aplicaţiile de acestgen trebuie să conlucreze cu servere bazate pe SQL în cazul operaţiilor de amploare. Liderul îndomeniul sistemelor de e-CRM este Siebel System, al cărui software este utilizat de către IBM.

Sistemele oferite de către Siebel permit personalizarea, răspunsul automat la e -mail-uri, un portal Webşi realizarea de planuri de e-marketing. Un alt lider al pieţei este Oracle, care utilizează e-CRM pornindde la nucleul sistem ERP (Enterprise Resource Planning - gestiunea intreprinderii). Astfel, in acestesisteme, CRM asigură interacţiunea cu clienţii, iar ERP infrastructura de gestiune a firmei.

Oferta de e-CRM este extrem de variată, existând soluţii şi pentru firmele mici şi mijlocii.Produsele e-CRM majore sunt adevărate medii de dezvoltare, cu instrumente specializate destinate

personalizării sistemelor.Cheia succesului în e-business o reprezintă posibilitatea Web site-ului de a interacţiona cu

clienţii şi de a le acorda acestora oferte şi informaţii personalizate. Direcţiile de dezvoltare ale e-CRM-ului sunt estimate de firma IBM prin:

utilizarea Internetului pentru a comunica direct cu clienţii; posibilitatea cunoaşterii preferinţelor clienţilor şi găsirea unor soluţii individuale pe baza unor studii realizate direct online; anticiparea produselor/serviciilor căutate de client; o mai bună interdependenţă între departamentele şi diviziunile firmei.

Satisfacerea consumatorilor nu este suficientă, scopul CRM este obţinerea loialităţii clienţilor, prin personalizarea produselor/serviciilor la adresa clienţilor în funcţie de preferinţele, necesitãţile sau problemele fiecãruia. Procesul obţinerii loialitãţii consumatorilor este un proces concentrat peconsumator, cuprinzând trei paşi: achiziţia, dezvoltarea şi menţinerea clienţilor.

Pentru achiziţie, e-business oferã consumatorului un acces consistent la firmã în oricemoment, oriunde şi independent de platformã. Clienţii sunt dezvoltaţi în momentul în care companiafurnizeazã servicii personalizate. Informaţiile despre utilizatori pot fi manipulate pentru a oferi oselecţie personalizatã de produse şi servicii. Rãspunsurile date clienţilor trebuie sã fie cultivate şimenţinute tot timpul personalizate, pentru a susţine 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 clienţii sãi. Modul în care aceşti actori sunt legaţi este determinat de managementulliniei de aprovizionare iar companiile utilizeazã aceastã tehnologie pentru a ajuta comunicarea şicolaborarea cu partenerii de afaceri.

Managementul liniei de aprovizionare ajutã la obţinerea unor rãspunsuri la întrebãrile decheie în afaceri, de exemplu unde existã surse de materiale prime şi auxiliare sau subansamble,determinând cel mai eficient furnizor, de a înţelege logistica de transport, determinarea celei mai bunelocaţii pentru sedii sau centre de distribuţie şi iniţierea de cereri de prognostic şi planificare.

Soluţiile oferite de IBM pentru managementul liniei de aprovizionare ajutã la livrareaprodusului potrivit, la locul potrivit, în timpul potrivit şi la cel mai mic cost. Beneficiul înfiinţãrii uneilegãturi active cu furnizorii şi clienţii este semnificativ pentru: îmbunãtãţirea serviciilor oferite clienţilor cu livrãri rapide şi de încredere. reducerea pierderilor prin liniile de inventar, reduceri de preţ şi o utilizare mai bunã a resurselor. accelerarea creşterii afacerii care conduce la victorie pe piaţã, în pãstrarea clienţilor, creşterea

vitezei de cumpãrare şi servicii mai bune pentru clienţi. Soluţiile de management a linei de aprovizionare conduc la creşterea randamentului şi la

satisfacţia clienţilor. IBM şi partenerii selectaţi, furnizeazã un suport capãt la capãt, incluzând planificarea cererilor, aprovizionarea continuã, logistica de transport şi modelarea pe calculator avariabilelor liniei de aprovizionare. IBM este situat în centrul unuia dintre cele mai mari linii deaprovizionare din întreaga lume şi este capabil să transfere aceste experienţe pentru a ajuta clienţii.Principalele produse de modelare a aplicaţiilor e-business pentru managementul liniei de aprovizionaresunt Lotus Domino şi MQ Series. Aceste produse includ servicii e -commerce şi produse pentrusuportul de tranzacţii rapide şi fãrã probleme.



103

3.11. Modalităţi de plată - Contul de comerciant

Contul de comerciant este total diferit de conturile bancare obişnuite, utilizate în afaceriletradiţionale. El permite realizarea de plăţi prin cărţi de credit sau de debit ca formă de plată electronicăde la clienţi. Un cont de comerciant, implică existenţa unui numă r de identitate (Merchant ID) şi a

unui terminal la punctul de vânzare (point of sale terminal - POS). Un terminal de acest fel (POS) poate comunica prin intermediul liniilor telefonice, asemănător unui fax. Prin acest terminal se citesc şise înregistrează informaţiile despre consumator de pe banda magnetică a unei cărţi de credit sau dedebit. După procesarea acestor informaţii POS trimite informaţiile şi detaliile tranzacţiei cătreinstitutiile autorizate să proceseze plata (VISA, AMEX, MASTERCARD etc. sau la banca emitentă,dacă este vorba de o carte de debit). Acestea răspund cu informaţia dacă fondurile/creditul existent suntsuficiente efectuării plăţii şi autorizează sau declină tranzacţia. În situaţia în care comunicarea laterminalul POS nu este posibilă din diverse motive (ex. întrerupere temporară), tranzacţia poate fi totuşi

procesată manual la un număr de telefon gratuit (1-800).

Un cont de comerciant care poate procesa tranzacţii şi prin Internet se distinge prin aşa -numitul cont de comerciant de tip MOTO (mail order / telephone order). Un fapt puţin cunoscut şirespectat este acela că procedura legală în tranzacţiile prin Internet este să se expedieze produsul către

destinatar, înainte de încasarea sumei corespunzătoare de pe cartea de cred it/debit a clientului. În modevident, autorizarea încasării este obţinută însă înainte de expedierea produsului, pentru a aveaconfirmarea ca există fonduri disponibile şi a elimina riscurile în caz de furt. Transferul bancar are locnumai după ce produsul este în drum spre consumator.

Furnizorul contului de comerciant poate influenţa alegerea sistemului de shopping cart. Încazul tranzacţiilor în timp real care oferă şi palta online, este necesar ca formularul de plată să poata filegat la serviciile de autorizare oferite de furnizorul contului de comerciant. Dacă nu este posibil,cumpărătorul va fi pus fi în situaţia de a nu putea procesa tranzacţiile, nici măcar manual. De aceea,este absolut necesară verificarea sistemelor de shopping cart care acceptă furnizorul contului decomerciant. În aceste condiţii cunoaşterea acestor detalii pot influenţa semnificativ tipul de afacereelectronică pentru care o anumită firmă optează.

Sistemele electronice de plăţi Sistemele electronice de plăţi trebuie să atingă nivele ridicate de securitate, viteză, caracter privat şi

confidenţial, descentralizare şi internaţionalizare şi să fie unanim acceptate de comercianţi şi oameni deafaceri. O trăsătură comună a majorităţii acestor soluţii o constituie utilizarea tehnicilor criptografice careasigură confidenţialitatea, autenticitatea şi integritatea mesajelor transferate între entităţile implicate. Înaceste sisteme sunt implicate, în general trei părţi care interacţionează între ele, şi anume: o bancă, uncumpărător şi un vânzător. Un sistem electronic de plăţi43 este alcătuit din două nivele caresunt:[Roşca_2004]

1. nivelul utilizator care cuprinde mulţimea tuturor utilizatorilor şi a tranzacţiilor care au loc întreaceştia. Utilizatorii sunt împărţiţi în trei grupuri, în funcţie de modul în care aceştia interacţioneazăîntre ei în cadrul unei tranzacţii. Aceste grupuri sunt cumpărătorii, vânzătorii şi băncile.

2. nivelul sitem care cuprinde mulţimea entităţiilor fizice şi a relaţiilor care se stabilesc între ele.Entităţile pot îndeplini unul din următoarele roluri: purtător de bani electronici sau registru de casă.

43 www.softnet.ro/library/files/papers/Introducere_in_Comert_electronic.pdf:



104

Arhitectura unui sistem electronic de plăţi poate fi reprezentată grafic ca din figura 4.11. şi acestsistem electronic de plăţi poate folosi următoarele modalitãti de platã 44

cartela inteligentă (smartcard) care este un cip încorporat într-o cartelă de plastic. Spre deosebire de ocatelă de credit obijnuită, un smartcard dispune de un microprocesor. Comunicarea cu punctul deacces se face printr-un contact direct cu dispozitivul specializat în citirea cartelelor iar cumpărătorulnu are acces la instrumentele soft şi hard ale dispozitivului de citire a cartelei fapt ce conferă un plusde siguranţă băncilor.

portofelul electronic cu observator care este alcătuit din două calculatoare; unul aparţine clientului, prin care acesta comunică cu punctul de acces al sistemului de plăţi electronice, iar celălalt aparţine băncii, fiind încorporat în cel al clientului, şi care previne dubla cheltuire a banilor electronici.

punctul de vânzare (POS) care este folosit de către vânzător pentru a stoca temporal banii electronici. distribuitorul de bani electronici este un dispozitiv prin care se încarcă bani electronici în portofelul

electronic al cumpărătorului. 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 cumpărător; - distribuitor carte de credit-bani electronici care permite incrementarea valorii din portofel pe baza

creditării cumpărătorului de către o casă de credit; - distribuitor numerar-bani electronici permite incrementarea valorii din portofel prin colectarea de la

cumpărător a unei sume cash.

Mijloacele de plată folosite în comerţul electronic sunt:cecul on-line, ordinul de platã, plata laramburs, plata prin card de credit, plãti mobile (m-payment), etc

Cecul on-line care este un înscris cu ajutorul căruia o persoană dă ordin unei bănci să plătească osumă de bani beneficiarului. Cecul este una dintre cele mai nesigure modalităţi de plată, din cauza faptului călegislaţia din ţara noastră nu prevede o metodă simplă de recuperare a banilor în cazul în care cumpărătorulemite un cec fără acoperire. În ciuda acestui dezavantaj, există la ora actuală un număr destul de mare demagazine virtuale care acceptă şi folosesc acest mijloc de plată on-line.

Ordinul de plată care este emis de plătitor şi este adresat băncii deţinătoare a contului său. Prinintermediul ordinului de plată, plătitorul cere băncii la care are deschis un cont, să plătească o sumădeterminată unui anumit beneficiar. Ordinul de plată este cea mai utilizată metodă de plată în România, maiales în tranzacţiile între persoane juridice.

Plata ramburs care este un sistem de expediere a mărfurilor, conform căruia destinatarul esteobligat să achite la primire, expeditorului, contravaloarea mărfii. Principalele dezavantaje ale acestui sistemsunt date de valoarea limitată a tranzacţiilor, iar pentru comerciant lipsa unei garanţii că destinatarul va ridicaşi plăti marfa. Aceasta este cea mai răspândită metodă în comerţul electronic românesc, datorită răspândiriireduse a cărţilor de credit sau de debit.

Plata prin cardul de credit Sistemul de cărţi de credit a fost creat în scopul de a -i permitecumpărătorului să-şi satisfacă nevoia de cumpărare de bunuri şi servicii, chiar dacă nu dispune la un anumitmoment de banii necesari. Prin folosirea cărţii de credit, riscul este transferat de la vânzător la instituţiafinancară 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:

1.Deschiderecont, bani reali

5.Produse, servicii

7.Bani reali

2.Bani reali 6.Banielectronici

4.Banielectronici

3.Banielectronici

Emitent banireali

Emitent banielectronici

Cumpărător Vânzător

Arhitectura unui sistem de plăţi electronice



105

1. cumpărătorul prezintă vânzător ului cartea de credit; 2. vânzătorul trimite numărul cărţii de credit şi detaliile tranzacţiei la un sistem de autorizare; 3. sitemul de autorizare poate, fie să autorizeze direct tranzacţia fie, să o direcţioneze la banca emitentă a

cărţii de credit pentru aprobare; 4. la anumite intervale de timp vânzătorul trimite detaliile tranzacţiilor aprobate spre banca sa; 5. după ce tranzacţiile, pentru care banca respectivă este şi colectoare şi emiţătoare de cărţi de credit, au

fost procesate, aceste informaţii sunt transmise la asociaţia emiţătorilor de cărţi de credit6. la sfârşitul lunii, cumpărătorul primeşte facturile pe care trebuie să le achite, astfel va plăti dobândapentru creditul acordat de banca ce a emis cartea de credit.

Bibliografie modul: BUCHMANN ROBERT, C onceperea, proiectarea şi realizarea afacerilor pe Internet , Ed.

Risoprint, Cluj Napoca, 2004; RUSU L., ARBA R., BREŞFELEAN P., MUREŞAN L., BUCHMANN R., VEREŞ O –

Modele de afaceri pe Internet , Ed. Risoprint, Cluj-Napoca, 2007 ROŞCA, GH.I et al., Comerţ electronic-Concepte, tenologii şi aplicaţii, Editura Economică,

Bucureşti, 2004

Teste de verificare a cunoştinţelor Care sunt caracteristicile modelelor B2B, B2C, G2G, G2B, B2E, G2E? Care sunt caracteristicile modelelor e-recruitement, e-auction, e-marketing? Care sunt etapele derulării unei tranzacții electronice?



106

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 ROŞCA, GH.I et al., Comerţ electronic-Concepte, tenologii şi aplicaţii, Editura Economică,

Bucureşti, 2004 RUSU L., ARBA R., BREŞFELEAN P., MUREŞAN L., BUCHMANN R., VEREŞ O –

Modele de afaceri pe Internet , Ed. Risoprint, Cluj-Napoca, 2007

Bibliografie opţională

CHAFFEY DAN, E-Business and E-commerce Management , Second Edition, Ed.PrenticeHall, 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 aplicaţiilor 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 aplicații Web din paradigma Rich Client, bazat pe DHTML și comunicareaasincronă 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 bunaformare); se poate considera că este atât emiţător, cât şi consumator XML, fiind de obicei un programcu rol de intermediere. În unele situaţii, poate să nu fie intermediar, ci doar să indice utilizatoruluiuman dacă documentul este bine format sau nu45.

Aplatizare (Flattening) - Transformarea unui document XML prin reducerea numărului de

nivele al arborescenţei sale, de obicei prin crearea mai multor elemente şi atribute direct în rădăcină şi pierderea unor relaţii de subordonare între elemente. Metoda este utilă dacă unicul scop aldocumentului 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 spaţii. Valorile atributelor sunt delimitate cughilimele, care pot fi opţionale în unele limbaje de marcare.

Atribut de enumerare - Un atribut XML care este definit prin enumerarea valorilor saleposibile.

45 În unele traduceri din literatură termenii parser, validator şi analizor pot apare ca sinonimi,deoarece în multe cazuri cele trei funcţii sunt realizate de acelaşi program. Totuşi, din raţiuni de

performanţă, există numeroase cazuri în care sunt folosite programe diferite pentru a realiza conversiacodului sursă pe de o parte (parser) şi pentru a verifica buna formare şi validarea, pe de altă parte(analizor + validator).

http://www.librarie.net/autor/7273/Sabin-Buraga

http://www.librarie.net/autor/7729/Mihaela-Brut

http://www.librarie.net/carti/17596/Prezentari-multimedia-pe-Web-Limbajele-XHTML-TIME-si-SMIL-Sabin-Buraga


http://www.librarie.net/editura/Polirom

http://www.librarie.net/autor/1357/Teodoru-Gugoiu

http://www.librarie.net/carti/40653/HTML-XHTML-CSS-si-XML-prin-exemple-ghid-practic-Teodoru

http://www.librarie.net/editura/Teora

http://www.librarie.net/editura/Teora

http://www.librarie.net/carti/40653/HTML-XHTML-CSS-si-XML-prin-exemple-ghid-practic-Teodoru

http://www.librarie.net/autor/1357/Teodoru-Gugoiu

http://www.librarie.net/editura/Polirom



http://www.librarie.net/autor/7729/Mihaela-Brut

http://www.librarie.net/autor/7273/Sabin-Buraga



107

Atribut identificator - Un atribut XML de tip ID, utilizat la identificarea elementelor XMLcare au acelaşi nume. Poate servi şi la construirea relaţiilor între elemente, prin conectarea cu un atributreferinţă.

Atribut referinţă - Un atribut XML de tip IDREF, care face trimitere la un alt atribut (de tipidentitate) pentru a reflecta o relaţie î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 funcţionalitatea extinsă pentru a permite afişarea şinavigarea documentelor XML.

Bună formare, document bine format (well-formed document) - Proprietatea unuidocument de a fi de tip XML, adică de a nu încălca regulile limbajului XML, este o proprietate cetrebuie verificată de către orice consumator XML (se recomandă şi emiţătorilor). Un document XMLnu este obligatoriu să aparţină unui vocabular, dar trebuie să fie bine format din punct de vederesintactic. Un exemplu de regulă de bună formare este imbr icarea completă.

Cale XML - O construcţie de tip cale, care permite localizarea şi identificarea elementelor într-un document XML tratat ca un arbore. Vocabularul standard XPath oferă regulile după care secostruiesc aceste căi, dar se bazează pe metoda clasică de construcţie a căilor absolute sau relative alefişierelor.

CDATA - Date de tip caracter ce vor constitui valori de atribute.

Comentariu - Marcator special, de forma  care conţine text ignorat în general deprocesoare XML dar care pot ajuta un consumator uman să înţeleagă mai bine semnificaţia unor

porţiuni din document. Consumator XML - Sinonim cu receptor XML.CRM (Customer Relation Management) - sisteme informatice care gestionează relaţia cu

clientul; sunt caracterizate de faptul că modelele lor de date gravitează în jurul clienţilor - unidentificator de client este suficient pentru obţinerea unei cantităţi mari de date relaţionate (produsecomandate, totalizări etc.)

CSS - limbaj de definire a stilurilor, esențial în modelul AJAX Date de tip caracter - Şirurile de caractere care sunt conţinute în elemente, deci care nu

constituie marcatori XML. Se preferă denumirea de "date" pentru a accentua faptul că de obicei programele le tratează ca unităţi, ca date de tip text şi nu ca succesiuni (stringuri) de caractere.

Declaraţia DTD - Sinonim cu invocarea DTD.

Declaraţia XML - Primul marcator din orice document XML, este o instrucţiune de procesarece indică versiunea limbajului XML folosit şi setul de caractere (UTF, ISO etc.) folosit în document.

Depozit XML - Echivalentul unei baze de date XML: o colecţie organizată de documenteXML al căror scop este să stocheze cantităţi mari de date.

Deschidere (Start tag) - Exprimare prescurtată pentru eticheta de deschidere a unui marcator. Document - Fişier al cărui scop este să pună la dispoziţie informaţie în diferite forme (date,

text, imagini, sunet etc.). Documentele pot să conţină şi indicaţii de prelucrare a conţinutului saumetainformaţii (informaţii despre conţinut). Sunt excluse din definiţie fişierele care

prelucrează / transformă informaţia (aplicaţii, programe, procesoare etc.), acestea fiind considerateconsumatori sau generatori de documente.

DOM (Document Object Model) - Un model de date şi un tip de parsere care permit tratareadocumentelor XML ca pe arbori şi oferă metode de parcurgere facilă a nodurilor acestora. Aredezavantajul că memorează întreg arborele în memoria internă a consumatorului.

DTD (Document Type Definition) - Un fişier (cu extensia .dtd) care conţine regulile pe care trebuie să le respecte toate documentele ce fac parte dintr -un vocabular. DTD permite stabilirea dereguli privind marcatorii, dar nu oferă reguli privind informaţia marcată.

Element - Componenta de bază a unui document XML, format din marcator (care dă n umeleşi atributele elementului) şi conţinut (valoarea elementului).

Element document - Elementul rădăcină al unui document XML Element vid - Element XML fără conţinut, deci este sinonim cu marcatorul vid. Marcatorul

său poate fi scris în forma prescurtată, cu o singură etichetă: <nume_marcator /> Emiţător XML - O persoană sau un program care generează cod sursă XML.Entităţi 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 modsimilar cu apelul de variabile sau proceduri. În particular, pot fi apelate şi din DTD-ul în care au fostdeclarate. Pe scurt entităţile analizabile sunt şiruri de caractere reutilizabile, de orice dimensiune, de laun singur caracter la documente întregi.



108

Entităţi non-XML/neanalizabile (Unparsed entities) - Tipuri de informaţie apelate îndocumente XML, dar care sunt neanalizabile din punct de vedere XML, deci valorile lor nu suntformate din text brut, ci fac trimitere la variate tipuri de fişiere (imagine, sunet, fişiere Word etc.).

Granularitate - Densitatea documentelor XML dintr-un depozit de date. Granularitateridicată implică un număr mare de documente de dimensiune redusă (uşor de manevrat) în depozitul dedate. Granularitate redusă implică faptul că fiecare document acoperă cantităţi mari de date, ceea ce are

de obicei consecinţa că sunt mai dificil de manevrat. Imbricarea completă - Regula de bună formare a documentelor XML conform căreia oriceelement XML trebuie să fie conţinut de un alt element, mai puţin rădăcina, care trebuie să fie unică.Această regulă permite ca elementele unui document XML să poată fi reprezentate ca un arbore, modelfolosit de parserele de tip DOM. Imbricarea asigură existenţa relaţiilor de descendenţă/apartenenţă întreelemente (elementul tată conţine elementul fiu).

Imbricare (nesting) - Proprietatea elementelor de a se conţine unele pe altele; aceasta seasigură prin faptul că ambele etichete ale unui element fiu sunt conţinute între etichetele părintelui său.

Instanţă - De obicei sinonim cu obiectul, fiind obţinut prin fixarea tuturor proprietăţilor uneiclase. În context XML, o instanţă este un exemplu de document care respectă regulile unuivocabular/limbaj.

Instanţiere - Un tip particular de specializare, prin care, dintr-o clasă de obiecte cu proprietăţigenerale se obţine un obiect pentru care toate proprietăţile sunt specifice (fixate la valori precizate).

Obiectul obţinut se mai numeşte instanţă a clasei de la care s-a pornit. Se poate afirma că o clasă esteun timp complex de obiecte, ori că un obiect face parte dintr -o anumită clasă. În context XML, oricelimbaj/vocabular este o clasă sau tip de documente iar documentele care respectă regulile unuilimbaj/vocabular sunt obiecte/ instanţe ale limbajului/vocabularului. De aici provine şi prescurtareaDTD - document type definition (definirea unui tip de documente).

Instrucţiuni de procesare (Processing instructions) - Marcatori XML de forma<?marcator?> care adresează procesoarelor XML indicaţii privind prelucrarea anumitor porţiuni din document.

Invocarea DTD - Marcator special, care apare imediat după declaraţia XML, în aceledocumente care trebuie validate faţă de un vocabular DTD. Marcatorul precizează numele elementuluirădăcină şi regulile DTD (sau fişierul extern din care pot fi consultate de către 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 înţelege conţinutul unui document

de către 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 relaţional, care propune stocarea

datelor sub formă de arbori. Aceştia au avantajul că reflectă relaţii deincluziune/subordonare/apartenenţă între proprietăţile obiectelor descrise.

Model relaţional - Model consacrat de stocare a datelor sub formă de tabele între care existărelaţii (dependenţe) de diverse tipuri.

Mulţime deschisă de date (Open set, Open world) - Expresie care prezintă caracteruldeschis al modelului XML: un element sau un atribut se creează doar atunci când există o valoare pecare să o memoreze. Tot conţinutul unui document XML se consideră cunoscut, tot ce nu conţine se

consideră necunoscut. Aceasta are consecinţa că nu există valori NULL. Mulţime închisă de date (Closed set, Closed world) - Expresie care prezintă caracterul

modelului relaţional de a rezerva, la crearea structurii tabelelor, spaţiu de memorie chiar dacă anumitecâmpuri vor conţine valori NULL (necunoscute sau care nu vor fi introduse niciodată).

Nod XML - Nod al unui arbore obţinut prin convertirea codului XML (vezi parser, imbricarecompletă). Parserele convertesc în general fiecar e element într-un nod. Există parsere care convertesc şiatributele sau entităţile în noduri, caz în care nodurile XML vor avea diferite tipuri.

Notaţie - Un nume, de obicei o prescurtare, cu care se identifică un tip de informaţieneanalizabil (care nu trebuie tratat ca text brut) dar care poate fi referit în documente XML, prinatribute de tip entitate. Receptorul este responsabil cu identificarea aplicaţiei cu care se va deschideinformaţia neanalizabilă, pe baza identificatorului public care se precizează în notaţie.

Ocurenţă (Occurrence) - modul în care unui element i se permite să apară în cadrul părintelui său: cel mult o dată, cel puţin o dată, de oricâte ori ş.a.m.d. Ocurenţa fiecărui elementreprezintă una din regulile care trebuie stabilite într -un DTD.



109

Parser XML - Un tip particular de procesor XML, şi anume un program al cărui scop este săconvertească cod sursă XML în diferite modele de date, mai uşor de procesat. Modelele cele maifrecvent folosite sunt DOM şi SAX. Uneori, parserele asigură şi procesul de validare.

Parsing - Activitatea unui parser. În numeroase cazuri, include şi activitatea analizorului. Mairar (din raţiuni de performanţă), include şi activitatea validatorului.

Picior de cioară (Crow foot) - metodă grafică de reprezentare a relaţiilor de tip 1 la 1, 1 la n

etc., în cadrul modelului relaţional, între tabelele unei bazelor de date. Plic XML (Envelope) - Elementul rădăcină al unui document XML, dacă acesta conţineatribute care identifică/descriu documentul, emiţătorul sau receptorul său.

Procesor XML - Deşi uneori este utilizat ca sinonim cu consumator XML, definiţia procesorului este ceva mai restrânsă - se referă doar la acei consumatori care aplică procesări(transformări) codului sursă XML. Aceasta elimină din definiţie utilizatorii umani care citesc XML saudocumentele care memorează XML, deci un procesor XML este un program care acceptă date deintrare în format XML.

Producător XML - Un tip particular de emiţător XML, care este responsabil şi cu producereacodului sursă, deci se exclud emiţătorii care doar intermediază transferul de fişiere.

Prolog XML - Sinonim cu declaraţia XML. Raport - Un document formatat care prezintă într -o formă lizibilă, estetică, conţinutul 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ă codsursă XML.

Redundanţa - fenomenul prin care anumite date se repetă într -o bază de date. În modelulrelaţional, redundanţa este minimizată prin normalizare. În modelul arborescent, redundanţa fie se

păstrează, fie se elimină cu ajutorul atributelor referinţă. Referinţe entitate - Numele cu care sunt apelate entităţile, sunt marcatori speciali de forma

&marcator; (dacă sunt apelate din documente) sau %marcator; (dacă sunt apelate din DTD).Relaţie 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ă aparţine sau că este un fiu faţă de celălalt.

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ă foloseşte o fereastră de parsing, zonă a memoriei interne prin

care se derulează textul documentului, deci economiseşte memoria internă. Schema XML (XML Schema) - Are acelaşi rol cu un DTD, dar este mai puternică, oferind

un număr suplimentar de reguli care controlează atât marcatorii permişi de vocabular, cât şi informaţiace va fi conţinută în potenţialele documente. O schemă XML este construită cu limbajul standard XMLSchema care este, la rândul său, un vocabular XML cu un scopul indicat aici.

SGML (Standard Generalized Markup Language??) - Limbajul care a consacratmarcatorii de forma <nume marcator>, din care s-au dezvoltat, prin specializare, limbaje ca XML şiHTML. Conform acestui tip de limbaje, tot ce apare între paranteze ascuţite reprezintă marcatorul, iar ce apare în afara acestora este informaţia marcată.

Spaţiu de nume (Name space) - Metodă de calificare a unor seturi de elemente sau atributecu prefixe unice, ce permit validarea a diferite porţiuni de document după diferite vocabulare, identificate cu prefixele respective.

Text brut (Plain text) - Text fără formatări, 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 căruia i se indică fişierul XML şi fişierul care conţine vocabularul. Validator XML - Un tip particular de procesor XML, şi anume un program al cărui scop este

să verifice dacă un document XML aparţine unui sublimbaj XML, adică dacă respectă regulile unuivocabular XML dat.

Vocabular - tip de document XML. Un vocabular indică toate regulile de construire adocumentelor XML comunicate între un emiţător şi un receptor, poate fi considerat un contract întrecele două părţi care comunică. Vocabularul poate fi impus fie de emiţător, fie de receptor. Metodeleclasice de construire a unui vocabular sunt DTD şi schemele XML (vezi DTD, Schema XML). Undocument XML nu trebuie obligatoriu să aparţină unui vocabular, dar vocabularele asigură caracterulextensibil al XML, adică posibilitatea de a crea sublimbaje pentru diferite tipuri de probleme, cu propriimarcatori şi propriile reguli, care să fie acceptate apoi de către toţi cei implicaţi în problemelerespective.



110

XML (Extensible Markup language) - Limbajul extensibil de marcare. Trăsăturile saledefinitorii sunt:

are suport pentru seturi de caractere internaţionale; este extensibil, adică permite crearea de sublimbaje (vocabulare) specializate pe anumite

domenii sau probleme, obţinute prin stabilirea setului de marcatori acceptaţi şi a regulilor defolosire a acestora

este un limbaj de marcare a informaţiei particularizat din SGML; este un standard acceptat universal de producătorii 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 Facultăţii deŞtiinţe Economice şi Gestiunea Afacerilor, Universitatea Babeş Bolyai, începând din anul 2006. Aobţinut titlul de doctor în anul 2004, în domeniul Cibernetică şi Statistică Economică, cu tezaContribuţii la conceperea, proiectarea şi realizarea afacerilor pe Internet , sintetizată în volumulcu acelaşi titlu publicat la Editura Risoprint în anul 2004, premiat cu premiul Consiliului CercetăriiŞtiinţifice al Universităţii Babeş Bolyai. Este absolvent al programelor de masterat şi licenţă încadrul aceleiaşi facultăţi, absolvind secţia de Informatică Economică. În anul 2006 a reprezentatfacultatea la XML Summer School la Universitatea Oxford.

Domeniile sale de ex pertiză sunt modelele de aplicaţii Web pentru afaceri electronice, în specialcele bazate pe XML, şi managementul calităţii software. În aceste domenii, a condus două granturicâştigate prin competiţie naţională: grantul doctoral Cercetări legate de modelarea şiimplementarea comerţului electronic (finanţat de CNCSIS prin programul TD) şi grantulpostdoctoral Regândirea comerţului electronic – o abordare în sensul omogenităţii (finanţat deMCT prin programul CEEX).A participat ca membru în alte 10 granturi conduse de membriicatedrei, a publicat 2 cărţi de unic autor şi capitole în alte 11 cărţi cu mai mulţi autori, precum şinumeroase articole şi comunicări la conferinţe din ţară şi străinătate.

Documents

Suport Curs UIA