SUPORT DE CURS
ANUL III
Semestrul 2
Cluj–Napoca
2010
UNIVERSITATEA BABEŞ-BOLYAI, CLUJ-NAPOCA
Centrul 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 cursului
Date de contact ale titularului de curs:
Nume: Buchmann Robert Andrei
Birou: 436, sediul FSEGA
Telefon: 40 + 0264-41.86.52/3/4/5
Fax: 40 + 0264-41.25.70
E-mail: [email protected]
Consultaţii: Luni 14-16, Marţi 14-16
Date de identificare curs şi contact tutori:
Denumirea cursului: Utilizarea Internetului în
Afaceri Tutore: Lect.Dr. Buchmann Robert Andrei
E-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 CSS
la 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 cursului
Cursul prezintă tehnologiile ce asigură interoperabilitatea sistemelor informatice pentru
afaceri on-line, cu accent pe modelul AJAX, dominant în contextul Web 2.0. În acest scop se urmărește
familiarizarea cu tehnologiile ce stau la baza AJAX: JavaScript, DOM; CSS, XML, JSON și o serie de
biblioteci de înaltă productivitate (Dojo, Prototype, Scriptaculous).
Datorită audienței țintă a cursului, primul modul va asigura fixarea sintaxei XML cu referințe
la cunoștințele prerechizite legate de limbajele de marcare și HTML, apoi se trece la dezvoltarea de
deprinderi practice în exploatarea tehnologiilor.
Tehnologiile vizate sunt de tip open-source și standarde WWW, fiind accesibile gratuit
utilizatorilor și implicit studenților. Cursul trece în revistă și o serie de vocabulare XML strict orientate
spre afaceri, precum XBRL.
Piaţa muncii din România pe domeniul Web indică o tendință de migrare dinspre siteurile
clasice, Thin Client, spre siteurile bazate pe AJAX și XML. Primele două module ale cursului au un
caracter puternic tehnic, în timp ce ultimul model oferă o imagine sintetică asupra modelelor de afaceri
ce pot avea de 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 platforma software de învăţământ la distanţă: https://portal.portalid.ubbcluj.ro/
Modulul I. Limbajul 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
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
Modulul III. Modele de afaceri pe Internet
3. Categorii de afaceri pe Internet
3
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
Pentru paginarea temelor, recomandăm consultarea cuprinsului din partea a doua a
materialului de faţă.
Formatul şi tipul activităţilor implicate de curs
Cursul 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 deja
angajaţ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 proiectului
practic.
Materiale bibliografice obligatorii
BUCHMANN ROBERT, „Conceperea, proiectarea şi realizarea afacerilor pe Internet‖, Ed.
Risoprint, Cluj Napoca, 2004;
BUCHMANN ROBERT, „Rolul XML în interoperabilitatea sistemelor informatice pentru
afaceri‖, Ed. Risoprint, Cluj Napoca, 2007;
CRANE DAVE et al., "AJAX in Action", Manning, 2005
CRANE DAVE et al., "Prototype and Scriptaculous in Action", Manning, 2007
PHILIPS L.A., XML, Ed.Teora, 2001
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 de
către titularul de curs.
Materiale şi instrumente necesare pentru curs Laborator dotat cu calculatoare și sistem de operare Windows, videoproiector, materialul
bibliografic, instrumente software gratuite (browser, Notepad, biblioteci disponibile gratuit pe Internet).
Calendar al cursului
Sunt estimate 2 întâlniri preprogramate pe semestru, cu datele şi locaţiile afişate pe site-ul
facultăţii la începutul semestrului. Premergător fiecărei întâlniri se recomandă parcurgerea materialului
de 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 din
primele 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 contestare
imediată.
Nu se vor accepta proiecte practice sau participări la examen la alte date decât cele
programate.
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 timpul
examenului 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:
Se vor recomanda soluțiile de asigurare a accesibilității pentru persoanele cu dizabilități,
oferite de sistemul de operare Windows.
Strategii de studiu recomandate
Recomandă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 de
proiectarea 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 de
procesare a lor. Astfel, există o ambiguitate generală legată de "care este scopul XML?" Răspunsul cel
mai 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 orice
document XML şi care impun structura pe care trebuie să o respecte orice marcator XML;
un limbaj auxiliar, Document Type Definition (DTD), care permite definirea altor
limbaje (vocabulare), prin pentru definirea instrucţiunilor acestora (marcatori, atribute) şi
a modului lor de utilizare.
Astfel, puterea XML nu este legată de crearea unor documente sau programe, ci de crearea de
vocabulare (limbaje de tip XML) cu marcatori şi atribute personalizate, cu care apoi se construiesc
documentele şi programele, în funcţie de scopul propus şi de potenţialii receptori. Dacă se urmăreşte
distribuirea 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 receptorilor1.
Aceasta necesită un efort suplimentar dar asigură posibilităţi nelimitate de personalizare şi de
distribuire între diferite platforme hardware şi software. Exemple de vocabulare XML consacrate sunt
MathML (limbaj de marcare matematic) şi CML (limbaj de marcare în chimie), specializate în
formatarea şi structurarea datelor din domeniile respective (formule matematice, formule chimice), în
vederea utilizării lor de către specialişti sau programe specializate în domeniu. Alte exemple esenţiale
sunt o serie de vocabulare XML destinate chiar manipulării de documente XML: XSL permite
transformarea şi formatarea de documente, XLink permite relaţionarea marcatorilor din documente
XML 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 unui
vocabular. 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. În
cazul în care documentele sunt de uz intern, fără intenţii de distribuire pe scară largă, şi atunci când se
garantează faptul că toţi receptorii documentelor vor fi pregătiţi să le prelucreze, se poate evita
construirea 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 receptori
care nu se cunosc în prealabil, crearea unui vocabular devine necesară ca bază contractuală pentru
schimbul 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 de
tabel) 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 datelor
XML se folose;te vocabularul XSL.
9
b. structurarea datelor în vederea stocării într-o bază de date relaţională; practic, exemplul de mai
sus 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 datele
marcate), î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 de
date:
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 marcatori
diferită:
<ListaPreturiFructe> <Fruct Pret="10000"> Mere
</Fruct> <Fruct Pret="12000"> Pere </Fruct> </ListaPreturiFructe>
sau:
<ListaPreturiFructe> <Fruct Denumire="Mere" Pret="10000"> </Fruct> <Fruct Denumire="Pere" Pret="12000"> </Fruct> </ListaPreturiFructe>
Transformarea documentelor XML se poate realiza printr-o serie de operaţii de restructurare a
marcatorilor, prin programe capabile să manipuleze arbori XML sau cu ajutorul limbajului specific de
transformare - 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ă, pentru
transfer 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 ale
acestuia 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 nu
au 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
Pret Denumire
Fruct
Denumire Pret
Mere 10000 Pere 12000
10
<Fruct Denumire="Mere" Pret="10000"/>
Unitatea fundamentală a unui document XML este elementul. Marcatorul dă numele
elementului, iar conţinutul delimitat de etichetele de deschidere şi închidere este considerat valoarea
sau conţinutul elementului. Această terminologie este general adoptată de toate instrumentele de
prelucrare XML, deoarece asociază elemente cu valori de elemente, atribute cu valori de atribute şi
face mai clară flexibilitatea XML, prin care elementele pot deveni atribute sau invers 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 este
format 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. Spre
exemplu programele care tratează documentul XML ca pe un arbore de date separă conceptele
valoarea elementului şi conţinutul elementului. În astfel de cazuri, conţinutul unui element va fi
considerat în arbore un nod fiu de tip frunză, care are valoare de tip text şi nu mai are nici un nod în
subordine. Se va reveni la această problemă în 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 toate
funcţiile HTML, dar nu se limitează la acestea. Vocabularele XML pot defini şi marcatori în alte
scopuri: instrucţiuni de procesare, descrieri semantice etc.
Desigur, elemente comune există, având în vedere că ambele limbaje sunt specializări ale
SGML. 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 ora
actuală. De aici s-ar putea trage concluzia că HTML poate fi considerat un vocabular XML, adică un
limbaj în care sensurile marcatorilor au fost deja fixate şi acceptate de orice partener care citeşte
documente 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-au
dezvoltat divergent spre obiective diferite. Motivul pentru care HTML nu este un vocabular XML este
că 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 cazuri
imbricare 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 se
intersectează 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 ghilimele5, valorile
atributelor 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ă un
document 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) sunt
cele care respectă aceste reguli sintactice în scrierea marcatorilor, reguli obligatorii în XML indiferent
de 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ă HTML
nu este un vocabular XML. "Buna formare" este o constrângere specială impusă de XML, care nu
există î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 (cu
limitarea 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 XML
numit XHTML. Acest limbaj a fost construit în aşa fel încât defineşte marcatorii consacraţi în HTML
cu semnificaţiile lor consacrate, dar le impune regulile de bună formare (obligativitatea imbricării, a
ghilimelelor 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 pe
care le folosesc mediile de programare şi nu ghilimele rotunde, folosite de editoarele de texte, ceea ce
cauzează adesea o eroare dificil de sesizat.
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ă proceduri
de prelucrare a marcatorilor şi a datelor marcate. Înainte de asta trebuie să fie capabile să delimiteze şi
să extragă marcatorii şi conţinutul lor, atributele şi valorile lor, pentru a le atribui unor variabile de
lucru. 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 variate
sisteme de operare, inclusiv Windows XP, sub forma unor biblioteci de funcţii apelabile din variate
medii de programare obiectuală. S-au consacrat două astfel de modele, şi două tipuri de parsere
corespunzătoare:
A. DOM (Model obiectual a l 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 în
arbori, 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) puternice
pentru parcurgerea arborilor, convertirea datelor din arbori în diferite tipuri de variabile sau
modificarea 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ătoare
construcţiilor auxiliare permise în XML.
Dezavantajul DOM este dat de faptul că întreg documentul XML este încărcat în memoria
internă 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, ci
caracter 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 executa
la apariţia evenimentului.
Se poate remarca similitudinea între modul de procesare a fişierelor XML şi modul de
procesare a bazelor de date relaţionale. În teoria bazelor de date relaţionale, SGBD-ul este programul
responsabil cu convertirea fişierelor fizice de pe disc, care conţin datele, într-un model
tabelar/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 date
arborescente şi bazele de date relaţionale, despre care s-a considerat multă vreme că s-a finalizat cu
triumful ultimului model. În prezent, pentru anumite utilizări ale XML, putem considera că fişierele
XML 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ările
documentelor XML, ca succesiune de instrucţiuni (marcatori) sau ca structură de date, rămâne la
latitudinea 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ării
regulilor 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, spre
exemplu, notele studenţilor într-un tabel trebuie să se impună regula conform căreia nici o notă să nu
fie din afara intervalului 1-10. Alte exemple de validări sunt preţurile şi cantităţile care trebuie să fie
pozitive, intervalele de vârstă acceptate în diverse situaţii etc. Prezenţa datelor invalide în bazele de
date poate avea efecte grave asupra programelor care folosesc acele date şi asupra rezultatelor acestora.
În baze de date scopul validării este să se asigure un conţinut valid al tabelelor în raport cu sensul
atribuit datelor.
În perspectiva tratării fişierelor XML ca şi coduri sursă, vocabularul devine setul permis de
instrucţ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ând
deopotrivă 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, pe
impunerea 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 de
vocabular. Distribuirea vocabularului permite ca regulile vocabularului să fie aduse la cunoştinţa
tuturor utilizatorilor şi programelor care ar putea lucra cu acel tip de documente pentru a stabili o
consistenţă în utilizarea marcatorilor personalizaţi. În momentul în care se transmite un fişier XML de
la 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 şi
receptor. 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 a
documentului 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 diferite
vocabulare, cu alte cuvinte, fiecare marcator îşi poate invoca propriul vocabular care să-i guverneze
conţ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 de
apariţ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 de
documentele XML care îl invocă.
Spre exemplu, HTML este un tip de document SGML: se ştie că fişierele HTML şi SGML
sunt, de fapt, fiş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, se
recomandă folosirea editoarelor profesionale (XMLSpy, StylusStudio) care permit şi construirea de
vocabulare, 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 reguli
la 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ă respecte regulile mai multor DTD-uri simultan,
astfel se va putea afirma că documentul aparţine mai multor tipuri de document (vocabulare). De
exemplu, 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ărui
scop 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 copil
trebuie 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 de
un 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 în
format XML: <categorie-varsta>15</categorie-varsta> <profesie>elev</profesie> <nume>Ion</nume>
Aceste date vor fi considerate invalide în raport cu vocabularul XML Schema, deoarece
încalcă trei reguli:
ordinea (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ţime
de 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şa
cum este în cazul regulilor de bună formare, impuse de standardul XML) ci relativ la un vocabular. Un
acelaşi document poate fi valid conform cu unele vocabulare (DTD sau scheme) şi invalid în raport cu
altele. 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 la
acesta. Cu ajutorul vocabularelor, XML asigură un nivel de interoperabilitate superior hipertextului,
interoperabilitatea structurală sau sintactică, ceea ce înseamnă că entităţile Web pot să schimbe
documente 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 va
reveni ulterior); validitatea nu condiţionează operaţia de parsing şi documentele XML pot fi
create 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 este
independent (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
Elementele
Sunt componentele fundamentale, alcătuite din:
etichetele marcatorilor;
16
conţinut (valoarea elementului) - conţinutul poate la rândul său să fie constituit din alte
elemente (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 fiind
considerate delimitatori de atribute);
Excepţie privind numele: nu pot să înceapă cu cuvântul "xml" (majuscule, litere mici sau orice
combinaţie); se recomandă şi evitarea caracterului ":" folosit în anumite scopuri specifice
(spaţiile de nume).
Atribute le
Sunt 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 t ip caracter
Conţ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 CDATA
Aceste 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ă formare
deoarece <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 în
secţ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ţiunea
CDATA, 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 pentru
includerea unor caractere speciale (entităţile text), inclusiv a caracterelor nepermise. Exemplul
anterior poate fi scris şi în forma: <Paragraf> Forma generala a unei etichete XML este: <eticheta> </Paragraf>
Aici, "<" este 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 caz
numele 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 recunoscute
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 fi
reutilizată nelimitat8.
entităţile pot fi definite la o adresă URL sau în fişiere externe, care se indică parserului pentru
consultare.
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 care
se 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 de
caractere dar poate conţine orice structuri ce pot fi reprezentate prin caractere, inclusiv şiruri de
interogare, seturi de perechi atribut-valoare etc. Totuşi, conţinutul parametrului nu va putea fi procesat
sub formă de atribute, aplicaţia consumatoare fiind nevoită să folosească o metodă de extragere a
subş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 ignora
setul 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 mod
normal, 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 lor
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 elementului
Student 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. Mai
ră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, ci
avem 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şi
arată ca un atribut obişnuit. De aceea, mai poartă şi denumiea de pseudoatribut. Indicaţia de
procesare ar putea arăta şi astfel: <?CR 101?>
desigur, cu condiţia ca programul consumator să înţeleagă ce înseamnă instrucţiunea CR şi ce
semnifică parametrul 101. Acest detaliu este important deoarece, după cum se va arăta în capitolul
Modele 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ă o
structură 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.
Comentari i
Forma comentariilor este următoarea: <!-- Autorul documentului este Buchmann Robert -->
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ă rezultatul
operaţ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 DTD
Această 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-ul
care 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 dimensiunea
documentelor. În această situaţie, fiecare document va conţine calea sau URL-ul unde este
poate fi consultat DTD-ul. Evident, soluţia cea mai comodă este ca DTD-ul să poată fi
consultat de la o adresă Web unde să fie permanent disponibil. În această situaţie avem un
DTD 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 timp
conţine o definiţie de vocabular internă; de regulă această metodă se foloseşte când DTD-ul
intern îş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 (de
elemente şi atribute) identice din vocabulare diferite. Exemplu:
<UnElement xmlns:xlink="http://www.w3.org/1999/xlink">
<Legatura xlink:type="simple" xlink:href="fisier.xml" /> </UnElement>
Această construcţie foloseşte atributul special xmlns:xlink care este un atribut cu nume şi
valoare bine formate pentru un parser care nu înţelege spaţii de nume. Majoritatea parserelor moderne
acceptă însă spaţiile de nume şi vor da următoarea interpretare:
Elementul UnElement va fi utilizat conform cu regulile vocabularului XLink şi orice
construcţ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 vocabularul
XLink, 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 numele
vocabularului.
Cu alte cuvinte, spaţiile de nume sunt o metodă de calificare10
a marcatorilor şi a atributelor,
folosind caracterul ":" pe post de calificator. Textul cu care se face calificarea tuturor numelor din
spaţiul respectiv poartă numele de prefix, în acest caz prefixul fiind xlink. Prefixul este identificatorul
local 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ă ca
aparţ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ţin
vocabularului XML Schema şi trebuie calificaţi în spaţiul de nume xs11. Reluăm exemplul pentru
reamintire:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:sequence>
<xs:element name="profesie" type="xs:string" minOccurs="0" /> <xs:element name="categorie-varsta" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:minInclusive value="18" /> <xs:maxInclusive value="100" /> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence>
9 Nu este obligatoriu ca la adresa respectivă să existe ceva. Important e ca valoarea atributului
prefixat cu xmlns să fie un nume unic. Este recomandat ca acest nume să indice spre o resursă utilă din
punct de vedere informativ. 10
Calificare în sensul de "aparţine". Marcatorii şi atributele calificate cu un nume de
vocabular, aparţin acelui vocabular. Această tehnică este similară cu calificarea obiectuală, unde se
foloseş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 pentru
construcţ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 în
vedere 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 interiorul
elementului în care a fost invocat cu atributul xmlns, se recomandă ca toate spaţiile de nume să fie
declarate î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 sau
valorile atributelor sau în structurile XML auxiliare. DOM nu este o aplicaţie în sine, ci un model
abstract 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 în
clase, obiecte şi metode. Astfel, DOM este independent de platformă şi limbajul de programare, fiind
considerat un strat între parser şi aplicaţiile consumatoare de XML. Practic, parserul citeşte date din
sursa XML şi alcătuieşte arborele DOM translatând imbricările între marcatori în relaţii tată-fiu şi
unităţile XML în noduri ale arborelui.
Tipul de dată fundamental în DOM este DOMstring, un şir format din caractere de 16 biţi în
care se transpune orice valoare XML nativă. Variate limbaje de programare implementează acest în
propriile tipuri 16-bit string native, altele (C++) trebuie controlate pentru a nu mapa DOMstring peste
un tip de string 8-bit.
Nucleul DOM, numit DOM Core, este un set de 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 un
fiu al nodului rădăcină, alături de declaraţia XML. Prin aceasta, sugerăm că nodurile DOM sunt de
diferite tipuri: elemente, atribute, conţinut textual, comentarii, instrucţiuni de procesare etc. Este
important de reţinut că nodurile atribute sunt tratate ca proprietăţi ale nodurilor elemente şi nu ca
noduri 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ă o
colecţie de noduri poate să apară chiar în subordinea nodului rădăcină, indică faptul că acesta poate
avea ş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, cum
sunt 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 lucra
cu documente nonXML (HTML sau CSS).
Interfeţele extinse trebuie să apară în implementările care lucrează cu XML şi implicit cu
XHTML.
<HTML> <HEAD>
Document Node Documentul complet
NodeList
Element Node <produse>
Element Node <produs>
NodeList
NamedNodeMap NodeList
AttrNode ID=”p01”
Character Data
Text 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 MSXML2
disponibil pe platforme Microsoft. Printre proprietăţile şi metodele acestei implementări se remarcă cea
de încărcare a fişierului (load) şi indicaţia de încărcare asincronă (async). Încărcarea asincronă permite
codului 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ţele
interoperabilităţii deci, implicit, de integrarea XML în aplicaţiile software. Se poate afirma că în
domeniul e-business XML este mai mult decât un limbaj, este un suport al paradigmei sistemelor
colaborative. 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 depinde
dezvoltarea pe scară largă a sistemelor colaborative.
Interoperabilitatea afacerilor electronice presupune conectarea şi comunicarea fluidă în cadrul
unei reţele de furnizori şi parteneri de afaceri, grefată pe o reţea de aplicaţii şi agenţi software. XML ca
limbaj nu se adresează strict problemelor e-business, ci oferă o sintaxă utilă în crearea limbajelor
(vocabularelor) ce modelează probleme economice.
Beneficiile principale ale afacerilor electronice sunt costurile reduse şi timpii de 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 punct
de interconectare între sisteme ce folosesc formate diferite de date produc costuri proprii care riscă, în
sisteme eterogene să compenseze negativ reducerile de cost 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 propriul
model de date şi chiar diferite aplicaţii ale aceleiaşi organizaţii folosesc modele diferite. Problema e
doar parţial rezolvată prin adoptarea standardelor, dar aceasta reduce doar parţial eteorgenitatea
mediului economic virtual. Contribuie la ameliorarea problemei şi adoptarea sistemelor Electronic Data
Interchange, dar acestea au succes în companiile mari care îşi permit achiziţia unor platforme orientate
EDI.
Interoperabilitatea trebuie să poată fi asigurată la orice nivel, chiar şi sub nivelul small
business, public sau privat, şi la orice scară (independent de numărul de parteneri) astfel încât orice
două sisteme ce pot fi conectate hardware să poată schimba date cu efort minim de conversie. În unele
cazuri, partenerii de afaceri sunt cei care dictează formatul datelor care se schimbă între 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 fie
necesară 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 de
intrare. În alte cazuri, este implementată o interfaţă de conversie între sisteme. Totuşi, în contextul
efectului de reţea, numărul de interfeţe 1 la 1 ajunge să fie foarte costisitor. Soluţia ideală este crearea
unui format universal standard, cu valoare de coloană vertebrală, la care să fie convertite toate
formatele 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 conversii
dinamice de format. XML se bazează pe structuri de text, aşadar este independent de platformă şi de
reprezentarea 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 poate
servi şi ca format în care să se convertească datele din alte surse: date din formulare HTML, din tabele
relaţionale, din fişiere text aplatizate, din aplicaţii de mesagerie, din spreadsheet-uri. Indiferent de
sursă, sunt necesare instrumente de generare şi manipulare XML, dintre care cele mai importante au
fost deja prezentate în materialul de faţă. La acestea mai sugerăm câteva cu caracter mai particular.
Seturile de înregistrări ADO oferă posibilitatea de a genera XML pe baza acestora. În
versiunea 2.1 era vorba de posibilitatea de a salva XML pe disc într-un format care echivala
î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 ASP
Response.
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 forma
canonică XML. Alternativele la forma canonică au fost introduse de SQL Server 2000, prin care
interogările pot stabili modelul de date XML care să fie generat. Astfel, a apărut problema
vocabularelor 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 de
creare 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 o
operaţ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 de
date.
Două vocabulare consacrate în afacerile electronice sunt cXML şi XML Common Purchase
Order (XML CPO). Rolul lor este să modeleze documente uzuale în derularea afacerilor sub forma
unor mesaje cu structura fixată de vocabulare. cXML încapsulează mesajul în elementul cxml, al cărui
structură internă depinde de tipul de document. Ca alternativă, Microsoft a propus pentru BizTalk
Server vocabulare diferite pentru fiecare tip de document. XML CPO este un astfel de vocabular,
destinat modelării comenzilor de cumpărare, care corespunde unui mesaj de tip OrderRequest în
cXML. Numeroase astfel de vocabulare s-au dezvoltat în timp. O parte pot fi consultate la site-urile
creatorilor acestora: www.rosettanet.org, www.xbrl.org şi www.biztalk.org fiind două surse de
referinţă.
Un mesaj cXML de tip OrderRequest modelează o comandă sau o actualizare de comandă.
Structura acestuia poate fi consultată în 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 ce
specifică 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 elementul
rădăcină CommonPO şi elementele POHeader, BillTo, ShipTo, apoi o colecţie de elemente Item şi un
element Total.
Astfel, o transformare între cele două vocabulare presupune convertirea elementului ItemOut
din cXML în Item din XML CPO, Shipping în CarrierDetail şi calcularea QuantityTotal şi
LineItemTotal.
<xsl:template match="cXML"> <CommonPO> <xsl:apply-templates select="Request"/> <FOB ShipPaymentMethod="CC"/> <SpecialCharge Type="X" HandlingMethod="XX"/> <TermsOfSale PaymentMethod="PCard"/> <DateReference Description="XYZ"/> <xsl:apply-templates select="Request/OrderRequest/OrderRequestHeader/Shipping"/>
....
Regula exemplificată scrie elementul CommonPO în cadrul căruia invocă regulile care
transformă celelalte elemente şi creează câteva elemente care nu apar în sursa cXML.
Deşi foile de transformare XSLT se dovedesc esenţiale pentru comunicarea între vocabulare
diferite, crearea unei transformări pentru fiecare contact cu un vocabular partener poate deveni o
sarcină anevoioasă. Preferabil e ca transformarea să fie generată automat prin compararea
documentelor sursă şi destinaţie şi eventual să poată gestiona şi fişiere text aplatizate sau alte formate
text. În acest scop există numeroase produse software dedicate domeniului B2B pentru gestionarea
mesajelor, cum este cazul BizTalk Server produs de Microsoft. Prin interfeţe prietenoase, acest
instrument 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 care
trec mesajele.
25
BizTalk Mapper este una din componentele fundamentale în acest scop. Este capabil să preia
specificaţiile unor mesaje originale (ca XML Schema sau descrieri de mesaje text plate) şi să ofere o
interfaţă grafică pentru modelarea personalizată a componentelor acestor mesaje. Procesări
intermediare între modelul sursă şi modelul destinaţie sunt posibile prin crearea unor intermediari
speciali numiţi functoizi. E vorba de procesări care nu sunt suportate de XSLT, cum sunt manipulări
complexe 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 fi
utilizaţi pentru obţinerea valorilor calculate, ori se poate apela la elemente xsl care permit încapsularea
de scripturi în secţiuni CDATA. Există un număr mare de functoizi pentru calcule uzuale, care
generează codul respectiv automat în Visual Basic.
BizTalk Management Desk este componenta prin care se pot defini organizaţii virtuale
asociate vocabularelor sursă, porturi ce indică vocabularul destinaţie şi locaţia destinaţie şi canale ce
permit negocierea vocabularului cu porturile. Portul este punctul la care are loc transformarea
vocabularelor şi care livrează mesajul final la o destinaţie dorită. Canalul poate fi personalizat în
funcţie de protocolul şi specificaţiile de securitate dorite.
Activităţile B2B uzuale implică adesea şi o sincronizare a unui flux de mesaje de tipuri
diferite. BizTalk permite definirea unui astfel de flux în mod grafic la nivelul serverului prin definirea
documentelor de orchestrare. Acestea sunt formate dintr-o serie de acţiuni şi noduri decizionale care
implică 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 alinieze
la fluxul respectiv.
Comunicarea cu partenerii B2B necesită şi crearea unui portal în care să aibă loc agregarea
vocabularelor. Biztalk.org este un astfel de depozit de vocabulare pentru mesaje BizTalk.
RosettaNet.org este un depozite de fluxuri standard de mesaje. Un număr important de organizaţii
impun astfel de portaluri ca şi condiţie contractuală pentru alinierea la vocabularele proprii.
XBRL13
este un vocabular XML standardizat pentru domeniul afacerilor, pentru a permite
raportarea în format XML. Standardul este gestionat de XBRL International14
, un consorţiu nonprofit
susţinut de jurisdicţii naţionale din diferite ţări, care activează în interesul adoptării standardelor pentru
aplicaţiile contabile, generatoarele de raportări financiare, auditare etc. Eforturile pe marginea XBRL
se îndreaptă spre unificarea structurilor de raportare financiară, mai întâi la nivel naţional, prin modele
locale 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 a
formatului în aplicaţiile financiare şi de proiectul american lansat de U.S. Federal Deposit Insurance
Corporation 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, cu
urmă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ţii
opţ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.org 15
Rezultatele proiectului sunt sintetizate de articolul disponibil la
http://www.xbrl.org/us/us/FFIEC%20White%20Paper%2002Feb2006.pdf
26
datelor financiare din documentele XBRL. Vocabularul de bază poate fi specializat de jurisdicţiile
naţ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 de
a stabili relaţii între conceptele XBRL sau între acestea şi resurse Web concrete sau între marcatorii
XBRL. Baza de legături imprimă un caracter semantic conceptelor structurate cu XML Schema, de
aceea 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 set
de 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 la
nivelul marilor corporaţii. Scopul schimbării este alinierea raportărilor financiare la un standard
transparent şi este una din priorităţile organismelor de auditare financiară internaţională în urma
incidentelor la scară mare precum cazul Enron. Criticii indică faptul că XBRL va ajunge la o
complexitate mult prea mare pentru ca integrarea sa să fie fezabilă, alţii indică faptul că, aşa cum se
întâmplă în XML, complexitatea documentelor este proporţională cu complexitatea fenomenului
modelat.
Î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 de
caractere 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ă a
erorilor;
Longevitatea XML depăşeşte longevitatea sistemelor pe care le alimentează, ceea ce nu e
cazul formatelor proprietare sau binare. Datele XML pot persista şi fi transferate la trecerea
dintr-o versiune în alta a sistemului;
Vocabularele şi transformările asigură comunicarea între parteneri B2B fără ca aceştia să fie
informaţ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 în
contextul 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 pe
serializarea pachetelor transferate în mediile distribuite
Bibliografie modul
BUCHMANN ROBERT, Conceperea, proiectarea şi realizarea afacerilor pe Internet, Ed.
Risoprint, Cluj Napoca, 2004;
BUCHMANN ROBERT, Rolul XML în interoperabilitatea sistemelor informatice pentru
afaceri, Ed. Risoprint, Cluj Napoca, 2007;
PHILIPS L.A., XML, Ed.Teora, 2001
Teste de verificare a 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
Recapitulare
Modulul 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. De
asemenea, s-au trecut în revistă aspecte legate de XBRL și alte vocabulare XML orientate strict spre
modelarea afacerilor.
În cele ce urmează se prezintă tehnologiile care definesc modelul AJAX, precum și o serie de
exemple relevante prin care se subliniază deosebirile dintre modelul AJAX brut și bibliotecile Dojo,
Prototype și Scriptaculous.
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 la
a formata un document, spre modelele încadrate în aşa numita generaţie Web 2.0, printre care Rich
Client, ce promovează transferul efortului de procesare dinspre server spre client, pentru a micşora
efortul 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 a
fluidităţii experienţei utilizatorului care apropie regimul de utilizare a aplicaţiilor Web de regimul de
utilizare al aplicaţiilor desktop (în care interfaţa cu utilizatorul şi baza de date se află în aceeaşi
memorie, 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, gestionare
locală de e-mail - vezi Outlook, diverse aplicaţii desktop consumatoare de date on-line etc.), toate
acestea fiind aplicaţii ce necesită un efort prealabil de instalare şi configurare. Dezvoltarea Web spre
această direcţie a presupus găsirea de soluţii care să elimine necesitatea instalării modulelor client. În
acest 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 se
consideră 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şte
manipularea textului (în siteuri Web orientate spre text); Flash necesită pentru creare mediul de
programare Flash (oferit în prezent în cadrul unor produse Adobe) iar pentru vizualizare un 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 multimedia
rezonabile, 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 browserele
implementează standardele Web); AJAX necesită pentru creare doar un editor de texte iar pentru
vizualizare 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 de
JavaScript ş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 e
asigurat de HTML (structura paginii) şi CSS (formatul paginii), atât elementele HTML cât şi
stilurile CSS fiind manipulate dinamic de JavaScript prin intermediul modelului DOM. Partea de
server nu mai trebuie să asigure generare dinamică de cod HTML, ci alimentarea modulului Rich
Client AJAX cu date în format text (inclusiv XML).
Modelul AJAX e 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 AJAX
100%, deoarece nu exploatează transferul asincron de date – elementul care leagă tehnologiile Web
amintite 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 urma
unui 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ările
aplicaţiei sunt pagini diferite din punct de vede al operaţiilor Back/Forward şi Add
Bookmark/Favorites);
o Fiecare pagină generată dinamică implică un refresh complet al paginii curente, de
cele 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ând
noua 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ării
intermitente cu serverul care suspendă utilizarea, ci şi datorită gamei reduse de
evenimente 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ând
declanşa transferuri HTTP oricând, cu sau fără notificarea utilizatorului; răspunsul se
returnează de la server în format text, fie brut, fie structurat (XML, JSON), pentru a
fi prelucrat prin funcţii JavaScript;
o Starea iniţială a aplicaţiei e determinată de transferul dinspre server a întregului
modul client, cu toate stările sale posibile (deci are loc un transfer iniţial masiv care e
totuşi suportat de calculatoarele moderne şi nu necesită instalare, toate interpretoarele
necesare fiind încorporate în browser);
o Fiecare stare a aplicaţiei e obţinută prin modificarea la nivel de client a structurii
interfeţ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ă, deci
mecanismele 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şa
cum face refreshul de pagină) – interfaţa continuă să funcţioneze în acele stări care
nu 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 la
care 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 o
anumită zonă a paginii – care nu trebuie să fie neapărat un buton sau o imagine, deci
schimbul 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 descris
anterior, un semn de carte va marcha doar aplicaţia AJAX în ansamblul său, nu poate marca
diferite 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 a
tehnologiilor componente (HTML, JavaScript,XHR, CSS); în acest sens recomandăm studiul
site-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 a
browserului clientului); o parte din aspectele cross-browser sensibile vor fi detaliate în
materialul de faţă;
Formularele AJAX nu pot realiza nativ încărcare de fişiere pe server (prin câmpuri de tip
FILE în formulare) - aceasta se datorează faptului că JavaScript, din raţiuni de securitate, nu
are 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 pe
cadrele invizibile. Vom atrage atenţia asupra soluţiilor existente în materialul de faţă, la momentul
potrivit.
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 modificarea
dinamică a conţinutului marcatorului (se poate considera că, în mod implicit, mesajul de eroare este
vid). Rolul atributului id este de a identifica în mod unic paragraful respectiv, pentru a fi ulterior
accesat de JavaScript. În 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 la
evenimentul 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 intermediul
obiectului 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 Internet
Explorer vom reveni ulterior cu metoda de instanţiere necesară), care defineşte o conexiune la
script.php transferând ca variabilă GET codul poştal. Funcţia send() este responsabilă cu trimiterea de
date prin metoda POST la server17
şi cu crearea unei stări de aşteptare pentru client (aşteptarea
ră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 de
aş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şi
folder cu pagina HTML client), apelat anterior de obiectul XHR:
<?php if ($_GET["CodPostal"]==400451) print "Cluj Napoca,Cluj, Aleea Azuga...(completati detaliile)"; else print "cod incorect, cod incorect, cod incorect"; ?>
Aşadar, scriptul recepţionează variabila GET CodPostal, care conţine chiar valoarea tastată în
câmpul TXcodpostal. Dacă valoarea acestei variabile este chiar cea aşteptată (400451), scriptul
returnează 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 nu
va fi comparată cu 400451, ci va fi căutată în baza de date a codurilor poştale apoi, instrucţiunea print
va 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.responseText var datevect=datestring.split(',') document.getElementById("TXoras").value=datevect[0] document.getElementById("TXjudet").value=datevect[1]
document.getElementById("TXadresa").value=datevect[2] }
Reamintim că răspunsul primit de la server are forma unui şir de valori text delimitate de
virgulă, chiar şi în condiţii de eroare (cod poştal incorect). Din acest şir se extrag datele într-un vector
cu 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ă a
clientului). 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âmpului
respectiv, deci în urma celor trei atribuiri, cele trei câmpuri vor fi completate cu datele obţinute de la
server.
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 asupra
că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 implementa
comunicarea asincronă, cererea şi răspunsul serverului sunt procesate pe fire de execuţie diferite.
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 modelului
AJAX - faptul că execuţia codului nu se întrerupe între formularea cererii XHR şi receptarea
ră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ă la
obţinerea unui răspuns de la server. În paralel, orice alte instrucţiuni care ar apare după xhr.send (sau în
alte funcţii decât date()) vor fi executate atâta timp cât nu depind de răspunsul serverului. Toate
operaţ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 complet
disponibile clientului. În acest scop, funcţia de procesare a datelor trebuie să verifice dacă s-a ajuns în
starea 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ă procesarea
imediată 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ă între
ultimele două linii de cod până la receptarea completă a răspunsului şi avantajul esenţial al modelului
AJAX dispare. De fapt, în aceste condiţii nici nu se mai poate folosi acronimul AJAX, fiind vorba doar
de o formă evoluată a modelului Dynamic HTML (care permitea încă din anii 90 accesarea structurii
documentului HTML prin JavaScript şi CSS). Întreruperea 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 datele
necesare se află în memorii diferite (a clientului şi a serverului) şi devin foarte frecvente apelurile de tip
RPC (apel de proceduri la distanţă – când apelul de procedură şi execuţia procedurii au loc pe
calculatoare diferite). Chiar dacă în multe cazuri latenţa de reţea e insesizabilă (mai ales că în AJAX
care nu face refresh de pagină integrală ci transferă doar un set redus de date), aceasta afectează
întotdeauna 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 faţă e posibil ca o întârziere excesivă să îl facă pe
utilizator să tasteze oraşul şi judeţul fără să mai aştepte completarea lor automată. Apoi, la sosirea
acestora 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 la
server (aplicaţia nu îngheaţă).
Una din problemele spinoase ale modelului AJAX este compatibilitatea cu browsere diferite
sau 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 tipuri
de browsere:
function createXHR() { var x
try { x=new ActiveXObject("Msxml2.XMLHTTP") }catch (e) { try { x=new ActiveXObject("Microsoft.XMLHTTP") }catch (e) {x=false} } if (!x&&typeof XMLHttpRequest!='undefined') {x=new XMLHttpRequest()} return x; }
Această funcţie implementează trei tipuri alternative de instanţiere XHR, disponibile pe
diferite 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 a
obiectului 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 eroare
HTTP tradiţională – XHR foloseşte HTTP şi recepţionează codurile de diagnosticare clasice (404 în
caz 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 p roces are( ) { i f ( xh r . readyState == 4 ) { i f ( xh r .s ta tus == 200) { va r dates t r ing=xhr . respons eText va r datevec t=dates t r ing.sp l i t ( ' , ' ) document .ge tE 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 .getElementB yI d("Eroare") . innerHTML="" } e lse document .ge tElementB yId ("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, se
generează 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 innerHTML
poate fi oricât de complex).
Notă: Insistăm asupra ideii ca pachetul Firebug să fie instalat în
Firefox încă de la primele exemple testate. În timpul execuţiei
scripturilor, consola Firebug afişează datele care se schimbă între
client şi server, ceea ce oferă un ajutor semnificativ în localizarea
erorilor care pot să apară la tastarea codului sursă. Struc tura datelor
schimbate între client şi server poate indica dacă o eventuală eroare
apare în modulul client sau în scriptul server. Imaginea de mai jos
afişează datele schimbate prin metoda GET, în cele trei rubrici ale
consolei:
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 limbajul
a avut dintotdeauna o reputaţie proastă, datorită lipsei tipizării datelor, a naturii dezorganizate a codului
Clic pe adresa scriptului server
pentru afişarea datelor transferate
Butonul de deschidere
a consolei Firebug
36
sursă integrat cu HTML şi a implementărilor inconsistente în diverse browsere. AJAX a revigorat
semnificativ 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 se
atribuie. Erorile de tip type mismatch sunt în general evitate prin mecanismul de conversie implicită a
datelor din expresii. Aceasta poate fi un avantaj (comoditatea) dar şi un dezavantaj – detectarea erorilor
devine mai dificilă.
Limbajele puternic tipizate atrag atenţia asupra erorilor de tip. De exemplu tastarea greşită a
numelui 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 cu
instrucţ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 a
numelui).
Mecanismul conversiei implicite din expresii e exemplificat de atribuirea:
a=2 b="a" c=a+b
Un limbaj tipizat generează o eroare type mismatch datorită tentativei de adunare între o
variabilă numerică şi o variabilă string. În JavaScript, rezultatul va fi "2a", numărul 2 fiind convertit
automat 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 poate
face dificilă detectarea unor erori de tip (conversii implicite neintenţionate). Tipurile datelor cu care
lucrează 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 sunt
funcţii obişnuite care preiau argumente şi le oferă proprietăţilor obiectului this:
function Obiect(arg1,arg2,...)
{ this.proprietate1=arg1 this.proprietate2=arg2 ..... return this }
a=Obiect(valoare1,valoare2) alert("prima proprietate a obiectului are valoarea:"+a.proprietate1) a.proprietatenoua=valoarenoua alert("obiectul a primit o noua proprietate!")
Funcţiile JavaScript sunt similare cu alte limbaje (se declară prin cuvântul cheie function, pot
avea 0 sau mai mulţi parametri, returnează o valoare la apelul acestora). Datorită lipsei tipizării, spre
deosebire de C sau Java, nici la funcţii nu se declară tipul valorii returnate înaintea cuvântului cheie
function. Aşadar, o funcţie va putea returna alternativ (pe diferite ramuri de execuţie), valori de diferite
tipuri (inclusiv nici o valoare, adică valoare de tip undefined).
O altă diferenţă faţă de limbajele obiectuale clasice este faptul că JavaScript nu suportă
supradefinirea (polimorfismul) 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ţiei
ce trebuie executată la un apel se face atât prin nume cât şi prin argumente). In JavaScript, a doua
definire 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şarea
variabilei 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 între
variabila f şi funcţia f(). În JavaScript se obţine o eroare, deoarece pe ultima linie, f nu mai este o
funcţ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 orice
alt tip. Exemplul următor creează o astfel de variabilă de tip function (pointer spre o definiţie de
funcţ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ţie
5 (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 vizibilitatea
variabilelor locale din funcţii. În majoritatea limbajelor, exemplul următor va provoca o eroare:
function f()
{ local=2 x=local/2 return x }
a=f() b=local alert(b)
Majoritatea programatorilor se aşteaptă ca ultima linie de cod să provoace o eroare de
vizibilitate a variabilei local. În mod normal, o variabilă creată într-o funcţie este accesibilă doar în
interiorul acelei funcţii şi se distruge după execuţia funcţiei. În JavaScript în schimb, variabilele locale
ale 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 de
declaraţia sa. Deci următorul exemplu va provoca eroare de vizibilitate chiar şi în JavaScript (lipseşte
apelul care creează închiderea):
function f() { local=2 x=local/2
return x }
b=local alert(b)
38
Închiderile sunt un aspect problematic, văzut adesea ca un pericol de securitate şi de depăşire
de memorie în schimb programatorii avansaţi văd în aceasta o oportunitate, un nou mod de a gândi
codul sursă al algoritmului – de exemplu, o funcţie poate avea acces la valorile variabilelor locale ale
altei 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=2 functielocala=function () {
b=a+a return 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âne
accesibilă (datorită închiderii) chiar şi în blocul funcţiei f3(). Aşadar o funcţie poate încapsula
mai 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=2 functielocala=function () {
b=a+a return 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 rezultatul
acestui bloc, deci valoarea 4. Acest exemplu e elocvent pentru a diferenţia cazurile în care e
vorba 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 în
marcatorul SCRIPT sau prin încadrarea scripturilor direct în valorile unor atribute HTML. Exemple:
<script type="text/javascript"> function functie() {alert("mesaj")} </script> <input type=button onclick="functie()" >
este echivalent cu:
<input type=button onclick="alert('mesaj')" >
18
Există şi lmbaje de programare ce permit, prin sintaxe diferite, atât creare de funcţii cât şi
creare 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 care
acestea apar în codul sursă, până la final sau până la întâlnirea unei erori. Legarea cu pagina HTML se
realizează de obicei prin intermediul evenimentelor - declanşarea unui eveniment pe suprafaţa
documentului 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ă un
mesaj. 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, este
recunoscut azi de toate browserele).
2.2.2. XML şi DOM
XML este o paradigmă, un model pentru limbajele ce folosesc marcatori. Rolul modelului
XML este să garanteze o structură internă arborescentă pentru documente. Structura arborescentă este
garantată prin impunerea 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 în
altul, 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 cum
posibilitatea 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 Web
la 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 de
compatibilizare 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 face
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 pot
exista doi marcatori cu aceeaşi valoare ID;
atributele XHTML au obligatoriu valorile cuprinse între ghilimele (în timp ce HTML permite
construcţii cu atribute fără ghilimele sau prescurtate precum <INPUT TYPE=CHECKBOX
CHECKED>, XHTML permite doar <input type="checkbox" checked="checked"/>);
codul sursă trebuie să înceapă cu un antet de instrucţiuni care să confirme că documentul este
de tip XML:
<?xml ?> <!DOCTYPE ...> <html> ...... </html>
19
În continuare vom utiliza forma XML pentru marcatorii cu etichetă unică
40
Instrucţiunea xml indică faptul că documentul respectă regulile XML. Instrucţiunea
DOCTYPE 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 în
memoria internă a clientului sub forma unui arbore cu noduri - fiecare nod corespunzând unui
marcator, cu un nod rădăcină unic şi cu nodurile-frunte corespunzând conţinutului textual al
marcatorilor:
<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ţine
nodurile subordonate). Modificând prin DOM arborele paginii, practic se manipulează structura
documentului – orice porţiune de document va putea fi mutată, ştearsă, modificată, se pot crea porţiuni
noi în document (adăugând noduri noi în arbore). Porţiunile documentului sunt identificate cu ajutorul
marcatorului care le încadrează (şi a atributului id pe care acesta îl are). Modelul arborescent al paginii
mai poartă şi denumirea de model DOM sau arbore DOM (preferabil faţă de denumirea mai generală
de "arbore XML"). Toate componentele arborelui sunt subordonate obiectului ce reprezintă pagina în
ansamblu (deci conţine întregul arbore) – e vorba de obiectul document. Acesta conţine obiecte de tip
element (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 de
evenimente. 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 limbaj
XML în măsura în care asigură un mecanism de interpretare a instrucţiunilor acestuia. În cazul
XHTML, semnificaţia instrucţiunilor este cea oferită de HTML. 21
În special vom neglija pentru simplificare antetul XHTML, dar se vor putea remarca şi alte
abateri care nu afectează funcţionarea exemplelor în principalele browsere – Internet Explorer 7 şi
Firefox 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 va
mai fi nevoit să ştie cum se numeşte funcţia handler de care are nevoie (programatorul va trebui oricum
să ştie cum se identifică elementele paginii). Dezavantajul metodei este că marcatorul SCRIPT nu mai
poate apare în HEAD, codul JavaScript trebuind să apară după definirea elementului cu atributul ID,
altfel funcţia getElementById nu va detecta nimic. Acest dezavantaj poate fi îndepărtat prin ascultarea
de 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.documentElement var vector = v1.childNodes var nodbody for (i = 0; i < vector.length; i++)
if (vector[i].nodeName == "BODY") { nodbody = vector[i] break; }
vector = nodbody.childNodes var noddiv for (i = 0; i < vector.length; i++)
if (vector[i].nodeName == "DIV") { noddiv = vector[i] break; }
var nodtext=document.createTextNode("Text nou") noddiv.replaceChild(nodtext, noddiv.childNodes[0]) noddiv.setAttribute("align","right") }
</script> </head> <body> <div>Text vechi</div> <button onclick="modificaPagina()">Apasa pentru modificare text</button> </body> </html>
În acest exemplu, conţinutul vizibil al paginii este un buton care reacţionează la clic şi un text
marcat cu marcatorul div. Efectul clic-ului pe buton este înlocuirea textului cu un alt text şi modificarea
formatului (alinierea la dreapta a textului).
Spre deosebire de majoritatea marcatorilor HTML care au rol de formatare sau definire a unor
componente de pagină, există doi marcatori cu rol strict de delimitare: div şi span. Rolul lor este să
delimiteze 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 div
sau 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 un
efect 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ţie
dar, 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 de
structură – se folosesc pentru a împărţi documentul în unităţi structurale care să devină în memoria
internă noduri ale arborelui DOM (deci vor putea fi accesate direct şi manipulate independent unele de
altele).
Structurarea documentului are un rol important şi în ce priveşte formatarea prin stiluri CSS.
Fiecare bloc div sau span poate fi asociat unui stil CSS pentru a fi formatat (atributul class). Apoi, prin
intermediul JavaScript, asocierea div-CSS sau span-CSS poate fi modificată pentru a modifica în mod
dinamic formatul paginii. Pentru a î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 bloc span sunt asociate unor stiluri CSS ce le
formatează fundalul:
<html> <head> <style type=text/css> .S1 {background:red} .S2 {background:blue} </style> </head> <body> Text oarecare care 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 a
sugera că un bloc div sau span se poate întinde pe mai multe rânduri şi poate conţine orice combinaţii
de marcatori permise de regulile de sintaxă XML. Culoarea fundalului indică porţiunea de document
afectată 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 HTML
clasice, documentul arată ca un text marcat cu marcatori de formatare - H1 pentru titluri, P pentru
paragrafe, FONT pentru aplicare de font etc. În paginile HTML AJAX, documentul e o colecţie de
blocuri div (şi mai rar span) însoţite de stilurile CSS care le definesc formatarea şi atributele id
necesare 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 4
nivele pot fi gestionate de persoane diferite, cu un minim de interferenţă între acestea iar depanarea
aplicaţ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 textual
este î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 considerat
nod 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 de
informaţ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 în
modificarea 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ţă de
exemplul 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. În
exemplul actual, zona ce s-a dorit a fi manipulată s-a definit ca un bloc div – avantajul fiind că acesta
poate încadra o porţiune oricât de complexă şi nu interferează cu formatul documentului (P defineşte
un 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 atribut 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 fiii
nodului BODY, primul fiu cu numele DIV. Aceasta implică două cicluri de parcurgere şi reprezintă un
dezavantaj, 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 convertesc
caracterele albe în noduri de tip text. Mai exact, marcatorul body din exemplul de mai jos va avea trei
noduri fiu şi nu unul, cum ar dicta 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 tip
element (marcatorul b) şi un al doilea nod de tip text (Enterul de după închiderea lui b) – generarea
acestor noduri poate fi verificată cu instrumente DOM Inspector. 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 în
noduri 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 exemplu
similar este faptul că prin conversie la XML, unele browsere adaugă în mod forţat marcatori noi: de
exemplu e posibil ca în cadrul unui tabel să se adauge forţat marcatorii thead şi tbody (antet şi corp de
tabel, o separare neglijată de mulţi designeri HTML care se rezumă la a descrie rândurile tabelului prin
tr)!
Dacă parcurgerea arborelui DOM se face pe bază de poziţie (de exemplu parcurgerea
vectorului childNodes sau cu nextSibling) este posibil ca numărul nodurilor fiu să nu fie exact cel la
care se aşteaptă programatorul, problema fiind agravată de faptul că nu toate browserele aplică acelaşi
tratament 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 acest
caz este că e posibil ca documentul să conţină mai mulţi marcatori similari (mai multe paragrafe, mai
multe 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 parcurgerii
vectorului childNodes, ci avem efectiv un vector cu toţi marcatorii cu aceeaşi etichetă, în ordinea
apariţiei lor în document. Desigur, rămâne incomodă necesitatea de a cunoaşte poziţia marcatorului
căutat. În unele situaţii, în care se doreşte manipularea simultană a tuturor marcatorilor cu aceeaşi
etichetă, getElementsByTagName devine soluţia ideală (spre exemplu, dacă se doreşte manipularea
identică a tuturor câmpurilor unui formular, a tuturor paragrafelor sau blocurilor div dintr-un
document). Mai mult, getElementsByTagName devine necesară atunci când getElementById nu se
poate folosi (exemplu: 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 formatul
său sunt create cu ajutorul proprietăţii innerHTML a marcatorului localizat (al paragrafului). În
exemplul 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). Proprietatea
innerHTML 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 nod
modificat/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>" nu
a avut ca efect doar inserarea de text, ci chiar crearea unui nod-element nou, la rândul său cu
propriul 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 de
conţ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 şi
outerHTML, putem spune că outerHTML conferă o putere mai mare serverului în a
restructura pagina, în timp ce innerHTML conferă responsabilitatea structurii clientului,
serverul manipulând doar conţinutul.
La enumerarea proprietăţilor DOM, am sugerat şi alte căi de a accesa şi manipula conţinutul
marcatorilor.
4.Manipularea de atribute
Exemplul cu codul poştal accesează şi modifică atributul value al marcatorilor input prin
calificarea proprietăţii value:
document.getElementsById("idcamp").value="valoarea noua a campului"
Al doilea exemplu accesează şi modifică (creează) atributul align al blocului div prin metoda
setAttribute:
noddiv.setAttribute("align","right")
Metoda setAttribute este înrudită cu getAttribute, care citeşte valoarea unui atribut.
În consecinţă exemplul actual poate fi scris într-o formă mai comodă astfel:
<html> <head> <script type="text/javascript"> function modificaPagina()
{ var noddiv=document.getElementById("bloc1") noddiv.innerHTML="Text nou" noddiv.align="right" }
</script> </head> <body> <div id=bloc1>Text vechi</div> <button onclick="modificaPagina()">Apasa pentru modificare text</button> </body> </html>
Ambele variante de acces la atribute sunt acceptabile pentru majoritatea atributelor deoarece,
în general, pentru fiecare atribut al unui marcator din pagină se generează în DOM o proprietate a
obiectului (nodului) corespunzător marcatorului. Această afirmaţie are un caracter general, dar nu unul
absolut – există cazuri în care numele atributului nu este acelaşi cu numele proprietăţii. În general la
acest capitol apar diferenţe supărătoare între browsere. Probabil cele mai importante excepţii sunt
atributele 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, prin
aceea că asocierea div-stil1 e înlocuită cu asocierea div-stil2 (diferenţa între cele două stiluri e culoarea
de fundal, după cum arată descrierile de stil din antetul paginii). Acesta e mecanismul de bază prin care
paginile AJAX capătă dinamică din punct de vedere vizual – modificarea atributelor class pot avea
efecte majore asupra modului în care arată interfaţa iar legarea acestor modificări la evenimentele
utilizatorului 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 prin
cealaltă 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 specific
unuia din browsere: noddiv.setAttribute(document.all?"className":"class","stil2")
(obiectul document.all e un un obiect care există doar în Internet Explorer; dacă valoarea sa e
true, se 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 unui
obiect-element în ambele browsere, în timp ce class există ca proprietate doar în Firefox, iar className
există ca atribut doar în IE.
O problemă similară apare la folosirea celuilalt atribut de aplicare a stilurilor CSS, style – prin
care stilul se descrie direct în marcator şi nu se apelează din antetul paginii. Pentru style, metoda care
funcţ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 CSS23
. 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 controlul
vizibilităţii unor porţiuni de document (de obicei blocuri div). Aceasta se obţine printr-o funcţie care
comută 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 dintre
browsere î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 şi
faptului că acesta e disponibil în două variante:
XML DOM, modelul fundamental, ce poate fi folosit pe orice tip de cod XML (inclusiv codul
XHTML al paginii AJAX); acesta oferă metodele de parcurgere a arborelui din nod în nod
(childNodes, nextSibling, parentNode etc.) şi cele de extragere a datelor
(nodeValue,setAttribute,getAttribute etc.); funcţiile XML DOM pot fi utilizate atât asupra
arborelui paginii cât şi asupra altor arbori XML (date primite prin proprietatea responseXML).
Modelul XML DOM este suportat de majoritatea limbajelor de programare ce permit
prelucrare de cod XML;
HTML DOM, o versiune DOM optimizată pentru paginile XHTML, ce oferă, în plus faţă de
XML DOM, versiuni prescurtate sau metode mai directe decât cele generale; funcţiile HTML
DOM pot fi folosite asupra arborelui paginii AJAX, dar nu pot fi folosite asupra altor arbori
XML, cum ar fi răspunsul serverului în format XML (proprietatea responseXML a obiectului
XHR).
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 nodeValue
sau metodele de acces la fiii nodului curent (replaceChild, appendChild etc.);
obiectul document este proprietate a obiectului window, ce reprezintă fereastra browserului şi
oferă acces la funcţionalitatea browserului (istoricul paginilor vizitate, butoanele Back şi
Forward, 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 problema
atributului class e ocolită).
48
o document.links[ ] – un vector cu toate hiperlegăturile şi hărţile de imagini (marcatorii
area) ale paginii;
o document.form[0].elements[ ] – un vector cu toate elementele din primul formular al
paginii (getElementsByTagName("form")[0].childNodes[] în XML DOM, cu
evitarea "nodurilor albe");
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ă la
adresa: http://www.w3schools.com/HTMLDOM/dom_reference.asp
La aceste diferenţe adăugăm o excepţie deosebită: getElementById poate fi folosită doar în
arborele 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 lista
marcatorilor 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şte
atributul 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 un
document XML este comparat cu regulile unui vocabular este similară cu cea prin care un document
HTML este interpretat conform sintaxei HTML şi poartă numele de validare.
Validarea HTML (faţă de vocabularul XHTML) este integrată implicit în browsere dar nu şi
validarea de cod XML generic (faţă de diverse vocabulare). 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 ce
face ca getElementById să nu funcţioneze pe răspunsul obiectului XHR!
Notă: getElementById funcţionează în alte medii de programare, ce
includ validare şi gestiunea vocabularelor XML. În general
validatoarele XML sunt instrumente off-line - o validare aplicată la
fiecare transfer XHR ar afecta grav performanţa aplicaţiei (ar
presupune un dublu transfer – al datelor XML şi al vocabularului faţă
de care se validează, la care se adaugă efortul de validare). Extensia
Firefox numită XML Developer Toolbar oferă instrumente de validare în
browser şi poate fi descărcată gratuit de pe site -ul oficial al
browserului. Acestea sunt însă validatoare off -line, inaccesibile
obiectului XHR.
2.2.4. Obiectul XHR
Detaliile legate de mecanismul de transfer al datelor între clientul AJAX şi server vor fi
discutate pe un exemplu simplificat din cele anterioare:
<html> <head> <script type="text/javascript"> var xhr function modifica()
{ try
{ xhr = new ActiveXObject("Msxml2.XMLHTTP") } catch (e)
{ try
{ xhr = new ActiveXObject("Microsoft.XMLHTTP") } catch (e)
{ xhr = false
} }
if (!xhr && typeof XMLHttpRequest !="undefined")
{
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 de
la 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 variabile
POST); în exemplul de faţă open nu trimite nici o variabilă, send trimite caracterul null, aşadar tot ce se
transmite 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 script
simplu care generează un şir de caractere:
<?php print "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 manipulare
DOM;
în ultimii ani, adepţii AJAX au promovat şi un al treilea format de date, JSON, care se preia
din 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ăţii
structurilor 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 date
responseXML. Răspunsul serverului va fi prelucrat obligatoriu prin XML
DOM, metodele HTML DOM returnând erori. În paragraful XML DOM vs. HTML
DOM 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), momentul
la care are loc citirea lui responseText este declanşarea evenimentului readystatechange cu
readyState=4
6. Reacţia paginii HTML la datele serverului
- blocul div anterior definit în pagină ca o zonă vidă a documentului e completat cu datele
serverului; acest proces e declanşat de evenimentul click pe butonul paginii.
În plus faţă de acest mecanism de bază obiectul XHR poate trimite şi recepta date direct prin
antetul HTTP (care în mod normal e construit de către protocol, atât în browser cât şi la server, pentru
a 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 php
destinatar încât să returneze valoarea câmpului User-Agent din antetul HTTP:
<?php
print $_SERVER["HTTP_USER_AGENT"]; ?>
În urma modificărilor, exemplul anterior va afişa în blocul div textul "Browserul meu!" la
apăsarea butonului. Dacă ştergem apelul metodei setRequestHeader, textul afişat în blocul div va fi
identitatea browserului.
Notă: Pentru lista câmpurilor antetului HTTP, recomandăm consultarea
adresei http://www.w3.org/Protocols/rfc2616/rfc2616 -sec14.html. De
asemenea, o multitudine de instrumente de tip HTTP Header Vi ewer sunt
disponibile pentru descărcare gratuită, pentru a permite vizualizarea
antetului HTTP direct în browser. Exemple de astfel de instrumente sunt
Tamper Data – extensie add-on instalabilă de pe site-ul oficial Mozilla
Firefox sau HTTP Watch (www.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ă ca
utilizatorul 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 o
hiperlegătură. Obiectul XHR permite, după cum s-a văzut, ca schimbul de date să aibă loc la orice
moment î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 prin
apă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 de
trimitere a datelor vor fi:
formularul nu va mai avea un buton submit, ci un buton oarecare de tip button, căruia i se va
asocia funcţia de trimitere a datelor ca handler onclick; folosirea unui buton submit ar realiza
un 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 obiectul
XHR;
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 formular şi ar putea
induce 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 are
nevoie 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").value
valori["codpostal"]=document.getElementById("TXcodpostal").value valori["adresa"]=document.getElementById("TXadresa").value valori["oras"]=document.getElementById("TXoras").value valori["judet"]=document.getElementById("TXjudet").value sir="" for (cheie in valori) { sir=sir+cheie+"="+encodeURIComponent(valori[cheie])+"&"
} xhr.open("POST","script.php") xhr.setRequestHeader ("Content-Type", "application/x-www-form-urlencoded") xhr.onreadystatechange=procesare xhr.send(sir) }
function procesare() {
if (xhr.readyState!=4) return alert("serverul a raspuns cu:"+xhr.responseText) .................//procesarea raspunsului serverului }
</script> </head>
<body> <h1>Introduceti datele</h1> <form> <table> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal></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>
52
<td>Judet</td> <td><input type=text id=TXjudet ></td> </tr> <tr> <td></td> <td><input type=button value=Trimite onclick="trimite()" ></td> </tr> </table> </form> </body> </html>
Scriptul server:
<?php print "datele primite la server sunt:".$_POST["nume"].
",".$_POST["codpostal"].",".$_POST["adresa"].",".$_POST["oras"].",".$_POST["judet"]; ?> Notă: Avertizăm că în timpul testării metodei POST, consola Firebug nu
afişează o eroare atunci când scriptul server nu primeşte variabilele
POST aşteptate (de exemplu pentru că s-a tastat greşit numele lor). În
schimb, rubrica Response din Firebug afişează mesajul "Loading..." care
semnifică 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ând
obiectul XHR nu este instalat în browser24
. Cadrele interne s-au folosit frecvent înainte apariţiei
obiectului XHR pentru a schimba date cu serverul şi sunt chiar şi în prezent preferate de unii
dezvoltatori 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ă cele
interne nu se definesc prin împărţirea ferestrei browserului pe orizontală sau verticală (cu
FRAMESET), ci prin definirea unei suprafeţe dreptunghiulare în interiorul paginii (cu
IFRAME). 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 date
invizibil utilizatorului. Acest set de date poate fi apoi accesat prin JavaScript, din proprietăţile
cadrului intern;
Împrospătarea conţinutului unui cadru, fie şi unul invizibil, generează un sunet în unele
browsere 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ă (cu
head, body etc.). Chiar dacă pagina respectivă este doar un şir de caractere cu datele
serverului, acesta se accesează prin proprietatea innerHTML a marcatorului BODY al paginii
conţinute în cadru;
Un cadru intern poate stoca doar şiruri de caractere interpretabile ca HTML. Cadrul intern nu
aplică 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 arbore
DOM se realizează în JavaScript prin două metode, ce vor trebui incluse într-o structură try-
catch:
arbore=new document.implementation.createDocument() – pentru Firefox
arbore=new ActiveX("Microsoft.XMLDOM") – pentru Internet Explorer
arbore.load(raspuns) – variabilei raspuns in prealabil i-a fost atribuit conţinutul cadrului
Notă: În timpul depanărilor în Firefox cu extensia Firebug, opţiunea
Console nu mai poate fi folosită pentru monitorizarea schimburilor
între client şi server (aceasta monitorizează doar cererile XHR). În
schimb, 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 cu
obiectele ActiveX dezactivate.
53
client-server indiferent de calea pe care sunt realizate, inclusiv prin
cadre.
Cadrele interne invizibile au şi un alt rol, deosebit de important, pe care obiectul XHR nu îl
poate îndeplini. Cu ajutorul cadrelor se pot depăşi limitările AJAX cu privire la upload-ul de fişiere şi
mecanismul Back/Forward al browserului.
Modelul AJAX implementat prin cadre invizibile diferă categoric de modelul bazat pe XHR.
Unii autori consideră că folosirea cadrelor invizibile nu ar trebui încadrată în modelul AJAX, fiind mai
degrabă o simulare a sa. 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 de
utilizare);
JavaScript, ca limbaj de programare;
XML – poate să se refere la obiectul XHR (proprietatea responseXML), dar poate să se refere
şi la faptul că pagina HTML e tratată de JavaScript ca arbore XML (DOM).
Cadrele interne respectă toate aceste 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ărcare
de pagină. Acest al doilea cadru poate fi folosit pentru a schimba date cu serverul, în timp ce utilizarea
aplicaţ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.document raspuns=documentcadru.body.innerHTML procesare(raspuns) } function procesare(rasp)
{ vector=rasp.split(",") document.getElementById("TXoras").value=vector[0] document.getElementById("TXjudet").value=vector[1] document.getElementById("TXadresa").value=vector[2]
} </script>
</head> <body> <iframe id=cadruint width=400 height=50 src="" onload="citestedate(this)">
</iframe> <h1>Introduceti datele</h1>
<form > <table> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal onblur="trimite(this.value)"></td> </tr> <tr> <td>Adresa</td>
54
<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> </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ăspunsul
serverului. După ce exemplul se dovedeşte funcţional, dimensiunile cadrului se pot modifica
la valoarea 0 pentru a obţine un cadru invizibil, ce nu interferează cu experienţa utilizării
aplicaţ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 varianta
XHR). Teoretic, rolul cadrului este de a afişa pagina indicată de src. Practic, acea pagină poate
fi 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ăspuns
este chiar o pagină generată dinamic în scopul afişării. În AJAX, acest răspuns este un şir de
caractere care va fi ascuns atunci când cadrul devine invizibil. Scopul acestui şir de caractere
nu 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 au
sosit înainte să înceapă procesarea lor. În timpul receptării datelor, pagina principală poate fi
utilizată 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 cu
cadre, deoarece fiecare tip de browser folosea alte metode pentru a accesa conţinutul unui
cadru. În prezent se pot folosi două tehnici în acest scop:
o tehnica pull (extragerea datelor din cadru): conţinutul cadrului se accesează din
pagina 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 serverul
alimentează cadrul va conţine cod JavaScript care apelează funcţia de prelucrare a
răspunsului din pagina principală.
Modificarea prin DOM a atributului src al cadrului nu e singura metodă de a încărca date (sau
documente) î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 fi
un 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 trimise
spre 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 POST
sau 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. Modificarea dinamică a atributului src conferă
55
o dinamică superioară şi o subtilitate a schimburilor de date mai apropiată de cea promovată de
modelul AJAX.
Se poate remarca o oarecare simplitate comparativ cu metoda XHR. Totuşi, pentru a se
asigura compatibilitatea cross-browser, funcţia citestedate() devine mult mai complicată, pentru a
garanta 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 cu
instrumente şi componente de nivel înalt, uşor de integrat şi reutilizabile. Pe scurt, e vorba de
instrumente menite să accelereze procesul de producţie a unui site AJAX. Exemplele anterioare au
demonstrat nucleul oricărei aplicaţii AJAX – de la instanţierea prin tentative şi excepţii a obiectului
XHR 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 de
a crea semne de carte pentru stări diferite ale aplicaţiei. Această tendinţă a dus la apariţia unei
multitudini de "platforme" AJAX bazate pe pachete ce implementează diverse funcţionalităţi ale
modelului, 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 cu
CSS, manipulare cu JavaScript, conectare la server cu XHR) . Majoritatea platformelor AJAX sunt
construite pe nivelele:
Nivel 0: mecanisme de nivel scăzut, reutilizabil, de conectare asincronă la server: obiectul
XHR sau cadrele interne;
Nivel 1: instrumente de nivel înalt de comunicare cu serverul (ce maschează detaliile nivelului
0) – Dojo, JSON-RPC, Prototype, Direct Web Remoting;
Nivel 2: instrumente de nivel înalt de construire a interfeţei cu utilizatorul (construite peste
nivelul 1) – Dojo oferă instrumente şi la acest nivel, SmartClient, Script.aculo.us (bazat pe
Prototype);
Nivel 3: medii de dezvoltare a 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ţiere
XHR). Majoritatea instrumentelor de nivel 1 sunt create independent faţă de tehnologia folosită de
server. Unele, precum Direct Web Remoting, instalează şi o componentă Java pe server pentru
ascultarea şi gestionarea la un nivel mai înalt a cererilor HTTP prin XHR. Altele, precum JSON-RPC,
exploatează modelul ORB (Object Request Broker) pentru a permite accesarea obiectelor server direct
din scripturi client.
Instrumentele de nivel 2 sunt medii de generare a interfeţei cu utilizatorul – componente GUI,
cu funcţionalităţi, animaţii preprogramate şi chiar suport pentru operaţii desktop tradiţionale precum
drag-and-drop. Unele instrumente extind gama de componente GUI pentru a o apropia cât mai mult de
cea a interfeţei formularelor Windows sau Mac. Instrumente precum Backbase sunt de fapt limbaje de
marcare (limbaje XML) ce folosesc proprii marcatori, superiori celor din HTML, împreună cu funcţii
cu rol de interpretor.
Instrumentele de nivel 3 sunt medii de dezvoltare complexe bazate pe
generatoare de cod JavaScript (Ruby on Rails generează cod şi 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ţia
mediilor 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 parcurs
etapele:
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 Internet
Explorer.
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 limbajului
JavaScript 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ţie
sunt cele de tip open-source: Prototype (niv.1), Script.aculo.us (niv.2), Dojo (niv.1 şi 2) şi
Rails (niv.3).
2.3.2. Comunicarea cu serverul prin pachetul Dojo
Pachetul Dojo e rezultatul unui proiect open-source şi poate fi descărcat gratuit la
www.dojotoolkit.org. Pachetul include instrumente de nivel 1 şi 2 pentru facilitarea dezvoltării de
aplicaţ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 Dojo
Core pentru gestiunea comunicării cu serverul şi gestiunea evenimentelor (nivelul 1), biblioteca de
animaţii, efecte şi gestiune drag and drop Dijit (nivelul 2) şi biblioteca de extensii DojoX cu
instrumente diverse, experimentale şi extensibile, pentru ambele nivele.
În continuare reluăm exemplul cu formularul în care se completează automat oraşul, judeţul şi
strada 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 a try { a=new ActiveXObject("Msxml2.XMLHTTP") }catch (e) { try
{ a=new ActiveXObject("Microsoft.XMLHTTP") }catch (e) {a=false} } if (!a&&typeof XMLHttpRequest!='undefined') {a=new XMLHttpRequest()} return a; } function procesare() { if (xhr.readyState == 4) { if (xhr.status == 200) { var datestring=xhr.responseText var datevect=datestring.split(',') document.getElementById("TXoras").value=datevect[0] document.getElementById("TXjudet").value=datevect[1]
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=procesare xhr.open("GET","script.php?CodPostal="+cod) xhr.send(null) } </script> </head> <body> <h1>Introduceti datele</h1> <form> <table> <tr>
<td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td> <td><input type=text id=TXcodpostal onblur="date(this.value)"></td> </tr> <tr> <td>Adresa</td> <td><input type=text id=TXadresa size=50></td> </tr> <tr> <td>Oras</td> <td><input type=text id=TXoras ></td> </tr> <tr> <td>Judet</td> <td><input type=text id=TXjudet ></td> </tr> <tr> <td></td> <td><input type=submit value=Trimite ></td> </tr> </table> </form> <p id=Eroare></p> </body> </html>
Pentru convertirea paginii la platforma Dojo, pachetul trebuie 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 în
două 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 care
au fost testate toate exemplele. Avertizăm asupra faptului că modificările de la o versiune la alta pot fi
majore (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 consultarea
documentaţ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ând
răspunsul serverului (date sau mesaj de eroare26
), al doilea reprezentând o referinţă a obiectul Dojo ce
gestionează conexiunea cu serverul, pentru a permite acces la o serie de proprietăţi ale sale din
interiorul 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 ca
variabile 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 o
referinţă 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ăspunsul
serverului poate avea forma:
date=obiectDojo.xhr.responseText
În continuare oferim şi un exemplu de transfer a datelor prin metoda POST:
<head> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { document.getElementById("confirmare").innerHTML=raspuns } function proceroare(raspuns,obiectDojo) { document.getElementById("confirmare").innerHTML=
"<font color=red>Eroare de conectare la server!</font>"+raspuns } function date() { dojo.xhrPost ({ url: "script.php", handleAs:"text",
load: procesare, error: proceroare, form: "formular" }) } </script> </head> <body> <h1>Introduceti datele</h1> <form id=formular method=get action=scriptoarecare.php> <table> <tr> <td>Nume</td> <td><input type=text id=TXnume name=nume></td>
</tr> <tr>
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 şi
codul poştal. La evenimentul blur (părăsirea câmpului) pentru TXcodpostal, are loc un transfer spre
server a tuturor datelor formularului. Pentru verificare, modificăm scriptul PHP astfel încât să testeze
dacă au ajuns la server două variabile POST corespunzătoare celor două câmpuri:
<?php
print "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 în
cazul nostru, obiectul XHR realizează transferul la evenimentul blur, folosind un alt script
server şi o altă metodă decât cele declarate de formular (proprietatea url e preferată atributului
action, funcţia xhrPost e preferată atributului method!). Practic, după cum s-a observat şi în
exemplele 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) şi
atributul name (cu rol de generare a variabilelor POST). Se poate comenta faptul că e prima
dată când apelăm la atributul name. În exemplele anterioare, acestea nu au fost necesare
deoarece variabila GET CodPostal fusese construită pe altă cale: onblur="date(this.value)"
prelua valoarea câmpului şi o transmitea ca argument funcţiei, care o concatena la adresa
scriptului server, odată cu numele variabilei GET "script.php?CodPostal="+argument. Acest
mecanism de transmitere a variabilelor GET direct în adresa scriptului server e facil şi uzual
când nu se transmite un număr mare de date. Dacă dorim să transmitem întreg formularul prin
GET, singura modificare necesară la ultimul exemplu este înlocuirea lui xhrPost cu xhrGet
(care acceptă la 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 de
formular cu id=camp. Scriptul server care va confirma acest lucru are forma:
61
<?php
print "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, tipul
răspunsului e fixat prin argumentul handleAs. Mai mult, Dojo acceptă şi alte două formate puternice
drept răspuns: cod JavaScript pentru execuţie imediată sau date în format JSON (JavaScript Object
Notation).
Reluând exemplu cu completarea automată a formularului la introducerea codului poştal,
scriptul server ar putea arăta astfel:
<?php
if ($_GET["CodPostal"]==400451) print ' document.getElementById("TXoras").value="Cluj Napoca";
document.getElementById("TXjudet").value="Cluj"; document.getElementById("TXadresa").value="Aleea Azuga..." ' else print ' document.getElementById("TXoras").value="cod incorect";
document.getElementById("TXjudet").value="cod incorect"; document.getElementById("TXadresa").value="cod incorect" '
?>
Acum, scriptul PHP nu mai returnează date în format text, ci cod sursă JavaScript. Deoarece
codul returnat e un şir de caractere ce conţine multiple instrucţiuni, acestea au fost delimitate prin
punct-virgulă (caracter care e obligatoriu în JavaScript doar dacă mai multe instrucţiuni apar pe aceeaşi
linie – aşa cum e cazul şirului trimis de server). În aceste condiţii, funcţia dojo.xhrGet poate fi
configurată pentru a recepta datele în format JavaScript şi a le executa imediat, cu ajutorul
argumentului handleAs:
<head> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function proceroare(raspuns,obiectDojo)
{ document.getElementById("Eroare").innerHTML=
"<font color=red>Eroare de conectare la server!</font>"+raspuns } function date(cod) { dojo.xhrGet ({ url: "script.php?CodPostal="+cod, handleAs:"javascript", error: proceroare }) } </script> </head>
Se observă simplificarea majoră a codului sursă comparativ cu varianta iniţială şi un acces mai
direct din codul PHP direct asupra paginii HTML. Este important de remarcat faptul că argumentul
funcţ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 este
obligatoriu. 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 mult
simplificată faţă de XML. Atât XML cât şi JSON sunt, la bază, şiruri de caractere, diferă doar structura
internă a acestor şiruri. În timp ce XML impune ca datele să fie definite într-o structură de marcatori ce
respectă regulile de bună formare, JSON permite gruparea datelor în manieră obiectuală (seturi de
proprietăţi încapsulate pe mai multe nivele) – modelul JSON este inspirat chiar de modalitatea de
iniţ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, descrierea
CSS 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 fi
descrise prin JSON. Aceasta explică motivul pentru care funcţiile
handler sunt indicate doar prin numele lor, nu şi prin argumente:
obiect={url:....,handleAs:....,load: procesare ,error:proceroare}
în loc de
obiect={url:....,handleAs:....,load:procesare() ,error: proceroare() }
Explicaţia constă în faptul că la construirea unui obiect definit prin
sintaxă JSON fiecare proprietate a obiectului devine o variabilă care
primeş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ţia
va fi apelată şi executată chiar la construirea obiectului. Ori,
scopul unui handler e să fie executat doar la declanşarea
evenimentului asociat!
În schimb, dacă proprietatea primeşte valoarea funct ie, aceasta va deveni o variabilă de tip function ce va stoca blocul de exe cuţie
a funcţie şi nu valoarea sa!
Pentru clarificare, reamintim modul în care JavaScript diferenţiază o
funcţie de valoarea sa prin absenţa sau prezenţa argumentelor şi
parantezelor:
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) şi
va putea fi apelată cu b().
În concluzie, funcţiile handler din argumente de tip JSON nu vor putea
primi argumente explicite, ci doar pe cele implicite (raspunsul şi
obiectul Dojo).
În cele ce urmează vom realiza o comparaţie între formatele JSON şi XML aplicate asupra
datelor 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âte
două proprietăţi. Insistăm asupra faptului că valorile masive se enumeră între paranteze pătrate, 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 vector28
etc.). După unii autori, obiectul JSON nu este decât o variabilă masivă de tip asociativ (care foloseşte
nume 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 baza
imbrică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 atunci
câ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 conversie
facilă între şiruri de caractere JSON şi obiecte JavaScript;
accesul facil la proprietăţile JSON prin sintaxa JavaScript, comparativ cu accesul mai dificil la
XML prin DOM – în exemplul JSON, al doilea preţ poate fi accesat prin produse[1].pret, în
timp ce în exemplul XML ar fi necesară parcurgerea vectorilor getElementsByTagName sau
childNodes pentru nodul 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 reprezentarea
structurilor de date. Deşi creat pe baza modului în care JavaScript iniţializează variabile complexe,
JSON 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şi
renunţă 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 mai
folosesc 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 fiind
validate 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ă fixeze
nişte reguli stricte pentru structurile de date generate;
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-ul
http://json.org întreţine o listă la zi cu site-urile de la care pot fi procurate parsere JSON pentru diverse
limbaje de programare. Pentru JavaScript, parsingul se poate face în mod nativ – funcţia eval()
converteşte un şir de caractere într-o expresie sau un bloc de instrucţiuni JavaScript, aşadar prin
aplicarea 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 metode
complexe de manipulare a structurii JSON, dar acestea trebuie instalate şi invocate ca biblioteci de
funcţii JavaScript (vezi biblioteca http://json.org/json2.js). Conversia unui şir JSON în obiect se
realizează în JavaScript astfel:
obiect=eval('('+xhr.responseText+')') sau eval('obiect='+xhr.responseText)
Aceasta se realizează în mod nativ29
. Folosirea funcţiei eval ridică probleme de securitate
datorită faptului că argumentul funcţiei va fi evaluat şi executat chiar dacă este un bloc de instrucţiuni
JavaScript î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ă folosirea
parserelor 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ă se
asigure că e o structură JSON şi nu un cod sursă potenţial maliţios. Biblioteca json2, propusă de David
Crockford, 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ă şi
protocoale de transport JSON (JSON-RPC). Mai mult, comunitatea JSON a propus înlocuirea
obiectului XHR cu un obiect similar, JSONRequest, optimizat pentru transferuri JSON (la adresa
http://json.org există legături spre instrumente de acest gen, inclusiv o extensie add-on pentru Firefox
ce implementează obiectul JSONRequest). În contextul înlocuirii XML cu JSON ca format de transfer
al datelor structurate, susţinătorii JSON arată că până şi litera X din acronimul AJAX îşi pierde
semnificaţia. Deşi există o tendinţă de migrare a modelului AJAX spre structuri de date JSON, XML
ră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 ca
ră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 data
aceasta, 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 rotunde
anulează 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:
<?php if ($_GET["CodPostal"]==400451)
$date=array("oras"=>"Cluj Napoca","judet"=>"Cluj","adresa"=>"Aleea Azuga...(completati detaliile)");
else $date=array("oras"=>"cod incorect","judet"=>"cod incorect","adresa"=>"cod incorect");
print json_encode($date); ?>
Se observă utilizarea funcţiei json_encode(), care converteşte un vector asociativ (sau un
obiect 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 de
caractere JSON în obiect sau vector.
Notă: Mai multe detalii despre extensia JSON pentru PHP sunt
disponibile la http://www.php.net/manual/en/book.json.php. Informaţii
despre extensii JSON pentru alte limbaje (şi despre extensii JSON PHP
alternative celei instalate implicit) sunt disponibil e la site-ul
oficial JSON: http://json.org
Pagina AJAX va fi modificată pentru a accesa proprietăţile obiectului JSON primit de la
server (nu mai reproducem corpul paginii):
<head> <title>Formular</title> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) {
// se elimina linia - var vect=raspuns.split(',') – deoarece raspunsul nu mai e de tip text // ci de tip obiect
document.getElementById("TXoras").value=raspuns.oras document.getElementById("TXjudet").value=raspuns.judet document.getElementById("TXadresa").value=raspuns.adresa document.getElementById("Eroare").innerHTML="" } function proceroare(raspuns,obiectDojo)
{ document.getElementById("Eroare").innerHTML=
"<font color=red>Eroare"+raspuns+"</font>" } function date(cod) { dojo.xhrGet({ url: "script.php?CodPostal="+cod, handleAs:"json", load: procesare, error: proceroare }) } </script> </head>
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 caractere
simplu, deci putea fi returnat de server direct sub formă de string cu structura cerută de JSON. Am dorit
totuş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 orice
combinaţie de atribute, conţinut textual şi elemente imbricate. Din
raţ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 în
care 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 la
elemente imbricate şi conţinutul lor textual.
Datele pot fi returnate din PHP ca un şir de caractere cu structura indicată, sau împachetate în
obiect XML printr-un script ce exploatează 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 clasa
DOMDocument):
<?php header("Content-Type","text/xml") if ($_GET["CodPostal"]==400451) { $oras="Cluj Napoca"; $judet="Cluj"; $adresa="Aleea Azuga...completati detaliile"; } else { $oras="cod incorect"; $judet="cod incorect"; $adresa="cod incorect"; } $xml=new DOMDocument(); $radacina=$xml->createElement("detalii"); $fiu=$xml->createElement("oras"); $fiu=$radacina->appendChild($fiu); $continut=$xml->createTextNode($oras); $continut=$fiu->appendChild($continut);
$fiu=$xml->createElement("judet"); $fiu=$radacina->appendChild($fiu); $continut=$xml->createTextNode($judet); $continut=$fiu->appendchild($continut); $atribut=$radacina->setAttribute("adresa",$adresa); $radacina=$xml->appendChild($radacina); print $xml->saveXML(); ?>
La nivelul serverului se remarcă:
obligativitatea de a declara 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 de
ră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 prin
xhr.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 fi
returnat cu print.
În cazul receptării datelor în format XML reamintim faptul că obiectul XML primit de la
server e mai restrictiv decât modelul XML al paginii. Nu toate funcţiile DOM folosite la manipularea
paginii pot fi folosite la manipularea arborelui DOM al obiectului XML. Nu sunt posibile, printre
altele:
- getElementById (se va folosi getElementsByTagName sau navigare de arbore cu
childNodes, firstChild, lastChild etc.);
- calificarea atributelor în forma nod.id (se va folosi nod.getAttribute(), setAttribute());
- innerHTML sau outerHTML (se va folosi nodeValue şi 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 prin
atributele id (nu s-a mai trecut corpul paginii, nemodificat faţă de exemplele anterioare):
<head> <title>Formular</title> <script type="text/javascript" src="dojoroot/dojo/dojo.js"> </script> <script type="text/javascript"> function procesare(raspuns,obiectDojo) { oras=raspuns.getElementsByTagName("oras") document.getElementById("TXoras").value=oras[0].firstChild.nodeValue judet=raspuns.getElementsByTagName("judet") document.getElementById("TXjudet").value=judet[0].firstChild.nodeValue radacina=raspuns.documentElement document.getElementById("TXadresa").value=radacina.getAttribute("adresa") } function proceroare(raspuns,obiectDojo) { document.getElementById("Eroare").innerHTML=
"<font color=red>Eroare"+raspuns+"</font>" console.error("HTTP status code: ",obiectDojo.xhr.status)
// linia de mai sus nu e obligatorie: transmite codul de eroare al serverului spre
// consola Firebug în Mozilla Firefox } function date(cod) { date={CodPostal:cod} obiect={ url: "script.php", handleAs: "xml", load: procesare, error: proceroare, content: date } dojo.xhrGet(obiect) } </script> </head>
În exemplul de faţă se remarcă:
receptarea datelor de la server ca arbore DOM prin handleAs:"xml";
folosirea getElementsByTagName care, spre deosebire de getElementById, returnează un
vector – motiv pentru care se folosesc oras[0] şi judet[0] (cei doi vectori au 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 nu
există pericolul nodurilor cu "caractere albe" despre care am discutat la convertirea paginii
HTML în arbore DOM, aşadar childNodes şi proprietăţile aferente nu dau rezultate
imprevizibile; "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 forma 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. Pachetul
DOM Extension conţine clasa DOMDocument utilizată în acest exemplu şi e
specific versiunilor PHP mai noi de 5. Pentru versiunile PHP mai vechi
decât 5, se utilizează pachetul DOM XML32. Pachetul SimpleXML este o
alternativă 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 calificarea
părintelui (nodparinte->nodfiu), în loc să folosească metodele DOM
(nodparinte->firstChild->nodeValue). Deşi simplifică mult codul sursă,
SimpleXML are performanţe mai reduse decât DOM şi e folosit frecvent pe
pachete de date de dimensiuni reduse (arbori cu număr redus de nivele).
Recomandăm familiarizarea cu DOM mai degrabă decât cu SimpleXML
datorită 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 JSON
comparativ cu XML, fără să se piardă structura datelor. În ambele situaţii, proprietatea responseText
rămâne accesibilă şi conţine forma brută, de dinaintea operaţiei de parsing, a şirului de caractere primit
de la server.
Am sugerat anterior că pachetul Dojo elimină o parte neajunsurile AJAX. Pentru uploadul de
fişiere prin formulare, Dojo oferă funcţia dojo.io.iframe, ce maschează o funcţionalitate bazată pe cadre
interne invizibile ce conţin fişierul de uploadat (deoarece JavaScript şi XHR nu permit acces direct la
discul 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 are
loc 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 AJAX
rămâne neschimbată pe toata durata utilizării sale, iar un semn de carte tradiţional, creat prin stocarea
adresei URL curente nu va putea face diferenţa între diferite stări ale aplicaţiei. Trecerea de la o stare la
alta 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ă de
timp). Marca e concatenată în momentul transferului la adresa aplicaţiei. Fiecare astfel de marcă devine
reprezentativă pentru o stare a aplicaţiei. Atunci când utilizatorul creează un semn de carte, în acesta se
stochează adresa aplicaţiei (care e unică) concatenată cu marca stării curente. Considerăm funcţia de
transfer:
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 la
forma http://localhost/aplicatiamea.html#starea1. Această adresă va putea fi stocată în Favorites sau
Bookmarks, 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 vizitate
de 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 acest
context devine avantajoasă exploatarea cadrelor interne în locul obiectului XHR, deoarece fiecare
modificare 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 pe
durata utilizării aplicaţiei, folosind principiul anterior explicat, de definire a stărilor aplicaţiei prin
concatenare de mărci unice la adresa paginii. Pachetul Dojo permite programarea comportamentului
butoanelor Back şi Forward de pe browser, prin funcţii handler33
:
backButton: function() {..........}
forwardButton: function() {...........}
Notă: Ca şi în cazul upload-ului de fişiere, şi în acest caz
implementarea pe care o maschează Dojo e complicată şi bazată pe un
cadru intern invizibil. Cadrul invizibil suferă la creare două operaţii
forward şi o operaţie back pentru a se afla, din punct d e vedere al
istoricului, între un forward şi un back (astfel încât nici una din
cele două operaţii să nu provoace părăsirea aplicaţiei). Apoi, cele
două funcţii Dojo sunt legate de evenimentul onload asociat operaţiilor
back şi forward pe cadrul invizibil.
Un avantaj major al pachetului Dojo, care poate fi intuit din acest capitol, este că încapsulează
mecanismul complet de detectare a browserului pentru instanţierea corectă. Mai mult, dacă obiectul
XHR nu este disponibil sub nici o formă, Dojo încapsulează şi comunicarea cu serverul prin cadre
interne invizibile, fără nici un efort suplimentar din partea programatorului AJAX. Acest mecanism de
implementare 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 ramuri
de execuţie alternative pentru fiecare funcţionalitate care ar putea să lipsească din browserul
vizitatorilor, ceea ce asigură o robusteţe şi o fiabilitate mărită faţă de resursele utilizatorului. Structura
try-catch de verificare a existenţei claselor necesare instanţierii XHR este un exemplu de astfel de cod
degradabil. 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 bine
construit în acest sens. În plus, am sugerat şi faptul că în unele situaţii cadrele invizibile devin
obligatorii ş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 se
instalează 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 paginii
AJAX 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, care
apare chiar în numele fişierului şi care se modifică uneori cu
frecvenţă lunară. După ce downloadaţi biblioteca, verificaţi numele
fiş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 şir
de caractere, dar e acceptată şi sintaxa JSON. Mai iese în evidenţă faptul că adresa scriptului server e
un argument separat (nu face parte din obiectul-argument cu restul proprietăţilor, aşa cum era cazul în
Dojo). Ajax.Request poate primi numeroase argumente, dintre care cele mai importante sunt adresa
scriptului şi obiectul (aici în descriere JSON) cu descrierea cererii.
Notă: Având în vedere că şi funcţiile Prototype au ca argumente obiecte
definite prin JSON, rămâne valabilă regula discutată la prez entarea
Dojo: funcţiile handler sunt indicate doar prin nume, nu şi prin
paranteze, deci nu pot primi argumente explicite. Aşadar, o construcţie
precum
onSuccess: functiehandler(argument1,argument2)
va funcţiona eronat: va executa funcţia la construirea argumentului
Ajax.Request şi nu la declanşarea evenimentului pentru care s -a creat
handlerul! Handlerele Prototype au obligatoriu ca argument implicit
obiectul XHR, ca în exemplul:
new Ajax.Request(....{...onSuccess: functiehandler})
.....
function functiehandler(obiectxhr)
{
//blocul de execuţie a handlerului
}
În consecinţă, singura cale de a transmite argumente handlerelor este
intermedierea printr-un handler anonim (o valoarea de tip function):
onSuccess: function (obiectxhr) {functiehandler(argument 1,argument2)}
71
Din interiorul funcţiei handler vor putea fi accesate atât argumentele
explicite cât şi obiectul XHR.
Dacă se doreşte receptarea de cod JavaScript de la server, se poate apela la funcţia care
converteşte şiruri de caractere în construcţii JavaScript: eval (utilă şi la obţinerea obiectelor JSON în
mod nativ):
function procesare(obiectxhr)
{ eval(obiectxhr.responseText)
} function proceroare(obiectxhr) { ......
} function date(cod) { new Ajax.Request("script.php", { asynchronous: true, method: "get", parameters: "CodPostal="+cod, onSuccess: procesare,
onFailure: proceroare }) }
Evident, în acest caz scriptul server va returna un şir de caractere interpretabil ca şi cod
JavaScript, după cum s-a exemplificat în cazul Dojo.
Platforma care exploatează biblioteca Prototype, numită Ruby on Rails, promovează un
model aparte de aplicaţii AJAX: generarea de cod HTML la nivelul serverului, care apoi este inclus în
structura paginii prin proprietatea innerHML. Prototype este optimizată pentru această procedură: <html> <head> <script type="text/javascript" src="protoroot/prototype-1.6.0.2.js"> </script> <script type="text/javascript">
function proceroare(obiectxhr) {
document.getElementById("Eroare").innerHTML= "<font color=red>Eroare"+obiectxhr.responseText+"</font>"
} function date(cod) { new Ajax.Updater("t1","script.php", { asynchronous: true, method: "get", parameters: "CodPostal="+cod, onFailure: proceroare }) } </script> </head> <body> <h1>Introduceti datele</h1> <form> <table id=t1> <tr> <td>Nume</td> <td><input type=text id=TXnume ></td> </tr> <tr> <td>CodPostal</td>
72
<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>
Se observă că, în cazul folosirii obiectului Ajax.Updater, nu mai e necesară precizarea
handlerului 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 un
handler onSuccess pentru Ajax.Updater atunci când primirea răspunsului de la server are şi alte
consecinţ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 marcatorului.
Ajax.Updater(element, url, {........., insertion:top})
Revenind la exemplu, acesta se bazează pe faptul că serverul oferă cod HTML care poate fi
introdus prin innerHTML în locul conţinutului marcatorului al cărui atribut id e precizat în primul
argument Ajax.Updater. În consecinţă scriptul server ar trebui să genereze codul HTML de înlocuire: <?php if ($_GET["CodPostal"]==400451) { $oras='Cluj Napoca'; $judet='Cluj'; $adresa='Aleea Azuga....completati detaliile'; } else { $oras='cod incorect'; $judet='cod incorect'; $adresa='cod incorect'; } $cod=$_GET["CodPostal"]; print " <tr> <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> <td></td> <td><input type=submit value=Trimite ></td> </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 refreshul
redundant pe care modelul AJAX ar trebui să îl elimine. O parte din codul HTML (trei dintre
râ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 cu
minim de efort, este un instrument deosebit de puternic. Pentru a realiza acest lucru, intuiţia ar dicta ca
cele trei celule care se recreează la server să fie delimitate într-un bloc div sau span care apoi să fie
rescris cu Ajax.Updater:
<form> <table> <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ţiune
de document, atâta timp cât nu încalcă regulile de imbricare ale vocabularului XHTML. Aceste reguli
impun o structură rigidă a marcatorului table – acesta poate conţine doar marcatori tr, thead, tbody sau
tfoot. Orice text inserat între marcatorii table şi tr (sau între tr şi td) este fie ignorat de unele browsere,
fie mutat 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 rezultate
nedorite. 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 conversie
a 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 a
activa protecţia faţă de codul maliţios. Spre deosebire de funcţia nativă eval(), argumentul true face ca
funcţ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 din
proprietatea responseXML.
2.4. Interfaţa cu utilizatorul
Dacă ne referim strict la partea de interfaţă cu utilizatorul din AJAX, aceasta exista în anii 90
sub denumirea Dynamic HTML, care semnifica tocmai mecanismul de manipularea a unei interfeţe
HTML prin JavaScript şi CSS. Din nefericire, la momentul la care Dynamic HTML s-a lansat, a fost
respins de comunitatea Web datorită lipsei de maturitate – CSS nu devenise încă un limbaj în sine, ci
doar o sintaxă de formatare complementară limbajului HTML, modelul DOM era încă primitiv iar
diferenţele de implementare între browsere erau descurajante. La ora actuală există încă diferenţe de
implementare î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ă manipularea
interfeţ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ţiile
desktop, utilizabilitatea a evoluat de la începutul anilor 90 până în prezent, pe măsură ce s-a trecut de la
sistemele de operare şi aplicaţiile cu linie de comandă la cele cu meniuri şi apoi la cele vizuale, bazate
pe 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 au
deschis noi orizonturi comparativ cu aplicaţiile în care interacţiunea se baza strict pe introducere de
date/comenzi sau selecţia din meniuri. În schimb, aplicaţiile Web au fost limitate în acest sens de gama
redusă de evenimente programabile şi de latenţa reţelei, adică de faptul că declanşarea evenimentului şi
datele necesare se aflau pe calculatoare diferite. Apariţia scripturilor client JavaScript şi a modelului
Dynamic HTML au permis tratarea anumitor evenimente exclusiv la nivelul clientului, evitând latenţa
de 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 comunicarea
asincronă 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 pot
obţ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 arborelui
dar oferă şi căi de acces mai facile la noduri, pe bază de atribut id (getElementById) sau prin vectorul
getElementsByTagName. În plus, atributele marcatorilor HTML sunt mapaţi în proprietăţi ale
obiectelor-element, după cum s-a văzut deja în exemplele acestui material. Pachete de funcţii precum
Dojo, Prototype sau Script.aculo.us oferă metode de nivel chiar mai înalt pentru accesul la
componentele arborelui DOM. Aceste pachete au avut un rol 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 considerate
blocuri reutilizabile de cod sursă.
75
2.4.1. Manipularea interfeţei cu utilizatorul prin biblioteca Prototype
Un număr mare de pachete de funcţii JavaScript pentru AJAX sunt construite pe funcţiile
pachetului Prototype. S-a arătat anterior că pachetul este uşor de instalat (e vorba de un singur fişier de
tip .js ce conţine definiţiile tuturor funcţiilor, iar numele fişierului conţine numărul de versiune al
bibliotecii).
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 şi
Field;
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 atribut
value (marcatorii input).
Localizarea în arborele DOM: Prototype oferă o metodă suplimentară de localizare a
elementelor din document: getElementsByClassName() identifică elementele prin numele stilului CSS
din atributul class! Metoda e mai degrabă 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 aceea
că 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 de
caractere, ci îi va afişa (de exemplu, atunci când e necesară afişare de cod HTML în textul
documentului):
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 limbajului
JavaScript.
Exemplul de mai jos calculează suma elementelor unui vector în mod clasic:
suma=0 for (i=0;i<numere.length();i++) {
suma=suma+numere[i] }
alert(suma)
Funcţia each() permite ca iteraţia să aibă loc în felul următor, evitând explicitarea ciclului for: suma=0 function aduna(numar) { suma=suma+numar
} numere.each(aduna) alert(suma)
Se observă că argumentul lui each() este o variabilă de tip function, care apelează funcţia
aduna() pentru fiecare element al vectorului. Aşadar, elementele vectorului care califică each() sunt
transferate 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 fiecare
element din colecţie care respectă condiţia dată de expresia regulată; aşadar, e similar cu
each() 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. Pentru
sintaxa 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 care
respectă condiţia;
detect() – argument similar; dar returnează primul element pentru care funcţia-argument
returnează true;
findAll () – argument similar, dar returnează sub formă de vector toate elementele pentru care
funcţia-argument returnează true;
reject() – argument similar, dar returnează sub formă de vector toate elementele pentru care
funcţ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 care
funcţ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 pentru
fiecare element al masivului vor fi colectate într-un nou masiv; exemplul de mai jos colectează
în vectornou dublul valorilor vectorului numere: numere=[-1,2,3] function dublare(numar) { return 2*numar
} vectornou=numere.collect(dublare)
invoke() – argumentul va fi un nume de metodă (în format string) ce se va aplica asupra
elementelor colecţiei; exemplul de mai jos ascunde toate elementele din pagină stocate în
vectorul a (vectorul b va stoca aceleaşi elemente deoarece invoke, ca şi collect, returnează un
masiv):
a=$("id1","id2","id3") b=a.invoke("hide")
pluck() – argumentul va fi un nume de proprietate (în format string) a cărei valoare va fi
citită pentru toate elementele colecţiei, valorile obţinute fiind stocate într-un masiv, ca în cazul
collect; exemplul de mai jos creează vectorul a, cu toate elementele ce au folosit stilul stil1, iar
vectorul b va primi toate valorile id ale acestora:
a=document.getElementsByClassName("stil1") b=a.pluck("id")
max() – argumentul va fi o 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 pentru
controlul 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 Element
oferă funcţiile show() şi hide() pentru afişare şi ascundere de noduri.
Notă: Avertizăm asupra faptului că nodurile ascunse pot să influenţeze
totuşi comportamentul paginii. Spre exemplu dacă se ascund câmpuri ale
unui formular, acestea vor trimite totuşi date serverului la folosirea
butonului submit. De asemenea, JavaScript va continua să aibă acces la
nodurile ascunse.
Un alt mecanism frecvent este eliminarea de noduri DOM, realizată de regulă prin resetarea
proprietăţii innerHTML sau cu metoda removeChild(), acestea fiind precedate de necesitatea de a
localiza nodul dorit. Clasa Element oferă Element.remove() care preia ca argument atributul id al
nodului de şters.
Definirea clasei Insertion. Rolul clasei este de a oferi metode de inserare în grupuri de
elemente consecutive. 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=AdaugaInceput onclick="new Insertion.Top('lista','<li>'+$F('valoare')+'</li>')">
<input type=button value=AdaugaSfarsit onclick="new Insertion.Bottom('lista','<li>'+$F('valoare')+'</li>')"> <input type=button value=AdaugaInainte onclick="new Insertion.Before('lista','<b>'+$F('valoare')+'</b>')"> <input type=button value=AdaugaDupa onclick="new Insertion.After('lista','<b>'+$F('valoare')+'</b>')">
Exemplul 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 uzuale
ar fi:
inserare relativ la rândurile unui tabel – în loc de blocul ul se va crea un bloc table iar funcţiile
de 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=AdaugaInceput onclick="new Insertion.Top('formular','<input type=text value='+$F('valoare')+'><br>')"> <input type=button value=AdaugaSfarsit onclick="new Insertion.Bottom('formular','<input type=text value='+$F('valoare')+'><br>')">
În acest caz butoanele AdaugaInceput şi AdaugaSfarsit inserează noduri noi la începutul şi
sfârşitul unui formular. Nu am mai reluat exemplele pentru inserare Before şi After, acestea
funcţionând oricum, independent de tipul grupului de elemente despre care e vorba. Grupul de
elemente poate fi şi unul eterogen, ca în exemplul:
<div id=blocdiv> <b>Imagine1</b><br> <img src="imaginel.jpg"><br> <b>Imagine2</b><br> <img src="imagine2.jpg"><br> </div> <input type=text id=numefisier> <input type=button value=AdaugaInceput onclick="new Insertion.Top('blocdiv','<b>Imagine0<b><img src='+$F('numefisier')+'><br>')">
Deoarece funcţiile Insertion permit explicitarea codului HTML ce va fi inserat (al doilea
argument), utilizarea lor nu e limitată la colecţii omogene de noduri (formulare, tabele, liste) ci e
permisă la orice grup de noduri fraţi grupate sub un marcator identificabil, după cum se vede în ultimul
exemplu.
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ă încapsularea grupului 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 toate funcţ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ă metode
de 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 primul
câ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 a
doua 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 şi
consecinţă 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 a
identifica poziţia relativă a elementelor, inclusiv poziţia faţă de suprafaţa vizibilă a paginii într-o
fereastră 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 biblioteca Script.aculo.us
Script.aculo.us este una din cele mai cunoscute biblioteci JavaScript orientate spre interfaţa cu
utilizatorul, 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 adoptarea
pachetului în designul unor site-uri de renume. Pachetul poate fi descărcat gratuit la adresa
http://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 se
află în folderul src al pachetului (8 dintre ele) şi în folderul lib (fişierul prototype.js). Fişierul
prototype.js este chiar biblioteca Prototype care este aşadar inclusă în biblioteca
Script.aculo.us;
Copierea celor 9 fişiere într-un folder dedicat stocării bibliotecii, în cazul nostru acesta va
avea numele scriptaroot, în rădăcina serverului Web;
Scripturile ce vor folosi funcţii Script.aculo.us vor include două apeluri de biblioteci
JavaScript, una pentru Prototype (versiunea Script.aculo.us) şi una pentru Script.aculo.us (care
conţ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 instalarea
versiunii din pachetul Script.aculo.us, pentru a evita riscul
incompatibilităţilor între Script.aculo.us şi Prototype. În exemplele
materialului de faţă ultima versiune Prototype e apelată din folderul
protoroot iar versiunea Script.aculo.us pentru Prototype e apelată din
folderul scriptaroot.
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. Fiecare
efect 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 ecranului
sau 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. Efectele
Script.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ă indice
un 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 pe
extremităţile animaţiei. Considerăm un efect MoveBy ce deplasează un element cu 100 de pixeli la
dreapta şi în jos:
new Effect.MoveBy("idelement",100,100,{from:0.0,to:0.5})
Deplasarea suferită de element e definită pe distanţa 100x100 (distanţe negative vor permite
deplasări la stânga sau în sus; prima valoare e verticala, a doua orizontala36
). Se observă enumerarea
opţiunilor în format JSON, aşadar acestea pot fi anterior stocate într-un obiect. Opţiunile acestui
exemplu 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ţă cu
cu 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ă fie
vorba 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 observarea
codului sursă a paginii cu instrumentul de depanare Firebug.
Imaginea indică faptul că, la nivel de cod, efectul s-a obţinut prin modificarea/crearea
atributului 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 prin
construcţ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 editarea
codului sursă cât şi în gândirea algoritmilor de tranziţie. Spre exemplu, algoritmul flicker se obţine
printr-o formulă matematică de randomizare a poziţiilor intermediare ce implică funcţii JavaScript
precum 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 comutarea
vizibilităţ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, un
obiect complet transparent ocupă totuşi o porţiune din suprafaţa afişată a paginii. Un obiect ascuns nu
ocupă 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" sau
visibility la "hidden".
Exemplu:
<html> <head> <script type=text/javascript src=scriptaroot/prototype.js> </script>
<script type=text/javascript src=scriptaroot/scriptaculous.js> </script> <script type=text/javascript> function deplasare() { new Effect.Opacity("bloc1",{ from:1.0,to:0.0,transition:Effect.Transitions.flicker}) } </script> </head> <body> <div id=bloc1 onclick=opacitate()>Acest paragraf devine transparent cu stări intermediare aleatoare</div> </div> </body> </html>
Exemplul poate fi verificat tot prin clic pe paragraful afişat. De data aceasta, paragraful devine
transparent (from 1 to 0!) trecând prin stări intermediare aleatoare (flicker). Efectul de pâlpâire se
obţ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 spre
stâ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: fixarea
unui 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 dimensionarea
elementelor conţinute:
o funcţia nu dimensionează elementele img (acestea trebuie să sufere propriul efect de
dimensionare);
o în unele browsere funcţia dimensionează textul doar dacă acesta a fost formatat
explicit 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 în
timpul dimensionării;
scaleMode: valoarea box implicită stabileşte să se dimensioneze doar porţiunile elementului
ce sunt vizibile fără derulare; valoarea content dimensionează complet elementul;
scaleFrom: procentajul din dimensiunea curentă de la care să înceapă dimensionarea, implicit
100%.
<html>
<head> <script type=text/javascript src=scriptaroot/prototype.js> </script> <script type=text/javascript src=scriptaroot/scriptaculous.js> </script>
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. Prin
aceasta 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 pentru
conţ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. Preluarea acestei sarcini de către un
element de tip imagine (un buton, o bară de scalare) poate aduce interfaţa AJAX mai aproape de
interfeţele aplicaţiilor desktop, aducând un semnificativ plus de utilizabilitate!
Highlight() – acest efect schimbă culoarea de fundal a elementelor trecând prin spectrul
culorile intermediare. În forma implicită, efectul aplică modelul Yellow Fade, adică tranziţie rapidă, de
tip flash, la galben şi înapoi, pentru a atrage atenţia utilizatorului asupra unui element al paginii. Efectul
nu afectează elementele care au deja o culoare de fundal stabilită prin CSS. Opţiunile suplimentare ale
efectului 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 proprietatea
CSS "background-color" în cadrul unui ciclu for care modifică sincron valorile R, G şi B din codul
culorii.
Se poate remarca faptul că Script.aculo.us oferă instrumente de un nivel atât de înalt încât
percepţia progamatorului asupra documentului se mută dinspre structura DOM (necesară atunci când
se gândeşte în termeni de noduri şi localizarea lor în arbore) spre suprafaţa ocupată pe ecran de
elementele 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 la
roş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 lista
efectelor 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 asupra
aceluiaş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 pe
baza 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
Recapitulare
Modulul 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 de
date XML și JSON.
În continuare se prezintă sintetic modelele de afaceri electronice consacrate și, în contextul
acestora, 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 acestui
spaţ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ţei
firmelor din întreaga lume care au acces la spaţiul virtual, asistând astfel la o adevărată revoluţie a
domeniului economic. Reacţia firmelor la aceste tendinţe se manifestă prin modificarea modului de
organizare şi de acţiune, începând să comprime vechile structuri ierarhice şi să elimine barierele
existente între compartimentele operaţionale. Se tinde de asemenea, spre renunţarea la barierele dintre
firmă şi clienţii sau furnizorii acestora.
Tendinţa actuală a multor firme este utilizarea Web-ul pentru a se face cunoscute, prin
intermediul celei mai importante surse de informare din societatea informaţională – Internetul. Pentru a
deveni un furnizor de informaţii, trebuie să posede o pagină unică de pornire (home page), cu ajutorul
căreia orice firmă poate deveni parte din Web, îşi poate oferi bunurile şi serviciile şi diverse informaţii
utile 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 este
arhicunoscut 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 de
organizare şi de acţiune, începând să comprime vechile structuri ierarhice şi să elimine barierele
existente între compartimentele operaţionale. Se tinde de asemenea, spre renunţarea la barierele dintre
firmă ş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 ale
comerţului electronic şi nu în ultimul rând principalele avantaje şi dezavantaje pe care acest fenomen îl
implică.
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 capta
integral spiritul comerţului electronic care, în practică reprezintă una din situţiile în care nevoile tot mai
complexe şi tehnologiile noi se contopesc pentru a revoluţiona modul în care se derulează afacerile. In
concepţ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 loc
offline sau online‖. Definiţia elaborata de R.Kolakota şi A.Whinston în lucrarea Frontier of electronic
commerce apărută în 1996: Comerţul electronic este o metodă modernă de efectuare a afacerilor, care
se 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 Information
Administration, definind comerţul electronic într-un sens larg ca fiind utilizarea oricărei tehnologii
electronice î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 electronic 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 face
afaceri 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 pentru
cumpă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 economic
complex, 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 şi
acces 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 Can
Grow Your Business), Microsoft Press, Redmond, Washington, 1997, p. 6
INSTITUŢII
Guvernul
Producători
Comercianţi
Furnizori
Consumatori
PROCESE
Marketing
Vânzări
Plăţi
Suport
REŢELE
Proprii
Internet
Comerciale
Comerţ
electronic
90
apropierii şi a unei bune comunicaţii cu clienţii, avantaj exclusiv al firmelor mici. E-commerce oferã o
oportunitate 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 avantaje
semnificative. Î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 ar
fi recrutarea personalului sau plata facturilor
AVANTAJE INTANGIBILE
Prezentarea imaginii firmei
Brandul
Campanii de marketing mai rapide şi mai eficiente, inclusiv PR
Cicluri de 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 examinate
atât la nivelul consumatorilor cât şi la nivelul firmelor.
Un beneficiu important al consumatorilor este accesul la cantitatea mare de informaţii
dinamice pentru sprijinirea luării deciziilor. În plus caracterul interactiv a Web-ului permite căutare
mai adâncă, neliniară iniţiată şi controlată de clienţi. De acum încolo, comunicarea prin Web este mai
mult 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 permite
compararea 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. De
asemenea există probabilitatea ca produsele greu de găsit să fie disponibile şi o selecţie mai largă a
articolelor datorită lărgimii şi eficienţei Web-ului. În plus avantajele pentru consumatorii industriali
sunt date de costurile reduse datorită competiţiei în procurarea materiilor prime, deoarece mai mulţi
furnizori pot concura într-o piaţă electronică deschisă. Acesta determină pe competitori să ofere
produse de gamă largă şi de mai bună calitate şi de a produce articole conform cererii.
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ărare 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ă a
partenerilor;
o cale rapidă şi comodă de furnizare a informaţiilor despre o companie sau despre produsele sale
prin 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 din
aproape 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 venituri
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 beneficii
operaţionale. Prin utilizarea Web-ului ca un canal de distribuţie, costurile de distribuţie sau costul
vânzării se contractează la zero. Acesta este mai probabil în domeniul publicităţii, furnizarea
informaţiilor sau produse digitale. Mai mult, cumpărătorii şi vânzătorii se pot contacta direct eliminând
cheltuieli de marketing şi constrângerile impuse de asemenea interacţiuni în lumea terestră, făcând
distribuţ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 alegerile
consumatorilor prin dezvăluirea preferinţelor lor în comportamentul de navigare şi cumpărare prin
Web.
Î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 la
dispoziţ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 consumatorii
individuali, permiţând clienţilor de a solicita informaţii cât doresc. Obţinerea informaţiilor relevante
despre clienţi, care sunt utilizate în scopul de a servi mai eficient în viitor permite firmelor să dea
informaţ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 loc
de 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 plus
este facilitată crearea de noi pieţe şi segmente de piaţă precum şi intrarea mai uşoară pe pieţele
existente ş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ăsirea
căilor de reducere sau înlăturare 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 şi
formalităţile cu transportul. Principalul obstacol, care continuă să existe, este cel legat de
distribuţia globală a bunurilor şi serviciilor.Un alt obstacol se referă la dificultatea de a derula
livrarea şi/sau expediţia unor loturi (pachete) mai mici. Cercetările din ţările membre ale UE
evidenţ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 şi
practica propriu-zis comercială. Adesea dificultăţile în comerţul electronic global sunt create
de diferenţele în sistemele legislative. În domeniul serviciilor juridice, pieţele electronice
globale 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, poate
fi deosebit de greu să se atingă economia de scară necesară creării unei pieţe electronice
globale, 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ării
acestuia 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ă o
singură ţ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 de
origine‖. Acest principiu precizează că un contract se supune legilor ţării de origine a
vâ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 volumul
relativ 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ţirea
segmentelor de piaţă ca, de exemplu, franchising şi scheme asociate acesteia (zone
comerciale). 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 de
mobilă î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ăbiciuni
interne. 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 dintre
schimburile 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ă o
viziune 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 în
alte 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 trebuie
să fie într-adevăr globale. Funcţia reală de reprezentare şi comercializare a acestor tipuri de pieţe poate
fi în întregime locală, în timp ce funcţiile de acces, plata, securitatea şi livrarea produselor ar putea fi
globale.
Asociaţiile de export reprezintă un alt tip de piaţă electronică de dimensiune globală care, cu
toate acestea, este caracterizat şi printr-un puternic element local. Conceptul constă în existenţa unui
număr de furnizori (ofertanţi), din aceeaşi regiune geografică, care caută o prezenţă globală, dar care nu
sunt capabili să acţioneze global în mod individual. Aceştia creează o entitate comună de export, care
se ocupă, în numele lor, de complexitatea comerţului internaţional cum ar fi cataloage în mai multe
limbi, 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ă ideea
comunicãrii în douã sensuri, când ei integreazã propriile pagini Web, sistemele intranet şi extranet în
sistemul 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 urmare
salariaţii, clienţii, distribuitorii şi furnizorii câştigã mai mult accesând datele mai repede şi
interacţionând direct cu nucleul sistemului de afaceri, iar companiile descoperã posibilităţi noi de
folosire 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 şi
experienţe pentru a fundamenta calea spre care trebuie condusã afacerea. Acesta este adevãrata forţã a
e-business-ului.
Un e-business prosper are şi o altã caracteristicã. Firmele sunt interesate sã vadã schimbarea
ca o oportunitate şi nu ca o provocare. Acest lucru este important pentru cã e-business-ul apare într-un
mediu schimbãtor, tehnologia evolueazã rapid şi regulile competiţiei se schimbã. Dacã o firmã este
mare, e-business poate ajuta ca sã se comporte ca o companie micã, mult mai agil, fãcând compania
mult mai responsabilă şi oferând posibilitatea unei comunicaţii mult mai directe cu clienţii, în schimb
dacă este o companie micã, e-business poate s-o ajute ca sã pară una mare, oferind o vizibilitate mare şi
acces la clienţi din întreaga lumea.Deci, indiferent de mãrimea firmei, peste tot clienţii actuali şi
milioanele de noi clienţi potenţiali pot sã aibã acces la afacere oricând şi oriunde. E-business oferã o
oportunitate 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 de
beneficiile 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ă cheltuielile
operaţ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 în
operaţ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 ţine
cont 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. Cele
mai importante avantaje le vor obţine acele companii care sunt dispuse să-şi modifice organizarea şi
modul 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, folosind 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 electronice41
În prezent, cele mai răspândite tipuri de comerţ electronic sunt Business-to-Business (B2B) şi
Business-to-Consumer (B2C).
1. Tranzacţiile B2B se caracterizează prin faptul că ambele părţi participante la tranzacţia
comercială, atât vânzătorul cât şi cumpărătorul, sunt instituţii (ex rtcoffice.ro). Acoperã toate
tranzacţ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 şi
parolele de pe website-urile lor. Din punctul de vedere al unui client B2B managementul informaţiei
destinate cumpărătorului ar trebui să se regăsească în site-ul cumpărătorului, în vederea integrării cu
celelalte 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 exemplu
41
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 comenzi
la furnizori, pentru a recepţiona facturi şi pentru a efectua plăţi. Acest tip de comerţ este implementat
de 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 prin
anii 1960 şi poate fi considerat strămoşul Comerţului Electronic (EC - Electronic Commerce). EDI
oferă 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ăncile
utilizează 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 Trading
Process 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ă azi
de Hewlett Packard, Textron Automotive, Chrysler, suplimentar peste 1.400 întreprinderi mici şi
mijlocii din lume participă la tranzactii. Recent, odată cu creşterea accesibilităţii la Internet, EC a căptat
interesul consumatorilor individuali şi al societăţilor comerciale de orice mărime şi preocupări. Mai
mult decât atât, cu tehnologiile avansate disponibile acum, se vorbeşte tot mai des de Economia
Digitală (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 dintre
comerciant ş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 şi
consumatori se referă la vânzarile electronice en-detail. Această categorie s-a dezvoltat foarte mult
odată 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 cu
calculatoare şi autoturisme.
3. Tranzacţii B2G Include toate tranzacţiile dintre firme şi organismele guvernamentale şi
administrative.(de exemplu e-licitatie.ro) Guvernele, la nivel naţional, regional şi chiar municipal
utilizează canale de comerţ electronic pentru creşterea eficienţei operaţiunilor, îmbunătăţirea nivelului
serviciilor 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 erau
transmise furnizorilor sub forma unei scurte liste, în ziare, sau în publicaţiile guvernului. Între anii
1980-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 de
informaţ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ă şi
internaţ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ă utilizeze
capacităţile de comunicare cum ar fi soft-ul necesar transmisiilor EDI, dacă doreau să descarce
informaţ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 '90
această categorie se afla într-o stare incipientă, dar ea se dezvoltă rapid, având în vedere că unele
guverne 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 şi
impozite.
Un exemplu elocvent este site-ul www.elicitatie.ro care permite achiziţia de materiale
consumabile, echipamente şi alte categorii de mărfuri de către instituţiile bugetate, prin intermediul
licitaţ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ă în
domeniul privind plata ajutoarelor sociale, returnarea taxelor etc.
4. Tranzacţii C2G, acoperă relaţii guvern-cetăţeni la nivel de informare şi prestare servicii
publice(ex plătirea taxelor online). Categoria tranzacţii dintre consumatori şi organismele
guvernamentale a fost implementată în ţara noastră la nivel local (primării). Totuşi, în condiţiile
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ţiile
locale, privind plata ajutoarelor sociale, returnarea taxelor etc.
5. Tranzacţii C2C, consumatorii care vin direct la alţi consumatori (okazii.ro, ebay.com) În
această 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 prin
intermediul sistemului intranet.
Impactul comerţului electronic se face simţit atât la nivelul fiecărei firme, cât şi pe ansamblul
societăţ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ât
ajung 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 ale
caracteristicilor pieţelor. În acelaşi timp, membrii societăţii vor beneficia de noi modalităţi de
achiziţ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. Impactul
global asupra stilului de viaţă poate fi comparabil cu cel al creşterii numărului de autoturisme sau cu
cel 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 prin
intermediul mediilor virtuale. Avantajele acestui model de afacere este în principal accesul 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 de
companie pentru activităţile de marketing şi cele de vânzare a propriilor produse şi servicii. Minimal, site-ul
Web 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 securitatea
tranzacţiilor. Produsele care se comercializează cel mai bine prin intermediul magazinelor virtuale sunt, de
regulă, cele care pot fi descrise cu uşurinţă şi nu necesită încercarea lor înainte de cumpărare. Spre de
exemplu: bilete de avion sau de concert, CD-uri, cărţi, software, produse alimentare, etc. Din punctul nostru
de vedere, serviciile au rolul de a completa oferta de produse şi se circumscriu deseori unei sfere mai largi,
cum ar fi spre exemplu site-ul de comercializare a produselor cosmetice care poate prezenta şi un
desen/schiţă despre cum se aplicăo cremã, un ghid despre genul de fard recomandat dimineaţa, în timpul
zilei şi respectiv seara. Preţurile produselor comercializate prin intermediul magazinelor virtuale sunt, în
general 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 majoritatea
rămâne fidelă abonamentelor clasice, în general, numai clienţii noi apelează la acest nou sistem de
abonament. In schimb abonamentele on-line pentru accesul la ştiri de ultima oră sau la dezbateri cu
participare restrictivă (contra cost), captează interesul doar dacă serviciile oferite sunt de valoare mare.
Aprovizionarea electronică (e-procurement). Integrarea electronică şi managementul
tuturor activităţilor de aprovizionare – primirea de oferte, comenzi, livrări şi plăţi – între o firmă şi
furnizorii acesteia. În categoria aprovizionărilor electronice se includ şi licitaţiile organizate de marile
firme şi autorităţile publice pentru achiziţionarea de bunuri şi servicii. Prin publicarea pe Web a
specificaţiilor ofertei, scad atât timpul cât şi costul de transmisie, mărindu-se şi numărul de firme care
iau 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 firme
de renume şi ajută clientul să găsească şi să aleagă exact produsul de care are nevoie. Există e-mall-uri
care acoperă o gamă variată de produse, pot oferi produsele unui anumit producător sau pot acoperi o
zonă geografică. Un e-mall poate accepta metode de plată comune. Un magazin electronic de tip Mall
reprezintă un depozit electronic conectat la o serie de baze de date ale furnizorilor săi, nu necesită spaţiu de
construcţie, timp şi bani pentru efectuarea de inventarieri şi oferă posibilitatea de a face constant cele mai
mici 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 date
conectate 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 un
e-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 de
marketing a e-mall-ului. Un e-mall de succes se defineşte ca fiind o reuniune de magazine virtuale care
deţ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 la fel
ca î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 de
resurse 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, datele
tranzacţionate sunt procesate electronic, reducând astfel timpul şi costul operaţiilor de procurare, ceea ce
determină 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 şi
discuta subiecte de interes pentru ei. Comunităţile virtuale sunt grupuri de discuţii interactive sau liste de
corespondenţi pentru dezbaterea subiectelor din diferite domenii de interes ale participanţilor. Discuţiile pot
fi pe diferite teme, de la cele de divertisment până la cele ce vizează un anumit domeniu de activitate. Astfel
de discuţii au loc prin intermediul forumurilor (forums), grupurilor (chat) sau listelor (mailing lists) de
discuţ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 a
asculta 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
98
creşterii traficului pe site-ul Internet şi dar pentru stimularea fidelitãţii şi ataşamentului emoţional faţă de
aceasta. 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 reduc
costurile de călătorie şi sunt utilizate de firmele mari, atât pentru comunicări ştiinţifice cât şi pentru cele
comerciale1.Î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 forma unei taxe de participare sau specifice
evenimentului 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 de
cercetare 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ă prin
mecanisme precum semnătura digitală. Câştigurile provin din managementul platformei (taxa de
membru sau taxa de utilizare), şi din vânzări de instrumente specializate (pentru proiectare, workflow şi
gestiunea de documente).
Platformele de colaborare oferă un set de instrumente şi un mediu de informare pentru colaborarea
între intreprinderi, între acestea şi colaboratorii externi şi între 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 trebuie
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 derularea
activităţii în general sau pentru domeniul contractual, în special1.
Piata unui terţ (Third-party marketplace) oferă vânzătorilor o interfaţă Web pentru
catalogul 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 acest
sens.
Furnizor de servicii cu valoare adaugată (Value chain service provider) oferă diferite
funcţii specifice din cadrul lanţului de aprovizionare al unei firme. Astfel de funcţii sunt logistica, plata
electronică, 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ţă în
domenii 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 de
abonament, fie prin intermediul banilor electronici de tipul e-cash sau cybercash. Au fost înfinţate unităţi şi
agenţii de cercetare care încearcă să creeze mecanisme de detectare semantică, dar serviciile de informare
care 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 sau
serviciilor oferite de firmele care acţionează pe piaţa electronică. Un exempul de astfel de servicii sunt
oferite de TRUSTE (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-se
observa 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 nivel
internaţ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ţea
de promovarea imaginii firmei şi de asistenţa pre şi postvânzare, folosind tehnologii deja existente şi
testate, 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 şi
servicii 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 şi
identificarea 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 aceste
nomenclatoare, funcţie de numele producătorilor, sau numele exact al produsului dar majoritatea deţin
doar o descriere generică a produsului sau a unui standard internaţional pe care bunul solicitat trebuie
să-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 o
organizaţie de mari dimensiuni le încheie cu furnizorii săi, caz în care toţi achizitorii din cadrul
organizaţ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 principalii
factori care determină forma de încheiere a contractelor o reprezintă categoria de bunuri şi servicii care
fac obiectul tranzacţiei: produse, mărfuri fungibile, bunuri şi servicii proiectate la comandă, produse şi
servicii 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 ajuta
afacerile, de a realiza noi valori tangibile şi cuantificabile în afacere. E-commerce-ul furnizeazã un
acces interactiv şi comod în întreaga lume, cu 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 şi
reducând costul actual al unei vânzări E-commerce este mai mult decât deschiderea unei canal de
vânzare online. Ea înseamnă utilizarea tehnologiilor pentru fuzelarea modelului de afaceri, obţinerea
economiilor, şi creşterea eficienţei, ea înseamnă reducerea costurilor şi stabilirea unor relaţii mai
strânse şi sensibile cu clienţii, furnizorii şi partenerii.
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 la
vânzarea în detaliu online, B2C include servicii bancare, de transport, de licitaţie, de sănătate. Business
to 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ţului
clasic, 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ă. Acestea
solicită 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 alte
companii, iar în B2C clienţii sunt persoane fizice. Aceasta determină alte implicaţii deoarece în general
tranzacţ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 şi
sintetizarea. Vânzarea către o altă firmă implică o serie de negocieri asupra preţurilor, condiţiilor de
livrare ş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ă integrarea cu sistemul
clienţ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 fluxul
informaţ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 de
modalităţile de plată existente, cunoscut fiind faptul că majoritatea acestor tranzacţii se fac prin
intermediul cărţilor de credit, pentru realizarea operaţiilor de vânzare-cumpărare. După publicaţia
eMarketer 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 şi
flori; 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 alte
companii (B2B), trebuie să fie siguri că pot comunica între ei fără intervenţie umană. La realizarea
aplicaţ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 în
funcţ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ă la
posibilitatea integrarii într-un e-mall;
3. clientul, cu o anumită formare profesională, interese proprii şi preferinţe. Acest client poate fi
un 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 de
afaceri 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 în
spaţiul virtual al unui magazin care oferă clienţilor săi diferite produse. În funcţie de procentul din
afacerea 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 implementare
e-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ării
acestei 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 îşi
introduce 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 a
produselor online prin intermediul unui magazin virtual pot fi sintetizate prin figura de mai jos, în care
operaţiile realizate sunt împărţite în activităţi anterioare comenzii şi activităţi realizate după procesarea
comenzii.
Pentru a construi un sistem de comerţ electronic, din punct de vedere arhitectural este nevoie
de colaborarea a patru componente (subsisteme electronice/informatice) corespunzătoare următoarelor
roluri:
Client. Un echipament, clasic un PC, conectat direct (via un ISP) sau indirect (o reţea a unei
corporaţ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, care
găzduieşte şi actualizează catalogul electronic de produse disponibile a fi comandate on-line pe
Internet.
Sistemul tranzacţional. Sistemul informatic (hard & soft) responsabil cu procesarea
comenzilor, iniţierea plăţilor, evidenţa înregistrărilor şi a altor aspecte de business implicate în procesul
de 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ţeaua
financiar-bancară. Indiferent de tipul de afacere abordat în cadrul aplicaţiilor de comerţ electronic apar
trei 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 intermediul
unui software specializat destinat managementului relaţiilor cu clienţii (Customer Relationship
Management-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. La
nivelul Internetului, CRM-ul transformat în e-CRM foloseşte tehnologia Web pentru a comunica în
interior, între departamente şi clienţi. Cele mai complexe sisteme de e-CRM sunt cele produse de către
firma GoldMine Software Corporation, Commence Corp, şi MultiActiv Software. Aplicaţiile de acest
gen trebuie să conlucreze cu servere bazate pe SQL în cazul operaţiilor de amploare. Liderul în
domeniul 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 pornind
de la nucleul sistem ERP (Enterprise Resource Planning - gestiunea intreprinderii). Astfel, in aceste
sisteme, 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 pe
consumator, 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 orice
moment, oriunde şi independent de platformã. Clienţii sunt dezvoltaţi în momentul în care compania
furnizeazã servicii personalizate. Informaţiile despre utilizatori pot fi manipulate pentru a oferi o
selecţie personalizatã de produse şi servicii. Rãspunsurile date clienţilor trebuie sã fie cultivate şi
menţ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 managementul
liniei de aprovizionare iar companiile utilizeazã aceastã tehnologie pentru a ajuta comunicarea şi
colaborarea cu partenerii de afaceri.
Managementul liniei de aprovizionare ajutã la obţinerea unor rãspunsuri la întrebãrile de
cheie î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 bune
locaţ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 livrarea
produsului potrivit, la locul potrivit, în timpul potrivit şi la cel mai mic cost. Beneficiul înfiinţãrii unei
legã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 a
variabilelor liniei de aprovizionare. IBM este situat în centrul unuia dintre cele mai mari linii de
aprovizionare din întreaga lume şi este capabil să transfere aceste experienţe pentru a ajuta clienţii.
Principalele produse de modelare a aplicaţiilor e-business pentru managementul liniei de aprovizionare
sunt Lotus Domino şi MQ Series. Aceste produse includ servicii e-commerce şi produse pentru
suportul 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 afacerile
tradiţ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 şi
se înregistrează informaţiile despre consumator de pe banda magnetică a unei cărţi de credit sau de
debit. După procesarea acestor informaţii POS trimite informaţiile şi detaliile tranzacţiei către
institutiile 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 sunt
suficiente efectuării plăţii şi autorizează sau declină tranzacţia. În situaţia în care comunicarea la
terminalul 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 şi
respectat 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 credit/debit a clientului. În mod
evident, autorizarea încasării este obţinută însă înainte de expedierea produsului, pentru a avea
confirmarea ca există fonduri disponibile şi a elimina riscurile în caz de furt. Transferul bancar are loc
numai după ce produsul este în drum spre consumator.
Furnizorul contului de comerciant poate influenţa alegerea sistemului de shopping cart. În
cazul tranzacţiilor în timp real care oferă şi palta online, este necesar ca formularul de plată să poata fi
legat la serviciile de autorizare oferite de furnizorul contului de comerciant. Dacă nu este posibil,
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 de
comerciant. În aceste condiţii cunoaşterea acestor detalii pot influenţa semnificativ tipul de afacere
electronică 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 de
afaceri. O trăsătură comună a majorităţii acestor soluţii o constituie utilizarea tehnicilor criptografice care
asigură confidenţialitatea, autenticitatea şi integritatea mesajelor transferate între entităţile implicate. În
aceste sisteme sunt implicate, în general trei părţi care interacţionează între ele, şi anume: o bancă, un
cumpărător şi un vânzător. Un sistem electronic de plăţi43
este alcătuit din două nivele care
sunt:[Roşca_2004]
1. nivelul utilizator care cuprinde mulţimea tuturor utilizatorilor şi a tranzacţiilor care au loc între
aceş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 acest
sistem 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 o
catelă de credit obijnuită, un smartcard dispune de un microprocesor. Comunicarea cu punctul de
acces se face printr-un contact direct cu dispozitivul specializat în citirea cartelelor iar cumpărătorul
nu are acces la instrumentele soft şi hard ale dispozitivului de citire a cartelei fapt ce conferă un plus
de 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 la
ramburs, 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ă o
sumă 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ătorul
emite un cec fără acoperire. În ciuda acestui dezavantaj, există la ora actuală un număr destul de mare de
magazine 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. Prin
intermediul 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, mai
ales în tranzacţiile între persoane juridice.
Plata ramburs care este un sistem de expediere a mărfurilor, conform căruia destinatarul este
obligat să achite la primire, expeditorului, contravaloarea mărfii. Principalele dezavantaje ale acestui sistem
sunt 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ândirii
reduse 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 permite
cumpărătorului să-şi satisfacă nevoia de cumpărare de bunuri şi servicii, chiar dacă nu dispune la un anumit
moment de banii necesari. Prin folosirea cărţii de credit, riscul este transferat de la vânzător la instituţia
financară care a emis credit card-ul.
Plata prin cardul de credit se face astfel:
44
www.softnet.ro/library/files/papers/Introducere_in_Comert_electronic.pdf:
1.Deschidere
cont, bani reali
5.Produse, servicii
7.Bani reali
2.Bani reali 6.Bani
electronici
4.Bani
electronici
3.Bani
electronici
Emitent bani
reali
Emitent bani
electronici
Cumpărător Vânzător
Arhitectura unui sistem de plăţi electronice
105
1. cumpărătorul prezintă vânzătorului 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 credit
6. la sfârşitul lunii, cumpărătorul primeşte facturile pe care trebuie să le achite, astfel va plăti dobânda
pentru creditul acordat de banca ce a emis cartea de credit.
Bibliografie modul:
BUCHMANN ROBERT, Conceperea, proiectarea şi realizarea afacerilor pe Internet, Ed.
Risoprint, Cluj Napoca, 2004;
RUSU L., ARBA R., 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.Prentice
Hall, 2004
HOLDENER ANTHONY, Ajax: The Definitive Guide, O'Reilly, 2008;
RUSSELL MATHEW, Dojo: The Definitive Guide, O'Reilly, 2008;
RUSU LUCIA, BUCHMANN ROBERT, Proiectarea şi realizarea 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 comunicarea
asincronă dintre client și server a unor structure de date de tip text (XML sau JSON).
Analizor XML - Un program care verifică buna formare a unui document XML (vezi buna
formare); se poate considera că este atât emiţător, cât şi consumator XML, fiind de obicei un program
cu rol de intermediere. În unele situaţii, poate să nu fie intermediar, ci doar să indice utilizatorului
uman 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 al
documentului este formatarea.
Atribut XML - Componentă a unui marcator, poate să apară doar în eticheta sa de deschidere,
are nume şi valoare. Atributele sunt separate prin spaţii. Valorile atributelor sunt delimitate cu
ghilimele, care pot fi opţionale în unele limbaje de marcare.
Atribut de enumerare - Un atribut XML care este definit prin enumerarea valorilor sale
posibile.
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 conversia
codului sursă pe de o parte (parser) şi pentru a verifica buna formare şi validarea, pe de altă parte
(analizor + validator).
107
Atribut identificator - Un atribut XML de tip ID, utilizat la identificarea elementelor XML
care au acelaşi nume. Poate servi şi la construirea relaţiilor între elemente, prin conectarea cu un atribut
referinţă.
Atribut referinţă - Un atribut XML de tip IDREF, care face trimitere la un alt atribut (de tip
identitate) pentru a reflecta o 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 şi
navigarea documentelor XML.
Bună formare, document bine format (well-formed document) - Proprietatea unui
document de a fi de tip XML, adică de a nu încălca regulile limbajului XML, este o proprietate ce
trebuie verificată de către orice consumator XML (se recomandă şi emiţătorilor). Un document XML
nu este obligatoriu să aparţină unui vocabular, dar trebuie să fie bine format din punct de vedere
sintactic. Un exemplu de regulă de bună formare este imbricarea completă.
Cale XML - O 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 se
costruiesc aceste căi, dar se bazează pe metoda clasică de construcţie a căilor absolute sau relative ale
fişierelor.
CDATA - Date de tip caracter ce vor constitui valori de atribute.
Comentariu - Marcator special, de forma <!--text--> care conţine text ignorat în general de
procesoare 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 - un
identificator de client este suficient pentru obţinerea unei cantităţi mari de date relaţionate (produse
comandate, 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 procesare
ce indică versiunea limbajului XML folosit şi setul de caractere (UTF, ISO etc.) folosit în document.
Depozit XML - Echivalentul unei baze de date XML: o colecţie organizată de documente
XML 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 sau
metainformaţ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 considerate
consumatori sau generatori de documente.
DOM (Document Object Model) - Un model de date şi un tip de parsere care permit tratarea
documentelor XML ca pe arbori şi oferă metode de parcurgere facilă a nodurilor acestora. Are
dezavantajul că memorează întreg arborele în memoria internă a consumatorului.
DTD (Document Type Definition) - Un 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 de
reguli privind marcatorii, dar nu oferă reguli privind informaţia marcată.
Element - Componenta de bază a unui document XML, format din marcator (care dă numele
ş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 mod
similar cu apelul de variabile sau proceduri. În particular, pot fi apelate şi din DTD-ul în care au fost
declarate. Pe scurt entităţile analizabile sunt şiruri de caractere reutilizabile, de orice dimensiune, de la
un singur caracter la documente întregi.
108
Entităţi non-XML/neanalizabile (Unparsed entities) - Tipuri de informaţie apelate în
documente XML, dar care sunt neanalizabile din punct de vedere XML, deci valorile lor nu sunt
formate din text brut, ci fac trimitere la variate tipuri de fişiere (imagine, sunet, fişiere Word etc.).
Granularitate - Densitatea documentelor XML dintr-un depozit de date. Granularitate
ridicată implică un număr mare de documente de dimensiune redusă (uşor de manevrat) în depozitul de
date. 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 orice
element 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, model
folosit de parserele de tip DOM. Imbricarea asigură existenţa relaţiilor de descendenţă/apartenenţă între
elemente (elementul tată conţine elementul fiu).
Imbricare (nesting) - Proprietatea elementelor de a se conţine unele pe altele; aceasta se
asigură 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 unei
clase. În context XML, o instanţă este un exemplu de document care respectă regulile unui
vocabular/limbaj.
Instanţiere - Un tip particular de specializare, prin care, dintr-o clasă de obiecte cu proprietăţi
generale 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ă este
un timp complex de obiecte, ori că un obiect face parte dintr-o anumită clasă. În context XML, orice
limbaj/vocabular este o clasă sau tip de documente iar documentele care respectă regulile unui
limbaj/vocabular sunt obiecte/instanţe ale limbajului/vocabularului. De aici provine şi prescurtarea
DTD - 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 acele
documente care trebuie validate faţă de un vocabular DTD. Marcatorul precizează numele elementului
ră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 de
incluziune/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ă caracterul
deschis al modelului XML: un element sau un atribut se creează doar atunci când există o valoare pe
care 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ă anumite
câ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, imbricare
completă). Parserele convertesc în general fiecare element într-un nod. Există parsere care convertesc şi
atributele 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ţie
neanalizabil (care nu trebuie tratat ca text brut) dar care poate fi referit în documente XML, prin
atribute de tip entitate. Receptorul este responsabil cu identificarea aplicaţiei cu care se va deschide
informaţ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 element
reprezintă 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 mai
frecvent folosite sunt DOM şi SAX. Uneori, parserele asigură şi procesul de validare.
Parsing - Activitatea unui parser. În numeroase cazuri, include şi activitatea analizorului. Mai
rar (din 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ţine
atribute 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 sau
documentele care memorează XML, deci un procesor XML este un program care acceptă date de
intrare în format XML.
Producător XML - Un tip particular de emiţător XML, care este responsabil şi cu producerea
codului 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ă cod
sursă XML.
Redundanţa - fenomenul prin care anumite date se repetă într-o bază de date. În modelul
relaţ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ţia
ce va fi conţinută în potenţialele documente. O schemă XML este construită cu limbajul standard XML
Schema care este, la rândul său, un vocabular XML cu un scopul indicat aici.
SGML (Standard Generalized Markup Language??) - Limbajul care a consacrat
marcatorii de forma <nume marcator>, din care s-au dezvoltat, prin specializare, limbaje ca XML şi
HTML. Conform acestui tip de limbaje, tot ce apare între paranteze 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 atribute
cu 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 unui
vocabular XML dat.
Vocabular - tip de document XML. Un vocabular indică toate regulile de construire a
documentelor XML comunicate între un emiţător şi un receptor, poate fi considerat un contract între
cele două părţi care comunică. Vocabularul poate fi impus fie de emiţător, fie de receptor. Metodele
clasice de construire a unui vocabular sunt DTD şi schemele XML (vezi DTD, Schema XML). Un
document XML nu trebuie obligatoriu să aparţină unui vocabular, dar vocabularele asigură caracterul
extensibil al XML, adică posibilitatea de a crea sublimbaje pentru diferite tipuri de probleme, cu proprii
marcatori şi propriile reguli, care să fie acceptate apoi de către toţi cei implicaţi în problemele
respective.
110
XML (Extensible Markup language) - Limbajul extensibil de marcare. Trăsăturile sale
definitorii 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 de
folosire 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. A
obţinut titlul de doctor în anul 2004, în domeniul Cibernetică şi Statistică Economică, cu teza
Contribuţii la conceperea, proiectarea şi realizarea afacerilor pe Internet, sintetizată în volumul
cu 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ţă în
cadrul aceleiaşi facultăţi, absolvind secţia de Informatică Economică. În anul 2006 a reprezentat
facultatea la XML Summer School la Universitatea Oxford.
Domeniile sale de expertiză sunt modelele de aplicaţii Web pentru afaceri electronice, în special
cele bazate pe XML, şi managementul calităţii software. În aceste domenii, a condus două granturi
câştigate prin competiţie naţională: grantul doctoral Cercetări legate de modelarea şi
implementarea comerţului electronic (finanţat de CNCSIS prin programul TD) şi grantul
postdoctoral Regândirea comerţului electronic – o abordare în sensul omogenităţii (finanţat de
MCT prin programul CEEX).A participat ca membru în alte 10 granturi conduse de membrii
catedrei, a publicat 2 cărţi de unic autor şi capitole în alte 11 cărţi cu mai mulţi autori, precum şi
numeroase articole şi comunicări la conferinţe din ţară şi străinătate.
Recommended
