Le développement Web est un univers dynamique et instable où se succèdent acteurs et technologies avec plus ou moins de succès. Même le vénérable HTML se voit aujourd'hui concurrencer en tant que vecteur d'informations par des technologies orientées multimédia comme peuvent l'être Flash ou Silverlight...

À ce titre, ces dernières années ont marqué un changement radical dans la manière de penser les développements Web : c'est l'avènement du Web 2.0 - notez que je hais ce terme, mais il est, et de loin, le plus consensuel et le plus apte à décrire l'ensemble des changements qu'a connu le Web -, avec en Guest Star, le controversé Javascript. Qu'on le vénère ou qu'on l'abohrre, on ne peut que reconnaître son apport au niveau de l'intéraction utilisateur... jusqu'à devenir le véritable catalyseur de la mutation des développements Web? Vous n'y croyez pas? Luke Kenneth, via Advogator, nous en livre une analyse de haut niveau avec Blurring of MVC lines: Programming the Web Browser.

L'auteur décrit les 4 approches du développement Web MVC telles qu'elles existent actuellement :

• Vue en HTML pure.
  Il s'agit de l'utilisation historique du HTML. Des vues en HTML pure, et une programmation métier essentiellement via CGI-BIN. Les domaines de compétences sont ici bien établis entre les différents composants.
   
• Mix HTML / Javascript.
  L'introduction du Javascript est légère et répond à des problématiques concrètes : la validation des données et l'aide à la saisie - j'omets sciemment l'aspect graphique -. Il en résulte une expérience utilisateur plus agréable et un allègement de la charge serveur, celui-ci n'ayant plus à gérer de nombreuses saisies incorrectes. Dans cette configuration, certaines compétences de la couche métier migrent vers le client Web.
   
• Mix HTML / Ajax.
  L'invasion se poursuit via une stratégie "innovante" : XMLHttpRequest - à noter la pique sur le caractère "innovant" - . La construction de la vue se complexifie, le gestion du cycle de vie devient un science à part entière mais l'expérience utilisateur est encore améliorée. La complexité d'intégration pousse le développeur à utiliser un des nombreux framework ayant vu le jour pour cadrer ce type de développement.
   
• Javascript comme pière angulaire du développement.
  Les rôles MVC du serveur Web et du client Web sont quasiment inversés et la nature même du développement Web est bouleversée. Si le développeur code toujours en Java ou en Python, une phase de génération existe et c'est finalement du Javascript qui sera exécuté.
   

La pièce maîtresse, le Javascript, dicte la structure et la forme du développement. Son impact est tel que l'auteur prédit la généralisation de technologies telle que GWT ou Pyjama, qui finalement, ne sont que des générateurs de code vers Javascript à partir de languages de haut niveau - respectivement Java et Python -. Un des commentaires va encore plus loin et place Javascript comme le nouveau bytecode du développement Web.

 En bref, une analyse poussée et argumentée sur la mutation du développement Web. À mettre en toutes les mains.

• Blurring of MVC lines: Programming the Web Browser.

 En savoir plus

Qui n'a jamais été confronté à devoir écrire 10 lignes de code uniquement pour copier les variables d'un objet vers un autre ?

Exemple classique avec un framework MVC : Vous récupérez le formulaire soumis sous forme de Bean. Vous devez ensuite passer toutes les valeurs à l'objet représentant le model (model.setNom(bean.getNom()), model.setAge(bean.getAge())....).

Cela passe encore quand vous avez 5 valeurs à entrer, mais avec des formulaires contenant 20 champs et plus c'est une autre histoire...

Pour simplifier tout ça, il existe un petit framework qui ne nécessite qu'une seule ligne de code : Dozer

MapperIF mapper = new DozerBeanMapper();
DestinationObject destObject = (DestinationObject) mapper.map(sourceObject, DestinationObject.class);

Voilà c'est fini. Cela nécessite cependant que les attributs des deux objets portent le même nom. Dans le cas contraire il faut ajouter un fichier XML pour décrire les différents champs à mapper :

<mapping>
<class-a>package.SourceClassName</class-a>
<class-b>package.DestinationClassName</class-b>
<field>
<A>SourceFieldName</A>
<B>DestinationFieldName</B>
</field>
</mapping>

Dans cet exemple : l'attribut SourceFieldName de l'objet SourceClassName sera copié dans l'attribut DestinationFieldName de l'objet DestinationFieldName. Il est également possible de spécifier les attributs à exclure lors de la copie.

En bref, c'est un outil bien pratique pour se décharger de l'insertion parfois fastidieuse des valeurs d'un Bean vers un autre objet.