Thursday, July 24, 2008
MyEtymology
Striving to be a universal etymological dictionary, myetymology.com provides an etymology for hundreds of thousands of words in dozens of languages, tracing their etymology to Latin, Greek or reconstructed Proto-Germanic and Indo-European roots.
Wednesday, January 16, 2008
PageRank
Page rank-ul este o valoare numerica ce reprezinta importanta unei pagini pe web. Faptul ca o pagina contine un link catre alta pagina, acest lucru e ca un vot acordat
paginii referite prin link de catre pagina ce contine linkul. Cu cat o pagina strange mai multe voturi/e referita de mai multe ori, cu atat mai importanta devine pagina. Concomitent, daca o pagina are un pange rank mare/este importanta, atunci creste si importanta voturilor pe care ea le acorda.
PangeRanku-ul este o notiune semnificativa pentru Google, pentru ca prin intermediul ei, si nu numai, Google decide importanta paginilor.
NU toate linkurile sunt luate in considerare de google, in special cele de pe link farms-urile stiute de Google, iar faptul ca un link al unui site se afla pe una din aceste siteuri tip link farm, poate duce la penalizarea siteului de catre Google.
Cum se calculeaza PageRank-ul?
Pentru calcularea PR-ului unui site, se iau in considerare toate linkurile care fac referire la situl in cauza.
Ecuatia care calculeaza PR-ul este:
PR(A) = (1-d) + d(PR(t1)/C(t1) + ... + PR(tn)/C(tn)),
in care t1 ... tn sunt paginile care au link catre pagina A, C este numarul de linkuri pe care pagina le are in continutul ei, iar d este o constanta -damping factor- de obicei cu valoarea 0.85 .
paginii referite prin link de catre pagina ce contine linkul. Cu cat o pagina strange mai multe voturi/e referita de mai multe ori, cu atat mai importanta devine pagina. Concomitent, daca o pagina are un pange rank mare/este importanta, atunci creste si importanta voturilor pe care ea le acorda.
PangeRanku-ul este o notiune semnificativa pentru Google, pentru ca prin intermediul ei, si nu numai, Google decide importanta paginilor.
NU toate linkurile sunt luate in considerare de google, in special cele de pe link farms-urile stiute de Google, iar faptul ca un link al unui site se afla pe una din aceste siteuri tip link farm, poate duce la penalizarea siteului de catre Google.
Cum se calculeaza PageRank-ul?
Pentru calcularea PR-ului unui site, se iau in considerare toate linkurile care fac referire la situl in cauza.
Ecuatia care calculeaza PR-ul este:
PR(A) = (1-d) + d(PR(t1)/C(t1) + ... + PR(tn)/C(tn)),
in care t1 ... tn sunt paginile care au link catre pagina A, C este numarul de linkuri pe care pagina le are in continutul ei, iar d este o constanta -damping factor- de obicei cu valoarea 0.85 .
Tuesday, January 15, 2008
Un program Google in Java
Exista un API pentru programarea cu Google in java, care se numeste googleapi.jar si care permite trimiterea de query-uri catre google si primirea/interpretare rezultatelor. Pentru toata aceasta operatiune este nevoie doar de downloadarea jar-ului
si de obtinerea unui google API developer key, ce trebuie inclus/folosit in aplicatie.
Aceasta cheie se obtine de la selectand tipul "installed applications" si este nevoie doar de un cont pe Google pentru toata aceasta operatiune.
In continuare dau un exemplu de folosire a acestui API, reprezentat printr-o clasa
ce trimite un query primit din linia de comanda catre google si afiseaza apoi rezultatele primite:
import com.google.soap.search.GoogleSearch;
import com.google.soap.search.GoogleSearchFault;
import com.google.soap.search.GoogleSearchResult;
import com.google.soap.search.GoogleSearchResultElement;
public class GoogleQueryExample {
// google api developer key
private static String googleKey =
"ABQIAAAAS...................................................................................";
public static void main(String[] args) {
// e necesat un query de cautat dat in linia de comanda
if (args.length != 1) {
System.err.println("query");
System.exit(1);
}
// obiect GoogleSearch
GoogleSearch s = new GoogleSearch();
try {
s.setKey(googleKey);
s.setQueryString(args[0]); /* Google query din linia de comanda */
s.setMaxResults(10);
// query la google
GoogleSearchResult r = s.doSearch();
// preia rezultatele
GoogleSearchResultElement[] re = r.getResultElements();
// afisare rezultate
for (int i = 0; i < re.length; i++) {
String title = re[i].getTitle();
String URL = re[i].getURL();
String snippet = re[i].getSnippet();
// inlatura tagurile html
title = title.replaceAll("<[^>]+>", "");
snippet = snippet.replaceAll("<[^>]+>", "");
// afisare propriuziza
System.out.println(title);
System.out.println(URL);
System.out.println(snippet + "\\n");
}
} catch (GoogleSearchFault f) {
System.out.println("Exceptie GoogleSearchFault: " + f.toString());
}
}
}
si de obtinerea unui google API developer key, ce trebuie inclus/folosit in aplicatie.
Aceasta cheie se obtine de la selectand tipul "installed applications" si este nevoie doar de un cont pe Google pentru toata aceasta operatiune.
In continuare dau un exemplu de folosire a acestui API, reprezentat printr-o clasa
ce trimite un query primit din linia de comanda catre google si afiseaza apoi rezultatele primite:
import com.google.soap.search.GoogleSearch;
import com.google.soap.search.GoogleSearchFault;
import com.google.soap.search.GoogleSearchResult;
import com.google.soap.search.GoogleSearchResultElement;
public class GoogleQueryExample {
// google api developer key
private static String googleKey =
"ABQIAAAAS...................................................................................";
public static void main(String[] args) {
// e necesat un query de cautat dat in linia de comanda
if (args.length != 1) {
System.err.println("query");
System.exit(1);
}
// obiect GoogleSearch
GoogleSearch s = new GoogleSearch();
try {
s.setKey(googleKey);
s.setQueryString(args[0]); /* Google query din linia de comanda */
s.setMaxResults(10);
// query la google
GoogleSearchResult r = s.doSearch();
// preia rezultatele
GoogleSearchResultElement[] re = r.getResultElements();
// afisare rezultate
for (int i = 0; i < re.length; i++) {
String title = re[i].getTitle();
String URL = re[i].getURL();
String snippet = re[i].getSnippet();
// inlatura tagurile html
title = title.replaceAll("<[^>]+>", "");
snippet = snippet.replaceAll("<[^>]+>", "");
// afisare propriuziza
System.out.println(title);
System.out.println(URL);
System.out.println(snippet + "\\n");
}
} catch (GoogleSearchFault f) {
System.out.println("Exceptie GoogleSearchFault: " + f.toString());
}
}
}
Wednesday, December 5, 2007
XML-RPC
XML-RPC
Prin XML-RPC java capata niste functionalitati pe care nu le are prin RMI. XML-RPC e mult mai light decat RMI-ul din java, pasandu-se mai degraba parametri decat obiecte spre server.
Daca RMI necesita compilarea interfetelor pentru a se cunoaste metodele premise spre apelare, XML-RPC permite clientului sa specifice ce metode vrea sa foloseasca si se cauta handleri pentru aceste metode. Referinta la obiectele de pe server se fac prin nume si nu exista stub ca la RMI.
Exemplu de client-server care foloseste jarurile xmlrpc 3.1 de la
http://mirror.nyi.net/apache/ws/xmlrpc/binaries/ (Apache)
Clientul:
Serverul:
Prin XML-RPC java capata niste functionalitati pe care nu le are prin RMI. XML-RPC e mult mai light decat RMI-ul din java, pasandu-se mai degraba parametri decat obiecte spre server.
Daca RMI necesita compilarea interfetelor pentru a se cunoaste metodele premise spre apelare, XML-RPC permite clientului sa specifice ce metode vrea sa foloseasca si se cauta handleri pentru aceste metode. Referinta la obiectele de pe server se fac prin nume si nu exista stub ca la RMI.
Exemplu de client-server care foloseste jarurile xmlrpc 3.1 de la
http://mirror.nyi.net/apache/ws/xmlrpc/binaries/ (Apache)
Clientul:
import java.net.URL;
import java.util.*;
import org.apache.xmlrpc.client.XmlRpcClient;
import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;
public class Client {
public static void main (String [] args) {
try {
XmlRpcClient server = new XmlRpcClient();
XmlRpcClientConfigImpl cnf = new XmlRpcClientConfigImpl();
cnf.setServerURL(new URL("http://localhost/RPC2"));
server.setConfig(cnf);
Vector params = new Vector();
params.addElement(new Integer(17));
params.addElement(new Integer(13));
Object result = server.execute("sample.sum", params);
int sum = ((Integer) result).intValue();
System.out.println("The sum is: "+ sum);
} catch (Exception exception) {
System.err.println("JavaClient: " + exception);
}
}
}
Serverul:
import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.server.XmlRpcServer;
import org.apache.xmlrpc.server.XmlRpcServerConfigImpl;
import org.apache.xmlrpc.webserver.WebServer;
public class Server {
public Integer sum(int x, int y) {
return new Integer(x+y);
}
public static void main (String [] args) {
try {
System.out.println("starting XML-RPC Server...");
WebServer server = new WebServer(80);
PropertyHandlerMapping map = new PropertyHandlerMapping();
map.addHandler("sample", Server.class);
XmlRpcServerConfigImpl cnf = new XmlRpcServerConfigImpl();
XmlRpcServer srv = server.getXmlRpcServer();
srv.setConfig(cnf);
srv.setHandlerMapping(map);
server.start();
System.out.println("Started successfully.");
} catch (Exception exception) {
System.err.println("JavaServer: " + exception);
}
}
}
Tuesday, December 4, 2007
RMI – Remote Method Invocation
Prin RMI se poate apela cod de la distanta – metode ale obiectelor aflate pe un server pot fi apelate de clienti.
Stubs si Skeletons
Clientul cand doreste sa apeleze o metoda de la distanta, o apeleaza in mod oarecum transparent (apelul se face asupra unui obiect de tip stub). Stubul este un obiect ce se afla pe client. Rolul stubului este de a incapsula informatii ca parametrii metodei care se va apela pe server precum obiectul si metodele ce se vor apela. Pachetul trimis de client ajunge la server. Aici se afla un alt obiect, skeleton caruia ii revine rolul sa decodifice parametrii, sa apeleze metoda invocata de client, sa retina valoare returnata/sau exceptia si sa trimita inapoi un pachet cu rezultatul.
Exemplu de aplicatie care foloseste RMI
Serverul va creea un obiect Hello si clientul apeleaza o metoda a obiectului creeat pe server. Pentru a sti ce metoda a obiectului sa poate apela, clientul trebuie sa aiba la dispozitie o interfata cu aceste metode, interfata ce este implementata de obiectul de pe server. Aceasta interfata se afla atat pe server cat si pe client. Aceasta este :
Dupa cum se vede , aceasta interfata extinde interfata Remote – ca de altfel toate interfetele care sunt implementate de obiecte aflate la distanta, iar metodele interfetelor pot arunca RemoteException.
Clasa Hello implementeaza interfata HelloInterface:
Singura metoda disponibila apelabila de catre client este say(); Hello extinde clasa UnicastRemotObject, care extinde la randul ei RemoteObject, astfel ca Hello e o clasa accesibila de la distanta.

