Noutati despre interfete web si interfete evoluate

Se afișează postările cu eticheta advanced. Afișați toate postările
Se afișează postările cu eticheta advanced. Afișați toate postările

marți, 23 decembrie 2008

Tema 3 nu e chiar simpla :)


Anu' trecut, cu ceva intarziere, am facut si eu tema 3. Nu a fost grea, insa e foarte amuzant ca pare simpla, dar creeaza niste probleme destul de mari. Acuma, nah, evident, puteai sa alegi sa te lupti cu aceste probleme sau sa sari peste ele. M-am uitat si pe la alti colegi ca sa vad cum au rezolvat si... se pare ca s-au dus pe varianta usoara...

Pe scurt, tema 3 cere sa se realizeze un mic script Javascript care sa permita evidentierea unor cuvinte intr-o pagina data, care se afla la aceeasi locatie ca si fisierul curent. Scurt si la obiect. Pe deasupra, se mai da ca exemplu si utilizarea optiunii de afisare din cache pe care o ofera motorul de cautare Google. Evident, ca un mic bonus se cere sa se utilizeze AJAX.

Insa, de aici incep problemele. Io am alex AJAX. Fix in acest moment am dat cu capul de perete. Motivul il reprezinta restrictiile de securitate impuse de browser-ele din zilele noastre. Mai exact, browser-ele nu prea permit incarcarea fisierelor locale prin intermediul unor scripturi locale. Evident, logica e simple: se incearca evitarea cazurilor de acces neautorizat.

Varianta mea de rezolvare a temei 3 poate fi gasita pe site-ul nostru, http://www.interfete-evoluate.eu/ .

Problema cea mai mare este cauzata de faptul ca browserele permit incarcarea prin Javascript doar a fisierelor care sunt in acelasi domeniu de securitate cu fisierul initial. Mai exact, un script de pe site-ul http://www.microsoft.com/ poate incarca doar un alt script/fisier care se afla pe acelasi site. Ca o situatie particulara, fisierele locale pot incarca alte fisiere locale doar cu acordul utilizatorului (in Firefox) sau nu pot incarca deloc alte fisiere locale (Internel Explorer).

Detalii despre aceste restrictii de securitate in Internet Explorer 7 pot fi gasit la adresa: http://msdn.microsoft.com/en-us/library/ms537505(VS.85).aspx

Pentru a rezolvat problema in Firefox 3, solutia e relativ simpla: adaugati un apel ca cel de mai jos, care informeaza browser-ul ca sunt necesare drepturi suplimentare (la randul sau, browser-ul va cere utilizatorului sa confirme faptul ca doreste sa acorde aceste drepturi):

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead UniversalFileRead");

Ionut

Read more...

duminică, 14 decembrie 2008

Speed of Browsers


Intr-un articol anterior vorbeam despre Web Workers. Pe scurt, "Web Workers"-ii reprezinta o modalitate prin care un script Javascript poate beneficia de facilitatile de multithreading oferite de sistemul de operare.

Motivul pentru care a aparut acest API (practic, utilizarea acestor facilitati se face prin intermediul unor functii disponibile in Javascript) il reprezinta dorinta utilizatorilor de a avea aplicatii web cat mai rapide, precum si dorinta programatorilor de a putea face aplicatii care sa ofere functii cat mai "dragute". Vezi Google Orice (Docs, Gmail etc.).

In ziua de azi, din ce in ce mai multe site-uri ofera continut care foloseste foarte mult facilitatile oferita de Javascript. Din aceasta cauza, baietii de la Google Chrome s-au gandit ca o dezvoltare logica a browser-elor inseamna marirea vitezei cu care se executa/interpreteaza codul Javascript. Astfel, in Chrome vine cu cateva lucruri diferite fata de alte browsere:
  1. fiecare tab ruleaza intr-un proces separat, in care codul Javascript poate rula in thread-uri separate. La pornirea Google Chrome se creaza un proces principal, de control, iar fiecare tab deschise duce la crearea unui nou proces. In felul acesta, un tab care face niste procesari intense nu afecteaza in niciun fel celelalte tab-uri;
  2. codul Javascript este compilat direct in cod binar specific masinii pe care ruleaza browserul. In Firefox 3, Javascript-ul este adus la forma unui limbaj intermediar (bytecode), dupa care este compilat la nevoie (oarecum asemanator cu ce se intampla in cazul Java). Firefox 3.1 are un mod diferit, despre care am sa vorbesc mai jos;
  3. Javascript-ul nu are suport direct pentru clase. Cei de la Chrome au introdus o notiune noua (hidden classes), prin care permit reutilizarea codului intr-un mod asemanator cu cel din limbajele de programare normala. Plus ca apare si un Garbage Collector...
