L’un des documents présente la liste des différences entre HTML 4 et HTML 5 (liste évidement non exhaustive) :

• Le langage est basé sur l’utilisation des documents DOM.
• Concept de contextes de navigation.
• Nouveaux concepts de modèles de contenu (remplaçant les actuels block et inline).
• Nouveaux éléments : datagrid, menu (pour l’utilisation en natif de menu contextuel), commands.
• Gestion du cache pour les applications Web en mode déconnecté (concept de Google Gears?).
• Concept de UndoManager, permettant de gérer l’undo/redo.
• Architecture de copier/coller et drag&drop.
• Nouveaux éléments permettant d’embarquer du contenu vidéo, canvas (pour les graphes 2D, les jeux, …).
• Nouveaux types d’élément input : date, number, email, url, color, …L’élément input a aussi droit à un nouvel attribut : autofocus, permettant de lui donner directement le focus lors du chargement de la page.
• Suppression des éléménts frame, frameset et noframe, car ils dégradent l’utilisation et l’accessibilité du site.

HTML 5 sera évidement compatible avec les pages en HTML 4. Cette nouvelle version a aussi pour but de standardiser toutes les API JavaScript grâce à un référentiel commun.

L’autre document est la spécification complète de HTML 5.

Pour suivre votre lecture

• GWT 2.0 : les nouvelles fonctionnalités
• Goo.gl : le raccourcisseur d’URL by Google
• Chrome OS : première présentation
• Guide d’optimisation de vos applications Web
• Twitter : la VoIP disponible grâce à Jajah
• Cinq moyens pour gérer son identité virtuelle
• Ruby on Rails : déployer une application sur Tomcat avec JRuby

Pour cette nouvelle version il devrait y avoir des évolutions dans le langages Java, un nouveau format d’archive (remplaçant du fichier jar) : Java Module System (JSR 277), de nouvelles API et des améliorations de la JVM (support natif de language de script : Javascript, Ruby, PHP).

Nouveautés du langage

• Support natif du XML :

Un exemple vaut mieux que plusieurs lignes d’explications :

1
2

Document d = <collection><object param="value">Content</object></collection>;
element.appendChild (<object>Content</object>);

• Propriétés JavaBeans :

Possibilité de définir un membre d’une classe en tant que propriété : les accesseurs seront alors générés à la compilation. Actuellement la syntaxe permettant d’accèder aux accesseurs n’est pas encore certaines : ., =>, -<, #.

1
2
3
4
5
6
7
8
9

public class MyObject {
    private property String member;
}
...
MyObject obj = new MyObject ();
obj.member = "NewValue"; // setMember
String str = obj=>member; // getMember
obj->member = "New Value"; // setMember
str = obj#member; // getMember

• Redéfinition des opérateurs :

Le langage permettrait alors de redéfinir les opérateurs grâce à des annotations.

1
2
3
4
5
6

String str = "first";
switch (str) {
    case "first": doThis (); break;
    case "second": doThat (); break;
    default: throw new IllegalArgumentException ("Unknown: " + str);
}

Autre exemple avec les énumérations :

1
2
3
4
5
6
7
8
9
10

enum MyColor {
    EMPTY,
    BLACK, WHITE,
    RED, YELLOW, BLUE,
    PINK, PURPLE, ORANGE, GREY;
}
 
public boolean isPrimary (MyColor c) {
    return c >= MyColor.RED &#038;& c < = MyColor.BLUE;
}

• Chaînage des appels de méthodes :

1
2
3
4
5
6
7
8

class MyObject {
     void doSomething () { ... }
     void doOther () { ... }
     boolean validate () { ... }
}
 
MyObjet myObject = new MyObject ();
boolean validate = myObject.doSomething ().doOther ().validate ();

• Amélioration des blocs catch :

1
2
3
4
5
6
7
8
9
10
11

try {
     doSomething ();
} catch (IllegalStateException | IllegalAccessException e) {
     // Traitement de l'exception...
}
 
try {
    doOther (); // Lance des types différences d'exceptions
} catch (final Throwable t) {
    throw t; // Lance les mêmes types d'exceptions
}

• Gestion automatique des ressources : les ressources qui sont initialisées dans un bloc sont automatiquement nettoyées à la fin du bloc. Le bloc finally n'est alors plus nécessaire.
• Simplification des templates et des List/Map :