Clasele care vor fi instantiate pe parte de server extinzand UnicastRemoteObject, extind implicit RemoteServer. RMI returneaza clientului o referinta la obiectul de pe server si nu obiectul propriuzis -> e necesar un mecanism de localizare/inregistrare a unui obiect existent pe server. Pe server inregistrarea obiectului se face cu bind(), iar clientul obtine o referinta a obiectului de pe server cu metoda lookup().
Pornire serviciului de inregistrare se face executand start rmregistry (rmiregistry & pe linux), cu portul implicit 1099.
rmic ne ajuta la generarea claselor skeleton si stub (Hello_Skel.class, Hello_Stub.class) .
Clientul:
Serverul:
Stubs si Skeletons
Clientul cand doreste sa apeleze o metoda de la distanta, o apeleaza in mod oarecum transparent (apelul se face asupra unui obiect de tip stub). Stubul este un obiect ce se afla pe client. Rolul stubului este de a incapsula informatii ca parametrii metodei care se va apela pe server precum obiectul si metodele ce se vor apela. Pachetul trimis de client ajunge la server. Aici se afla un alt obiect, skeleton caruia ii revine rolul sa decodifice parametrii, sa apeleze metoda invocata de client, sa retina valoare returnata/sau exceptia si sa trimita inapoi un pachet cu rezultatul.
Exemplu de aplicatie care foloseste RMI
Serverul va creea un obiect Hello si clientul apeleaza o metoda a obiectului creeat pe server. Pentru a sti ce metoda a obiectului sa poate apela, clientul trebuie sa aiba la dispozitie o interfata cu aceste metode, interfata ce este implementata de obiectul de pe server. Aceasta interfata se afla atat pe server cat si pe client. Aceasta este :
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface HelloInterface extends Remote {
public String say() throws RemoteException;
}
Dupa cum se vede , aceasta interfata extinde interfata Remote – ca de altfel toate interfetele care sunt implementate de obiecte aflate la distanta, iar metodele interfetelor pot arunca RemoteException.
Clasa Hello implementeaza interfata HelloInterface:
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class Hello extends UnicastRemoteObject implements HelloInterface {
private static final long serialVersionUID = 7896795898928782846L;
private String message;
public Hello (String msg) throws RemoteException {
message = msg;
}
public String say() throws RemoteException {
return message;
}
}
Singura metoda disponibila apelabila de catre client este say(); Hello extinde clasa UnicastRemotObject, care extinde la randul ei RemoteObject, astfel ca Hello e o clasa accesibila de la distanta.