(Detalii suplimentare despre V8, motorul Javascript al Chrome-ului gasiti la adresa: http://code.google.com/p/v8/)

Baietii de la Google au fost destul de destepti cand au luat decizia de a face un browser mai rapid. Nu neaparat pentru ca lor le-a iesit un produs bun, dar pentru ca au impins din spate ceilalti producatori.

Astfel se face ca cei de la Mozilla au facut o mica modificare in Firefox 3.1, care aduce un plus destul de important de viteza. Motorul Javascript din Firefox 3.1 nu mai este SpiderMonkey. El a fost inlocuit cu TraceMonkey, care foloseste o alta metoda de "interpretare" a codului. Practic, acesta nu mai genereaza un graf de control al fluxului (Control flow graph - CFG) in sensul clasic, si, in felul acesta, nu compileaza tot codul la inceput (ca Google Chrome) si nici nu aduce tot codul intr-un limbaj intermediar (ca Firefox 3.0.1). In felul acesta, se pot obtine pe alocuri viteze de circa 30 de ori mai mari decat in forma clasica. TraceMonkey foloseste trace-trees, despre gare gasiti mai multe detalii aici: http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-12.pdf


To be continued...


Ionut

Read more...

miercuri, 10 decembrie 2008

Testele ACID2 si browser-ele

Din pacate pentru colegii mei, nu am idei care sa fie legate in mod direct de interfetele web. Insa...

Astazi am avut niste probleme de layout intr-o aplicatie. Cautand pe net sa vad care-i problema, am dat peste o chestie interesanta, de care simt nevoia sa spun si altora.

Toata lumea stie ca browserele afiseaza in mod diferit aceeasi pagina. Motivul se datoreaza faptului ca fiecare browser are un motor diferit (afirmatie oarecum valabila deoarece exista motoare care se regasesc in mai multe browsere - ex. Gecko se gaseste in Firefox, Camino, Netscape si Thunderbird (stiu ca asta nu e browser)). Evident, fiecare motor e mai mult sau putin compliant cu standardele asa ca apar diferente.

Insa, ceea ce nu stiam este faptul ca exista un test care iti poate arata cat de compliant este un browser cu standardul CSS3. Pe scurt, va duceti la URL-ul: http://www.webstandards.org/files/acid2/test.html, si faceti testul.

Mai multe detalii gasiti aici: http://en.wikipedia.org/wiki/Acid2


Ionut


UPDATE: Cristi a semnalat printr-un comentariu faptul ca am facut o greseala in articol: ACID2 este pentru CSS2, nu CSS3... Mea culpa...

Read more...

Web Workers

Am sa incep cu un disclaimer: acest post nu reprezinta o insiruire a unor idei personale. Mai degraba, am gasit niste lucruri pe net despre care consider ca ar putea fi utile si altor persoane, asa ca m-am gandit sa le public aici.

Azi am aflat ca a aparut un nou beta al browser-ului Firefox 3.1. Ca un programator curios, m-am dus si io pe site-ul lor ca sa vad ce lucruri noi aduce aceasta versiune. Printre chestiile insiruite se afla si informatii despre acesti "Web Workers". In fapt, un web worker este un "thread" (pun ghilimele deoarece notiunea de thread nu este neaparat identica cu ce se intelege prin thread intr-un sistem de operare) care executa cod Javascript.

In acest articol exista mai multe informatii despre partea cu Web Workers in Firefox 3.1. Partea cea mai interesanta o reprezinta acel cod Javascript a carui executie, chiar dureaza ceva timp...

Detalii suplimentare despre Web Workers gasiti pe site-ul: http://www.whatwg.org/specs/web-workers/current-work/

Ca observatie Web Worker-ii nu sunt specifici Firefox. http://www.whatwg.org/ sunt cei care se ocupa de intretinerea HTML.


Ionut

Read more...

joi, 20 noiembrie 2008

Adunarea a doua siruri in Java

La cererea expresa a lui Florin si contrar vointei acestuia, subiectul primului meu post pentru proiectul de la cursul Interfete Evoluate va fi despre un lucru aparent banal: concatenarea a doua siruri in Java.

Operatia de adunare (concatenare) a doua siruri este una foarte raspandita in aplicatiile Java normale. Insa aceasta creaza probleme din cauza faptului ca obiectul String este imutabil. Practic, din adunarea a doua obiecte de tip String, va rezulta o noua instanta, complet diferita de primele doua. In codul compilat (adica in fisierul .class), acest lucru se face prin instantierea clasei StringBuilder si apelarea metodei append. Mai exact, daca vom scrie intr-o functie urmatoarea secventa de cod:


String s1 = "a";
String s2 = "b";
String s3 = s1 + s2;


Ea va fi compilata in:

String s1 = "a";
String s2 = "b";
String s3 = (new StringBuilder(String.valueOf(s1))).append(s2).toString();


Ca observatie, StringBuilder-ul este folosit doar de la Java 1.5. In versiunile mai vechi (care, din pacate inca se mai intalnesc...) se utilizeaza StringBuffer.

Este evident faptul ca apelul String.valueOf este inutil deoarece s1 este nenul (valueOf cu parametru de tip Object, intoarce sirul "null" daca parametrul este nul sau apeleaza functia toString() a obiectului daca acesta este nenul). De asemenea, in cazul in care o asemenea operatie se face des, cum ar fi intr-un ciclu, atunci este mai bine sa se reutilizeze instanta StringBuilder. Mai exact, daca avem urmatoarea secventa de cod:

for (int i=0; i<100; i++) {
String s1 = "a";
String s2 = "b";
String s3 = s1 + s2;
}

ea va fi compilata in:

for (int i=0; i<100; i++) {
String s1 = "a";
String s2 = "b";
String s3 = new StringBuilder(String.valueOf(s1)).append(s2).toString();
}

Evident, acest cod poate fi optimizat in felul urmator (facem abstractie de modul in care functioneaza instantierea obiectelor in Java):

StringBuilder buffer = new StringBuilder();
for (int i=0; i<100; i++) {
String s1 = "a";
String s2 = "b";
buffer.setLength(0);
String s3 = buffer.append(s1).append(s2).toString();
}


Ca incheiere, vreau sa mai adaug doar ca incepand cu Java 1.5, StringBuilder si StringBuffer au un parinte comun, AbstractStringBuilder (aici ma refer la JDK-ul de la Sun). Practic, in clasa abstracta sunt implementate toate operatiile, iar StringBuilder si StringBuffer actioneaza doar ca niste wrapper-e. Diferenta dintre cele doua clase este data de faptul ca StringBuffer este thread-safe deoarece apelurile sale sunt marcate ca synchronized.

Ionut

Read more...

Arhivă blog