1
2
3
4
5
6

Map<string , Object> myMap = new HashMap<> ();
 
List</string><string> list = new ArrayList<> ();
list.add[0] = "First";
list.add[1] = "Second";
</string>

• Les Closures (ou méthodes anonymes) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// Sans Closures :
lock.lock ();
try {
    ++counter;
} finally {
    lock.unlock ();
}
 
// Avec Closures :
withLock (lock) {
    ++counter;
}
 
public static <t> T withLock (Lock lock, {=> T throws E}) block) throws E {
    lock.lock ();
    try {
        // Exécution du 'bloc' de code block
        return block.invoke ();
    } finally {
        lock.unlock ();
    }
}
</t>

Modularité

• Gestion des Super packages.
• JAva Module System : remplaçant du fichier JAR (Java ARchive) : gestion des versions, des dépendances, ...

Gestion du versionning

Lorsque l'on développe une application, celle ci à généralement besoins d'une ou plusieurs librairies de classes. Cependant si cette librairie ne peut être fourni avec l'application (problème de license) ou qu'une version spécifique est nécessaire, il n'y à actuellement aucun moyen simple de vérifier la librairie. Les fichiers JAM vont permettrent ceci grâce à une gestion avancée du versionning :

major[.minor[.micro[.update]]][-qualifier]

Par exemple :

Modules

Un fichier JAM est en fait une simple archive (tout comme le fichier JAR) qui peut contenir d'autres JAR (les modules), des ressources (images, ...), du code natif (nouvelle gestion : /META-INF/bin/