Clasele care vor fi instantiate pe parte de server extinzand UnicastRemoteObject, extind implicit RemoteServer. RMI returneaza clientului o referinta la obiectul de pe server si nu obiectul propriuzis -> e necesar un mecanism de localizare/inregistrare a unui obiect existent pe server. Pe server inregistrarea obiectului se face cu bind(), iar clientul obtine o referinta a obiectului de pe server cu metoda lookup().
Pornire serviciului de inregistrare se face executand start rmregistry (rmiregistry & pe linux), cu portul implicit 1099.
rmic ne ajuta la generarea claselor skeleton si stub (Hello_Skel.class, Hello_Stub.class) .
Clientul:
import java.rmi.Naming;
public class Client {
public static void main (String[] argv) {
try {
HelloInterface hello = (HelloInterface) Naming.lookup ("//localhost/Hello");
System.out.println (hello.say());
} catch (Exception e) {
e.printStackTrace();
System.out.println ("HelloClient exception: " + e);
}
}
}
Serverul:
import java.rmi.Naming;
public class Server {
public static void main (String[] argv) {
try {
Naming.rebind ("Hello", new Hello ("Hello, world!"));
System.out.println ("Hello Server is ready.");
} catch (Exception e) {
e.printStackTrace();
System.out.println ("Hello Server failed: " + e);
}
}
}
XHTML
XHTML - EXtensible HyperText Markup Language
XHTML este compatibil cu HTML 4.01.
Toate browserele noi au support pentru XHTML.
XHTML este un limbaj care foloseste markere si are aceeasi putere de expresie ca si HTML dar mai are in plus un avantaj, acela de a respecta sintaxa XML.
Pe cand HTML este o aplicatie de tip SGML (Standard Generalized Markup Language), care este un limbaj foarte flexibil, XHTML este o aplicatie a XML care este un subset mult mai restrictiv al SGML.
Documentele XHTML trebuie sa fie bine formate, de aceea ele permit ca procesarea automata sa fie facuta cu unelte standard XML, spre deosebire de HTML care necesita un parser destul de complex, tolerant si personalizat.
XHTML poate fi gandit ca intersectia HTML cu XML, pentru ca chiar a fost gandit ca o reformulare a HTML in XML. XHTML a devenit o recomandare a W3C (World Wide Web Consortium) pe 26 ianuarie 2000. Versiunea XHTML 1.1 a devenit recomandare a W3C pe 31 mai 2001. XHTML poate fi considerat a fi succesorul HTML.
Nevoia de reformulare a versiunii HTML a fost simtita datorita faptului ca informatiile World Wide Web trebuiau furnizate mai multor tipuri de dispozitive mobile (telefoane mobile, PDA-uri etc) diferite de cele traditionale desktop, unde nu puteau fi dezvoltate resursele suplimentare de care HTML avea nevoie. In practica totusi browserele care suportau HTML pentru astfel de dipozitive s-au dezvoltat mai repede decat suportul de XHTML pentru browserele traditionale de desktop.
Un alt motiv care facea atractiva noua tehnologie a XHTML era faptul ca se reducea cererea de parsere si agenti de utilizare. Cu HTML, agentii de utilizare (motoarele de cautare gen Google :) si restul) aveau sarcina dificila de a corecta erorile documentelor publicate. Aici XML aducea un suflu nou pentru ca cerea agentilor de utilizare sa dea o eroare fatala la intalnirea unui document XML gresit formatat. Aceasta inseamna ca un browser XHTML poate teoretic sa omita codul de recuperare din eroare, chiar daca are nevoie de mai multe verificari de detectie a erorilor. Recomandarea ca browserele sa posteze o eroare mai degraba decat sa incerce sa repare un continut gresit formatat ar trebui sa ajute la eliminarea greselilor din aceste documente. Chiar si atunci cand autorii nu isi valideaza codul, la un simplu test intr-un browser XML, erorile critice ale documentului vor fi scoase la iveala si astfel vor fi mai usor de corectat.
O caracteristica speciala a XHTML mostenita din XML sunt namespace-urile. Cu ajutorul acestor namespace-uri, autorii si comunitatile isi pot defini propriile elemente XML, atribute si modele de continut pe care le pot insera in documentele XHTML. Acest lucru este similar cu flexibilitatea semantica a atributului "class" intr-un element HTML, dar cu mai putine restrictii. Anumite namespace-uri/scheme W3C XML care pot fi incluse in XHTML, includ MathML pentru marcarea semanticii matematice, Scalable Vector Graphics pentru marcarea vectorilor grafici si RDFa pentru includerea datelor RDF.
Schimbarile de la HTML la XHTML versiunea 1.0 sunt foarte mici si sunt in principal facute pentru a asigura compatibilitatea cu XML. Cea mai importanta schimbare este aceea ca documentele sa fie bine formate si ca toate elementele sa fie inchise in mod explicit asa cum cere standardul XML. In XML toate numele de elemente si atribute sunt case-sensitive, astfle incat XHTML a abordat aceasta problema prin a defini toate numele tagurilor ca fiind lowercase.
In XHTML toate valorile atributelor trebuie inchise intre apostrofuri sau ghilimele in contrast cu HTML unde numai valorile de tip string trebuiau inchise cu ghilimele, valorile numerice sau booleene erau scrise pur si simplu, fara ghilimele.
In XHTML toate elementele trebuie sa fie inchise in mod explicit, inclusiv elementele goale cum ar fi img sau br: <img> si <br>.
XHTML 1.1 - este cea mai recenta recomandare W3C. Prezentarea este controlata numai de Cascading Style Sheets (CSS). Aceasta versiune a XHTML permite deasemenea folosirea de caractere de marcare ruby pentru limbile est-asiatice.
Modularizarea XHTML permite refolosirea unor mici chunkuri de XHTML de catre alte aplicatii XML intr-o maniera bine definita si permite extinderea XHTML in scopuri specializate.
XHTML 1.1 adauga conceptul de stricta conformitate a documentelor: astfel ca un document nu poate angaja anumite caracteristici, trebuie sa fie un document complet care contine numai elementele definite in modulele cerute de XHTML 1.1.
XHTML 2.0 in 2007 este inca in lucru dar este deja controversat pentru ca se desprinde de compatibilitatea backward cu versiunile anterioare.
XHTML 2.0 poate fi parsat in acelasi fel in care un agent utilizator ar parsa XHTML 1.1, folosind un parser XML si un document CSS conform cu specificatiile versiunii noi 2.0.
Noile add-uri aduse de XHTML 2.0 sunt:
XHTML este compatibil cu HTML 4.01.
Toate browserele noi au support pentru XHTML.
XHTML este un limbaj care foloseste markere si are aceeasi putere de expresie ca si HTML dar mai are in plus un avantaj, acela de a respecta sintaxa XML.
Pe cand HTML este o aplicatie de tip SGML (Standard Generalized Markup Language), care este un limbaj foarte flexibil, XHTML este o aplicatie a XML care este un subset mult mai restrictiv al SGML.
Documentele XHTML trebuie sa fie bine formate, de aceea ele permit ca procesarea automata sa fie facuta cu unelte standard XML, spre deosebire de HTML care necesita un parser destul de complex, tolerant si personalizat.
XHTML poate fi gandit ca intersectia HTML cu XML, pentru ca chiar a fost gandit ca o reformulare a HTML in XML. XHTML a devenit o recomandare a W3C (World Wide Web Consortium) pe 26 ianuarie 2000. Versiunea XHTML 1.1 a devenit recomandare a W3C pe 31 mai 2001. XHTML poate fi considerat a fi succesorul HTML.
Nevoia de reformulare a versiunii HTML a fost simtita datorita faptului ca informatiile World Wide Web trebuiau furnizate mai multor tipuri de dispozitive mobile (telefoane mobile, PDA-uri etc) diferite de cele traditionale desktop, unde nu puteau fi dezvoltate resursele suplimentare de care HTML avea nevoie. In practica totusi browserele care suportau HTML pentru astfel de dipozitive s-au dezvoltat mai repede decat suportul de XHTML pentru browserele traditionale de desktop.
Un alt motiv care facea atractiva noua tehnologie a XHTML era faptul ca se reducea cererea de parsere si agenti de utilizare. Cu HTML, agentii de utilizare (motoarele de cautare gen Google :) si restul) aveau sarcina dificila de a corecta erorile documentelor publicate. Aici XML aducea un suflu nou pentru ca cerea agentilor de utilizare sa dea o eroare fatala la intalnirea unui document XML gresit formatat. Aceasta inseamna ca un browser XHTML poate teoretic sa omita codul de recuperare din eroare, chiar daca are nevoie de mai multe verificari de detectie a erorilor. Recomandarea ca browserele sa posteze o eroare mai degraba decat sa incerce sa repare un continut gresit formatat ar trebui sa ajute la eliminarea greselilor din aceste documente. Chiar si atunci cand autorii nu isi valideaza codul, la un simplu test intr-un browser XML, erorile critice ale documentului vor fi scoase la iveala si astfel vor fi mai usor de corectat.
O caracteristica speciala a XHTML mostenita din XML sunt namespace-urile. Cu ajutorul acestor namespace-uri, autorii si comunitatile isi pot defini propriile elemente XML, atribute si modele de continut pe care le pot insera in documentele XHTML. Acest lucru este similar cu flexibilitatea semantica a atributului "class" intr-un element HTML, dar cu mai putine restrictii. Anumite namespace-uri/scheme W3C XML care pot fi incluse in XHTML, includ MathML pentru marcarea semanticii matematice, Scalable Vector Graphics pentru marcarea vectorilor grafici si RDFa pentru includerea datelor RDF.
Schimbarile de la HTML la XHTML versiunea 1.0 sunt foarte mici si sunt in principal facute pentru a asigura compatibilitatea cu XML. Cea mai importanta schimbare este aceea ca documentele sa fie bine formate si ca toate elementele sa fie inchise in mod explicit asa cum cere standardul XML. In XML toate numele de elemente si atribute sunt case-sensitive, astfle incat XHTML a abordat aceasta problema prin a defini toate numele tagurilor ca fiind lowercase.
In XHTML toate valorile atributelor trebuie inchise intre apostrofuri sau ghilimele in contrast cu HTML unde numai valorile de tip string trebuiau inchise cu ghilimele, valorile numerice sau booleene erau scrise pur si simplu, fara ghilimele.
In XHTML toate elementele trebuie sa fie inchise in mod explicit, inclusiv elementele goale cum ar fi img sau br: <img> si <br>.
XHTML 1.1 - este cea mai recenta recomandare W3C. Prezentarea este controlata numai de Cascading Style Sheets (CSS). Aceasta versiune a XHTML permite deasemenea folosirea de caractere de marcare ruby pentru limbile est-asiatice.
Modularizarea XHTML permite refolosirea unor mici chunkuri de XHTML de catre alte aplicatii XML intr-o maniera bine definita si permite extinderea XHTML in scopuri specializate.
XHTML 1.1 adauga conceptul de stricta conformitate a documentelor: astfel ca un document nu poate angaja anumite caracteristici, trebuie sa fie un document complet care contine numai elementele definite in modulele cerute de XHTML 1.1.
XHTML 2.0 in 2007 este inca in lucru dar este deja controversat pentru ca se desprinde de compatibilitatea backward cu versiunile anterioare.
XHTML 2.0 poate fi parsat in acelasi fel in care un agent utilizator ar parsa XHTML 1.1, folosind un parser XML si un document CSS conform cu specificatiile versiunii noi 2.0.
Noile add-uri aduse de XHTML 2.0 sunt:
- formele HTML vor fi inlocuite cu XForms, o specificatie de informatie introdusa de utilizator de tip XML care permite afisarea corecta de diferite dispozitive de interpretarea a informatiei
- HTML frames vor fi inlocuite cu XFrames
- DOM Events vor fi inlocuite de XML Events care foloseste Document Object Model
- un nou element de tip lista, tipul nl, va fi inclus pentru a proiecta o lista ca lista de navigatie, lucru care poate fi folosite in crearea meniurior imbricate
- orice element va fi capabil sa se comporte ca un hyperlink similar cu XLink, de exemplu <li href="articles.html">Articles</li>
- orice element va fi capabil sa refere o media alternativa cu atributul src, de exemplu: <src="tree.jpg" type="image/jpeg">Oak</p> este acelasi obiect ca si <object src="tree.jpg" type="iamge/jpeg"><p>Oak</p></object>
- atributul alt al unui element img a fost inlaturat: un text alterntiv poate fi dat in continutul unui element img, asemanator cu elementul object, de exemplu: <img src="abc_abecedar.jpg">ABC <em>Abecedar</em></img>.
- un singur element head (h) va fi adaugat. Nivelul acestor headinguri va fi indicat de elementele sectiunilor imbricate, fiecare avand propriul sau heading h
- elementele i, b, tt vor fi si ele inlaturate din versiunea 2.0, numai elementele de subprezentare de tipul sup si sub (adica superscript si subscript) pentru ca ele sunt necesare in anumite limbaje. Toate celelalte taguri se intentioneaza sa fie semantice (de exemplu <strong> pentru text strong si boldat), in timp ce permite agentilor utilizatori sa controleze prezentarea cu elemente CSS.
- adaugarea RDF triplu cu proprietatea si atributele care usureaza conversia de la XHTML la RDF/XML.
Cativa membrii ai familiei XHTML:
- XHTML Basic: o versiune light a XHTML pentru dispozitive care nu suporta dialectele XHTML mai mari si mai complexe folosita pentru handheld-uri si telefoane mobile (este o inlocuire a WML si C-HTML).
- XHTML Mobile Profile: bazat pe XHTML Basic, acest OMA (Open Mobile Alliance) efort tinteste in special catre telefoanele de mana adaugand elemente specifice telefoanelor mobile la XHTML Basic.
- XHTML+Voice: XHTML combinat cu Voice XML pentru a suporta interactiuni audio video.
Servlets
Ce e un servlet?
Servelturile sunt module de cod java care ruleaza intr-un server de aplicatii,
pentru a raspunde la cererile clientilor. Servletii nu sunt dependenti de un
un anumit protocol client-server, dar de cele mai multe ori sunt folositi cu HTTP.
Pentru a scrie servleti sunt necesare clasele javax.servlet (framework-ul de baza) si
javax.servlet.http (frameworkul care raspunde cererilor http).
Servletii HTTP se folosesc in mod curent pentru:
-procesare si/sau inmagazinarea datelor trimise printr-un form HTML
-creare de continut dinamic (de ex se returneaza catre client ce s-a obtinut la un query pe o baza de date)
Servlets vs CGI
Modul traditional de a extinde functionalitatea unui server este CGI (Common Gateway Interface) – interfata independenta de limbaj, ce permite serverului sa porneasca un proces nou care primeste informatiile unui request (ex parametrii) prin variabile de mediu sau intrarea standard si scrie raspunsul la iesirea standard. Fiecare request e procesat separat (o alta instanta de CGI/ script CGI).
Servletii au cateva avantaje fata de CGI:
-un servlet nu ruleaza intr-un process separate -> se elimina overheadul crearii unui nou process pentru fiecare request
-un servlet ramane in memorie, daca un request s-a terminat si urmeaza altul aceeasi instanta de servlet il va procesa
-in server exista o singura instanta de servlet care raspunde concurent la toate requesturile
-mult mai sigur
Arhitectura de baza a unui servlet
Un servlet e o instanta a unei clase ce extinde interfata javax.servlet.Servlet. Cei mai multi servleti extind insa o implementare standard a interfetei, cum ar fi javax.servlet.GenericServlet sau javax.servlet.http.HttpServlet.
Pentru a initializa un servlet, serverul de aplicatii incarca clasa Servlet si creeaza o instanta apeland cosntructorul fara argumente. Acesta apeleaza mai departe metoda init (se creeaza un obiect de tip ServerConfig).
Sevletul efectueaza o singura data aceasta procedura de setup, iar obiectul ServletConfig e obtinut prin metoda getServletConfig().
Cand servletul este initializat, metoda service(ServletRequest req, ServletResponse res)
e apelata la fiecare request pe servlet (poate fi apelata concurent ).
La descarcarea servletului din server, se apeleaza metoda destroy() (toate resursele alocate in init sunt eliberate).
Diagrama cu lifecycle-ul unui servlet:

