L'objectif de cette conférence est de parler WEB
D'un point de vue Expérience Utilisateur
Framework
Architecture
Pourquoi le WEB ?
Le navigateur s'est imposé comme principal environnement d'exécution
d'applications : grand public, application de gestion, voir industriel
Ils sont déjà présents sur les supports mobiles : téléphones, tablettes
console de jeux, télévision, on commence à en voir dans les voitures
N'ayez pas peur d'intervenir
De poser des questions
De dire : j'ai rien compris , tu peux répéter
J'ai pas compris la question
A l'origine le browser est assez simple :
il affiche des informations avec un langage dédié / déclaratif :
du markup, de l'HTML
Et il possède un espace mémoire : une machine virtuelle et un langage
qui permet de manipuler cette mémoire : y déposer des informations et en récupérer
A un moment donné on ne sait pas trop ce qui s'est passé...
partie de ces principes simples on est arrivé à des choses ...
Vieux débat (pour ceux qui ont eu leur bac avant 2000)
la difficulté est la suivante : le contenu affiché sur le navigateur
est toujours distant : les données sont distantes (BD)
et les éléments graphiques sont distants (contenu statique)
idéalement, on aimerait que notre markup soit à l'image de ce qui s'affiche
<input model="firstname">
<input model="lastname">
Hello {firstname} {lastname}
finalement on explique au client que l'informatique c'est très compliqué
on manipule beaucoup d'instruction et de traitement et ces traitements il
faut les organiser en couche
pour
evolutivité
maintenabilité
scabilité
transitivité
la postérité
on parle de patterns, affinité de session, transaction, de two-phase commit...
On explique au client qu'il faut organiser les informations et les traitements
que potentiellement, les données seront utilisées par différents médias
et que potentiellement on voudra changer allègrement la partie graphique
par contre le backend, représente le coeur du métier de l'entreprise
MVC Paradigm
Au même moment, on assiste à un retour en force du modèle MVC
On dit : on final : nous avons 3 activités distinctes
controller : il écoute avant tout
lorsqu'il recoit quelque chose, il le transmet
model : la caverne d'ali baba : on y stocke tout les trésors
données, les modèles de données
View : c'est ce qu'on va afficher sur le browser : des données et des éléments graphiques
On décide de mettre tout ça : sur le serveur
Pourquoi : car le navigateur n'est pas très performant
en plus on a la proximité des données sur l'env de dev je vois
mes données, mon modèle, je tire le tout et je le place sur ma view
tout ça avec un seul langage principal : java, ou C# ou assimilé
Déclinaison basic de ce modèle avec les servlet et les JSP
D'ailleurs ya une nouvelle formation prévue en 2014
JSP/Servlet pour les nulles à Nantes, trop bien
Formation Vintage
Déclinaison Struts façon Groupama
on manipule des JSP (la classe)
mais on a un super fichier pour l'apsect controleur
le strutsconfig.xml (.xml)
Si vous n'en avez jamais vu ça vaut vraiment le coup
C'est une tuerie... par contre si vous n'avez pas fait polytechnique
ça risque d'être chaud
Déclinaison JSF
Le point remarquable : "Render"
Le rendu, cette opération mystérieuse que l'on confie à une personne sur le projet
Personne ne comprendra sauf, il introduira les principaux goulots d'étranglement
il ne fera jamais de transfert de co
object-oriented user interfaces
limites du Paradigme : MVC Server
0 - L'inconvénient du server side MVC : le V : le fait de faire du templating par le serveur
nous limite trop sur les traitements graphiques. La seule chose que
pour avoir du comportement : on ajoute du JS à l'arache
on cache des champs... on fait des iframes...
JQuery, Prototype
1 - 2005, 2006 John Resig dévelop Jquery, l'API Prototype intervient à peu près au même moment
2 - Jquery API qui permet de manipuler directement le DOM
l'arbre d'objet du navigateur : on ajouter des objets graphiques,
on ajoute des traitements sur des évènnements
3 - Inconvénient : Jquery est bien en toolbox...
on se retrouve à développer beaucoup beaucoup de JS... parfois difficile à structurer
Principes
DRY : don't repeat yourself / No boilerplate
On évite d'avoir à développer une structure de projet de base
le framework va réaliser lui même le binding / le lien mémoire <-> vue
le framework offre en natif tout un tas de lib pour manipuler le DOM
mécanisme d'enrichissement du DOM / HTML : possibilité
de définir des balises HTML
Structure : zone de déclaration des services ou factory,
mécanisme de controller avancée : héritage des propriétés entre controleurs
Testabilité : tout est testable grâce au mécanisme d'injection
Basé sur la notation Jasmine + lanceur Karma (ex testacular)
on peut injecter dans un test unitaire : un controlleur, un service, une factory
les exécuter, voir leur comportement avant ou après