Chaque application aura une bibliothèque de modules (locaux ou distants) permettant la recherche, le chargement (au démarrage ou à l'exécution).

Exemple :

// Déclaration du superpackage :
@Version("1.0")
superpackage com.site.pack {

    // Import de modules
    @VersionConstraint("1.0+")
    import com.site.name;
    @VersionConstraint("1.5*")
    import com.site.xml;

    // Liste des packages
    member package com.site.pack, com.site.pack.impl;

    // Types exportés
    export com.site.pack.*;
}

Nouvelles API

• NIO 2 : gestion avancée du système de fichiers (permissions, attributs de fichier), API I/O asynchrone pour les sockets et fichiers.
• JSR 275 (gestion des unités, ex: Km, m, cm, ...) : expression d'une valeur dans plusieurs unités, conversion d'unités, parsing des unités dans une String.
• JSR 310 (date and time API) : amélioration de l'API actuelle afin de permettre de gérer des durées, des intervalles.
• JSR 166y : amélioration de la concurrence.
• JSR 225 : Xquery API for Java.
• JSR 284 : gestion de la consommation des ressources (CPU, mémoire, connexions JDBC, ...).
• JSR 308 : annotations sur les types Java.
• JSR 260 (amélioration de la Javadoc) : tri des méthodes et champs en fonction de leur utilité, un index sémantique, distinction des méthodes/objets static, factory, deprecated, distinction des méthodes de propriétés (accesseurs), ajout d'exemples d'utilisation des méthodes.
• JSR 296 (framework pour Swing) : sauvegarde de l'état entre chaque session, gestion simplifiée des actions (arrière-plan), génération des textes dans des fichiers .properties (localisation).
• JSR 303 : validation des Beans (contraintes de schéma de base de données, du niveau business/service, du niveau présentation, du côté client).
• JSR 295 : liaison des Beans.

JVM

• Amélioration du byte-code (gestion dynamique) afin de supporter des langages de scripts : Javascript, PHP, Ruby.
• Modification du Garbage Collector : plus de gestion d'ancienne et nouvelle génération.

Article écrit à partir de : Xebia.

Pour suivre votre lecture

• GWT 2.0 : les nouvelles fonctionnalités
• Ruby on Rails : déployer une application sur Tomcat avec JRuby
• Ouverture du Java Store
• Oracle rachète Sun
• Première utilisation du plugin Eclipse GWT
• Google : GWT version 1.6 et consorts
• HTML 5 : deux nouveaux documents

C’est pour cela qu’il existe des langages de validations, ils permettent de valider le format des documents XML selon un format qui est défini par le dévéloppeur.

La plupart des parseurs vérifient le format et renvoient une erreur si le format n’est pas respecté.

Les langages de validations

Il existe plusieurs langages de validations, mais je ne vais vous présenter que les deux les plus utilisés.

Les différents langages :

• DTD (Document Type Definition) : définition du type de document. Ce langage peut être inclu directement dans le document XML.
• XML Schema : il permet de définir la structure d’un document avec plus de précision (type de donnée, nombre d’occurence, …).
• Relax NG (REgular LAnguage for XML Next Generation) : ce langage ne spécifie que la structure du document, le type de donnée est sous-traitée à la bibliothèque de types de XML Schema.
• Schematron : contrairement aux autres langages Schematron définie un modèle d’arbre du document XML, il utilise la même conception que XPath ou XSLT.

Doctype

Une DTD est une grammaire permettant de vérifier la validité d’un document.
Un document XML peut avoir une DTD incluse dans son entête ou bien indiquée le fichier où elle se situe.

Une DTD définit trois objets permettant de définir la grammaire :

• ELEMENT : représente un élément XML et permet de définir les sous-éléments ansi que leurs occurences.
• ATTLIST : liste des attributs d’un élément.
• ENTITY : permet de définir un ‘alias’.

Une DTD est définie de la façon suivante :

<!DOCTYPE element-racine [
  <!ELEMENT ...>
  <!ATTLIST ...>
  <!ENTITY ...>
]>

Voici un site permettant de valider un fichier XML avec sa DTD : http://www.stg.brown.edu/service/xmlvalid/.

Élément

Permet de définir un élément XML en spécifiant le nom les sous-éléments de ce dernier.
La déclaration d’un ENTITY doit avoir la syntaxe suivante :

<!ELEMENT nom (Donnees)>

La définition des Donnees peut avoir les valeurs suivantes :

• (#PCDATA) : l’élément contient des données de types textes mais ne peut pas contenir de sous-éléments.
• (Element1, Element2, …) : liste des sous-éléments que contient l’élément.
• (Element1 | Element2 | …) : liste des sous-éléments qui peuvent être contenus par cet élément.
• ANY : cet élément peut contenir n’importe quel type de données.
• EMPTY : cet élément doit être vide et ne peux contenir aucune donnée (texte ou éléments).

Dans la définition des sous-éléments on peut spécifier l’occurence de l’élément :

• Element1? : l’élément peut apparaître 0 ou 1 fois.
• Element1+ : l’élément peut apparaître 1 ou plusieurs fois.
• Element1* : l’élément peut apparaître 0, 1 ou plusieurs fois.

On peut spécifier le nombre de sous-élément en répétant l’élément enfant :

<!ELEMENT element1 (element2, element2)>

Ici l’ « élément1″ devra forcément contenir 2 éléments « element2″.

Voici un exemple de DTD d’une liste de contacts :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE contacts [
  <!ELEMENT contacts (contact*)>
  <!ELEMENT contact (nom, adresse, mail)>
  <!ELEMENT nom (#PCDATA)>
  <!ELEMENT adresse (#PCDATA)>
  <!ELEMENT mail (#PCDATA)>
]>

<contacts>
  <contact>
    <nom>Marwan KHELIF</nom>
      <adresse>...</adresse>
      <mail>mkhelif@gmail.com</mail>
    </contact>
  <contact>
      <nom>My Name</nom>
      <adresse>My address</adresse>
      <mail>my.mail@mail.com</mail>
    </contact>
  </contacts>
</code>

Attlist

La déclaration ATTLIST permet de définir les attributs d’un élément. On peut spécifier le type de donnée, la valeur par défaut, forcer la présence de l’élément, …

La déclaration se fait ainsi :

<!ATTLIST nomElement nomAttribut Type ValeurDefaut>

Le nom de l’élément doit correspondre au nom d’un élément déclaré dans la DTD.

Le type de l’attribut peut prendre les valeurs suivantes :

• CDATA : l’attribut contient des données textuelles.
• ID : chaqu’un des éléments définis doit avoir une valeur différente pour cet attribut.
• IDREF : référence la valeur d’un attribut ID d’un autre élémént.
• IDREFS : liste d’attributs ID, ses valeurs sont séparées par un espace.
• ENTITY : correspond à une ENTITY déclarée dans la DTD.
• ENTITIES : listes d’ENTITY déclarées dans la DTD, chaque ENTITY doit être séparées par un espace.
• NMTOKEN : la valeur doit être un nom XML valide.
• NMTOKENS : liste de noms XML valides.
• NOTATION : nom d’une notation définie dans la DTD.

La valeur par défaut de l’attribut peut prendre les valeurs suivantes :

• valeur : valeur par défaut de l’attribut.
• #REQUIRED : l’élément doit forcément posséder cet attribut.
• #IMPLIED : cet attribut n’est pas obligatoire.
• #FIXED valeur : l’attribut doit forcément avoir la valeur valeur.

Voilà un exemple de DTD définissant des attributs :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 <!DOCTYPE personnes [
  <!ELEMENT personnes (personne*)>
  <!ELEMENT personne (adresse, mail)>
  <!ATTLIST personne
       id ID #REQUIRED
       nom CDATA #REQUIRED
       sexe (homme | femme) "homme">

  <!ELEMENT adresse (#PCDATA)>
  <!ATTLIST adresse
       code CDATA #REQUIRED>

  <!ELEMENT mail (#PCDATA)> ]>

<personnes>
  <personne id="user0" nom="Marwan KHELIF">
    <adresse code="13">...</adresse>
    <mail>mkhelif@gmail.com</mail>
  </personne>
  <personne id="user1" nom="MyName" sexe="femme">
    <adresse code="01">...</adresse>
    <mail>monMail@mail.com</mail>
  </personne>
</personnes>

Entity

La déclaration d’une ENTITY permet de créer un ‘alias’, elle est ensuite utilisable dans le document XML.

On la déclare de la façon suivante :

<!ENTITY nomEntity "valeur">

On peut alors l’utiliser dans le document XML : &nomEntity;, la valeur définie sera alors positionnée à la place de cet entité.

Par exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<!DOCTYPE articles [   <!ENTITY auteur "Marwan KHELIF">
  <!ENTITY dtd "Document Type Definition">
  <!ENTITY xsd "XML Schema">

  <!ELEMENT articles (article*)>

  <!ELEMENT article (#PCDATA)>
  <!ATTLIST article
       titre CDATA #REQUIRED
       auteur CDATA "&auteur;"
       date CDATA #REQUIRED>
]>

<articles>
  <article titre="&dtd;" date="17/07/07">Presentation de &dtd; par &auteur;.</article>
  <article titre="&xsd;" date="17/07/07">Presentation de &xsd; par &auteur;.</article>
</articles>

Ce sont les entités générales du document, il y a un autre type d’entités : les entités paramètes.
Elles sont définies de la même manière sauf qu’il faut rajouter un ‘%‘ devant le nom :

<!ENTITY % nomEntity "valeur">

On les utilise de la façon suivante : %nomEntity;.
Voilà un exemple de leur utilisation :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE articles [
  <!ENTITY % article "titre, auteur, date, contenu">

  <!ENTITY auteur "Marwan KHELIF">
  <!ENTITY dtd "Document Type Definition">
  <!ENTITY xsd "XML Schema">

  <!ELEMENT articles (article*)>
  <!ELEMENT article (%article;)>
  <!ELEMENT titre (#PCDATA)>
  <!ELEMENT auteur (#PCDATA)>
  <!ELEMENT date (#PCDATA)>
  <!ELEMENT contenu (#PCDATA)>
]>

<articles>
  <article>
    <titre>&dtd;</titre>
    <auteur>&auteur;</auteur>
    <date>17/07/07</date>
    <contenu>Presentation de &dtd; par &auteur;.</contenu>
  </article>
  <article>
    <titre>&xsd;</titre>
    <auteur>&auteur;</auteur>
    <date>17/07/07</date>
    <contenu>Presentation de &xsd; par &auteur;.</contenu>
  </article>
</articles>

Ces deux types d’entités sont internes au document XML, on peut indiquer que la cible de l’entité est un fichier externe au document :

<!ENTITY doc SYSTEM "http//www.mkhelif.fr/doc.xml">
&doc;
<!ENTITY % articles SYSTEM "articles.dtd">
%articles;

Lors de l’utilisation de l’entité le contenu du fichier sera chargé et remplacera l’entité.

Pour suivre votre lecture

• HTML 5 : deux nouveaux documents
• Nouveautés Java 7 – Dolphin