In continuare dau un exemplu simplu de HTTP Servlet, care trimite clientului inapoi paramatrii dintr-un form.
Codul html pentru form este:
Clasa care extinde HttpServlet:
Iar fisierul de configurare web.xml este:
Servelturile sunt module de cod java care ruleaza intr-un server de aplicatii,
pentru a raspunde la cererile clientilor. Servletii nu sunt dependenti de un
un anumit protocol client-server, dar de cele mai multe ori sunt folositi cu HTTP.
Pentru a scrie servleti sunt necesare clasele javax.servlet (framework-ul de baza) si
javax.servlet.http (frameworkul care raspunde cererilor http).
Servletii HTTP se folosesc in mod curent pentru:
-procesare si/sau inmagazinarea datelor trimise printr-un form HTML
-creare de continut dinamic (de ex se returneaza catre client ce s-a obtinut la un query pe o baza de date)
Servlets vs CGI
Modul traditional de a extinde functionalitatea unui server este CGI (Common Gateway Interface) – interfata independenta de limbaj, ce permite serverului sa porneasca un proces nou care primeste informatiile unui request (ex parametrii) prin variabile de mediu sau intrarea standard si scrie raspunsul la iesirea standard. Fiecare request e procesat separat (o alta instanta de CGI/ script CGI).
Servletii au cateva avantaje fata de CGI:
-un servlet nu ruleaza intr-un process separate -> se elimina overheadul crearii unui nou process pentru fiecare request
-un servlet ramane in memorie, daca un request s-a terminat si urmeaza altul aceeasi instanta de servlet il va procesa
-in server exista o singura instanta de servlet care raspunde concurent la toate requesturile
-mult mai sigur
Arhitectura de baza a unui servlet
Un servlet e o instanta a unei clase ce extinde interfata javax.servlet.Servlet. Cei mai multi servleti extind insa o implementare standard a interfetei, cum ar fi javax.servlet.GenericServlet sau javax.servlet.http.HttpServlet.
Pentru a initializa un servlet, serverul de aplicatii incarca clasa Servlet si creeaza o instanta apeland cosntructorul fara argumente. Acesta apeleaza mai departe metoda init (se creeaza un obiect de tip ServerConfig).
Sevletul efectueaza o singura data aceasta procedura de setup, iar obiectul ServletConfig e obtinut prin metoda getServletConfig().
Cand servletul este initializat, metoda service(ServletRequest req, ServletResponse res)
e apelata la fiecare request pe servlet (poate fi apelata concurent ).
La descarcarea servletului din server, se apeleaza metoda destroy() (toate resursele alocate in init sunt eliberate).
Diagrama cu lifecycle-ul unui servlet:

