Une introduction à angularJS et aux Single Page Application

J'étais parti pour faire une video sur AngularJS mais j'ai éprouvé la nécessité de remettre cette technologie dans un cadre plus général de développement des applications.

J'expose le système courant du templating coté serveur et coté client.

Templates coté client 

Avec ici la synthèse:

Mais le plus important est de replacer le phénomene des SPA: Single Page Application dans le contexte. REST , MVVM (angularJS ) , SPA et NoSQL sont autant des pièces d'un même puzzle.

Pourquoi des applications de ce type:

• Pour des raisons Economiques: les coûts sont partagés , elles sont scalables, elles sont simples.
• Pour la simplicité des solutions misent en oeuvre.

 Au premier abord toutes ces notions semblent très compliquées, mais en commençant doucement par des exemples simples, tout devient possible.

En conclusion: ce n'est pas un simple mouvement de mode. Ces évolutions touchent la manière de faire des applications, de conduire des projets.

Le support des slides de la video est ici:lien

Sur youtube : la video est diffusée a cette adresse.

Immortel COBOL : un framework MVC en COBOL

Avec le projet COBOL on Wheelchair donnez une seconde jeunesse à vos développements COBOL.

Ce projet est ici   il permet d’écrire des applications WEB en COBOL selon le modèle MVC .

Le prérequis : un serveur HTTP, un compilateur COBOL (ex: openCobol sur Linux)  ET des développeurs COBOL.
  Les parties Controleur et dispatching semblent marcher  mais la partie modèle (accès aux données) n'est pas abordée.
Il n'y pas de doute, les développeurs COBOL sont de la tribu des immortels.

Le blues des frameworks MVC #node.js

Le concept du framework MVC  (modele vue controleur)  date du début des années 80 , bien avant le temps d'Internet ou de Java/JEE.

mvc 2

Jusqu’à maintenant les choses étaient simples. Un bon gros serveur MVC générant des vues pour le client.
La carrière de l'informaticien était toute tracée: Le MVC serveur tu maitriseras. Hélas des elements sont venus parasiter ce bel édifice.

• La montée en puissance du javascript.

Boosté par les gars de google ou de microsoft , le moteur d'exécution javascript est celui qui a gagné le plus en performance.

• Le javascript est le seul langage supporté par tous les navigateurs.

• La segmentation du poste client

Le PC est maintenant en concurrence directe avec les smatphones ou les tablettes. Le concepteur se retrouve devant une fragmentation du matériel et il doit gérer tous les cas de figure (clavier / ecran tactile)
ET cela même au niveau des applications métiers

 Il n'est donc  plus réaliste d'avoir tout le traitement de la vue préparé au niveau du serveur. Le framework se trouve réduit à un distributeur de données en ... JSON.  

• Plusieurs frameworks et non plus un seul framework

Certains traitements sont déportés sur le client mais sans pouvoir êtres terminés.
Prenons l'exemple d'un export CSV pris en charge par du javascript sur le poste client:
A)  Le client recoit de la donnée en JSON
B)  Le client retravaille les données et fabrique un export CSV
C) Le client NE POURRA pas enregistrer son travail sur son poste local (pour des raisons de sécurité, le navigateur refuse de dialoguer avec le système de fichier local) .

La solution est d'envoyer le fichier CSV vers un serveur qui se chargera de retourner le fichier reçu avec la bonne entete. Ce serveur joue le rôle d'un miroir qui se contente de renvoyer ce qu'il reçoit du client. Pour cela une dizaine de lignes suffit, nul besoin d'un framework embarquant plusieurs milliers de ligne de code.

Ainsi l'architecture applicative ne sera pas composée d'un gros serveur MVC mais de plusieurs composants hétérogènes de taille réduite.

On ne peut plus parler de modèle MVC. Sur ce site http://blog.nodejitsu.com/scaling-isomorphic-javascript-code  Charlie Robbins  liste les differents modèles induits par l'utilisation de framework client (backbone.js , batman.js etc ) et introduit la notion de RVP : Resource-View-Presenter

C'est pour ça que les frameworks  'classiques' vont devoir s'adapter ou disparaître. A ce jour seul Rails avec les versions > 3.0 a pris le parti de se mettre en retrait sa partie serveur pour mettre en avant la partie cliente.