In continuare dau un exemplu simplu de HTTP Servlet, care trimite clientului inapoi paramatrii dintr-un form.
Codul html pentru form este:
<HTML>
<HEAD>
<TITLE>HTML form tutorial example</TITLE>
</HEAD>
<BODY>
<H1>HTML form tutorial example</H1>
<FORM ACTION="http://localhost:8080/myservlet/MyServlet" METHOD="POST">
Name: <INPUT TYPE="TEXT" NAME="Name" VALUE="" SIZE="25" MAXLENGTH="50"> <BR>
Email: <INPUT TYPE="TEXT" NAME="Email" VALUE="" SIZE="25" MAXLENGTH="50"><BR>
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Sign Me Up!">
</FORM>
</BODY>
</HTML>
Clasa care extinde HttpServlet:
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
doPost(req, res);
}
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("(parametru,valoare):");
Enumeration en = req.getParameterNames();
while (en.hasMoreElements()) {
String param = (String) en.nextElement();
String value = req.getParameter(param);
out.println(param + "=" + value);
}
}
}
Iar fisierul de configurare web.xml este:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>
myservlet</display-name>
<servlet>
<description>
</description>
<display-name>
MyServlet</display-name>
<servlet-name>MyServlet</servlet-name>
<servlet-class>
MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/MyServlet</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>
Subscribe to:
Comments (Atom)