Angular, le plus que template (partie 1) – les directives

On commence aujourd’hui avec un gros morceau : AngularJS. Pourquoi un gros morceau ? Parce que c’est sans doute le framework MVC JavaScript dont on a le plus entendu parlé dernièrement, peut être parce qu’il est soutenu par Google en personne.

FrontEnd ready… only

AngularJS est un framework dédié au développement Front End, de façon analogue à Ember.js.
Contrairement à un React ou un Meteor, il ne s’occupe pas du côté serveur. Pour le Back End, libre à vous de choisir la technologie de votre choix, du moment que le contenu est servi via une API RESTFull (Best Practices forever).

AngularJS a la particularité de pouvoir se bootstraper sur n’importe quelle application web. Plus concrètement vous pouvez tester AngularJS sur une partie bien particulière de votre application Web sans casser le reste du FrontEnd, ni être obligé de l’utiliser de partout.
Il est bien sûr possible également de démarrer un projet from scratch avec pour objectif de réaliser une « One page web app » comme se plaisent à l’appeler nos homologues Anglophones.

HTML5 en ligne de mire

S’il y a une chose à retenir d’AngularJS c’est sa compatibilité avec HTML5 et surtout sa capacité à enrichir HTML5 avec ses propres balises HTML.
Disons que vous désirez construire une page avec un en-tête contenant le titre de votre site, un menu vertical sur la gauche, le contenu au centre en un footer en pied de page, voici à quoi pourrait ressembler votre code HTML :

Balises HTML personnalisées… ou Directives

Les Directives sont au coeur de l’utilisation d’AngularJS, les concepteurs du framework ayant pour objectif d’inciter un maximum de développeurs à utiliser des balises HTML sémantiques. Avec les directives, autant vous dire que c’est simple d’abonder dans leur sens !

L’intérêt des directives, mis à part un code source HTML plus facile à comprendre est le chargement asynchrone des données qu’elles contiennent.
Prenons la balise « <my-header></…> » par exemple, elle est composée de 2 fichiers :

my-header.html (contenant le html à afficher)

my-header.js (contenant le javascript créant la balise)

On note que le fichier my-header.html est explicitement appelé par la directive my-header.js. Cet exemple est très simple puisque le contenu HTML est statique (il ne fait intervenir aucune source de data extérieure, ni aucune variable) mais il démontre un aspect très intéressant du framework : la hiérarchisation des éléments de templating au seing de l’application développée.

Un des avantages de cette façon de procéder est que chaque fragment de html ainsi chargé (aussi nommé « partial« ) est récupéré par AngularJS via une requête XHR. Ainsi le squelette de la page peut se charger immédiatement, les données contenues dans les directives étant affichées indépendamment et récupérées de façon asynchrone.

Poupées Russes

Autre avantage des directives, c’est qu’elles peuvent s’imbriquer, comme n’importe quel élément HTML. Voici les HTML composant la directive leftNavigation :

Vous avez bien vu : une autre balise html est appelée : <navigation-item>.
un attribut spécial ng-repeat est utilisé dans cet exemple. Cet attribut permet de boucler sur un tableau JavaScript nommé navigationItem défini dans la directive navigationLeft ci dessous (ligne8) :

Et pour finir, la directive navigation-item complète :

Notez au passage l’utilisation de la notation {{variable}} et l’accès à « nav » défini dans le fichier navigation-left.html (regardez attentivement l’attribut ng-repeat) .

Comme vous pouvez le voir dans cet exemple, je choisi délibérément de fractionner mes directives en deux fichier :

  • Un fichier ma-directive.js contenant la déclaration de ma directive, attachée au module AngularJS courant.
  • Un fichier ma-directive.html contenant l’ensemble des éléments qui seront affichés à l’écran.

Comme vous pouvez le voir dans navigation-left.js, une méthode controller apparait, fournissant la variable navigationItem au template navigation-left.html et à ses enfants.

Je rentrerais dans les détails concernant les controllers lors d’un prochain billet.

 

Comme sur des rails

Depuis décembre dernier, je suis assidûment les cours de CodeSchool, en particulier la section JavaScript. Une connaissance très pointue de JavaScript me semble nécessaire avant de me lancer dans l’utilisation de Node.js ou d’un des frameworks MVC existants.

J’ai été assez étonné d’une chose en particulier sur CodeSchool : la taille de la section Ruby On Rails. J’ai été d’autant plus étonné de voir que les tout premiers cours créés sur CodeSchool ont pour thème Ruby On Rails.

Alors certes, cela fait maintenant très longtemps que j’entends parler de Ruby on Rails et de la façon dont Rails (le « père » des frameworks MVC à l’intention du développement web) et de sa couche d’abstraction ActiveRecord pour les données.
En revanche, si Python est un autre langage de script qui m’a longtemps intéressé, et auquel je me déjà initié, Ruby et sa syntaxe héritée de Perl m’ont toujours fait peur.

It’s all about APIs, man

Retour au temps présent : la séparation MVC va bien plus loin que de simplement séparer certains types de contenus au niveau du code. Les sources de données sont aujourd’hui également mises à part de façon massive.

Avez-vous déjà entendu parler d’APIs? Pour schématiser, une API permet de questionner un programme et de recevoir une réponse sous forme de flux de données en retour.

Une API est propre au programme qui l’héberge et les réponses formulées dépendent bien entendu de la spécificité métier de ce programme.

La quasi-totalité des sites internet les plus fréquentés au monde possède une API pour chacun de leurs services. Google Search, Facebook, Google Map, Foursquare, Twitter. Et si les APIs étaient originalement créées pour les programmeurs barbus souhaitant « jouer » avec ces sites Web et incorporer des données de ces APIs sur leurs sites internet par exemple, aujourd’hui ces API servent aux concepteurs de ces sites / services dans le but de construire les clients de leurs sites / Services / Applications.

Ne l’oubliez pas, comme je le dis en Introduction à ce Blog, le web devient mobile et dynamique : cela signifie qu’une même source de données peut se retrouver sur de nombreuses déclinaisons logicielles : téléphone mobile, site internet, application télévisuelle, widget… et il y a bien une chose que les développeurs détestent : c’est la duplication de code et de données.

Sainte API priez pour nous

Avec les techniques modernes de programmation et de développement Web, il n’est aujourd’hui plus nécessaire de bâtir un FrontEnd avec une liaison directe en base de données. De multiples requêtes http se chargent de récupérer les différents contenus d’une page au format XML ou mieux, JSON et votre framework JavaScript favori vous permet de mettre tout ça en page dynamiquement.
Sans le savoir, vous venez d’utiliser un webservice pour construire votre page web. Félicitations !

T’aurais pas oublié Ruby dans ton monologue, là ? hein ?

J’y reviens : mon cheminement faiblard au niveau des APIs et de leur importance dans la conception de sites web modernes permet de toucher un point très important : la performance.

Votre nouveau site internet est relié aux données via une ou plusieurs API. Il vous arrivera très souvent de concevoir cette API pour « nourrir » votre FrontEnd. Une API lente vous garantira une expérience utilisateur minable.
Vous savez le nombre effarant de technologies qui permettent de créer une API RESTFull de nos jours ? (pour ne citer que ce protocole). Des milliers.
Mais il y en certaines qui sont reviennent souvent dernièrement: Ruby on Rail et Node.js.

On me dit dans l’oreillette que Java, .NET, Python ou même PHP font très bien le travail. C’est vrai. Mais j’omets volontairement ces technologies, car elles ne rentrent pas dans le cadre de ce blog, qui je vous le rappelle est mon « journal de bord » concernant les nouvelles technologies, et dans une mesure moindre les technologies très intéressantes que j’aurais laissé en chemin (RoR, levez la main !).

C’est donc décidé : je vais m’initier à Ruby On Rails. Je sais pertinemment que ce n’est pas un langage / framework que je vais réellement utiliser dans ma vie professionnelle. En revanche, je sais par expérience que se plonger dans un autre contexte de programmation, avec un environnement différent et un langage différent va nécessairement me donner des points de vues nouveaux sur des techniques que je maîtrise parfaitement aujourd’hui.

RoR : en selle ! (et Gretel)

keep-calm-and-learn-ruby-on-rails-8

Première étape de cette initiation : les cours de CodeSchool. Je vous les recommande, ils sont très bien faits et les exercices interactifs sont plutôt bien pensés. Ils sont parfois un peu rébarbatifs, mais ils donnent un bon point de départ !

Deuxième étape : commencer un projet fondamental (je ne sais pas encore lequel) et pourquoi pas le publier sur Github.

Je vais très certainement trouver des choses intéressantes, de ma perspective de développeur PHP. Je ne manquerais pas de vous en faire part.
Petite note aux lecteurs qui serait déjà de fins connaisseurs de RoR : ne vous moquez pas trop de ce que je pourrais remonter comme découverte, il est très probable que vous les connaissiez depuis plusieurs années et que ça vous fasse sourire de constater que j’ai pu m’en passer depuis tout ce temps 😉

A bientôt 😉

Où il est bon de se placer dans le bon contexte

Bonjour.

Un premier billet sur un blog est toujours une tâche fastidieuse car il est difficile de savoir par quel bout commencer. Pour une fois, je dois avouer que c’est assez simple, puisqu’il va être question de technologies liées au développement web.
Mais pas n’importe quelles technologies : les « nouvelles » technologies.

Nouvelles, vraiment ?

Pas vraiment. Aujourd’hui le web est de plus en plus mobile. Il est également de plus en plus dynamique et il est plus que probable que les notions de « Cloud Computing » ou de « Big Data » soient déjà arrivées à vos oreilles.

Derrière ces notions se cachent toute une batterie de technologies qui n’existaient pas il y a 10 ans. En tout cas pas sous la forme actuelle, ni avec la maturité actuelle.

De mon point de vue de développeur Web, ces technologies ont émergé très rapidement suite à la publication de Node.js, une plateforme permettant d’utiliser JavaScript comme langage côté serveur (c’est bien plus que ça en réalité, Wikipedia vous en dira plus).

Avant Node.js, Javascript était surtout utilisé pour rendre plus dynamique visuellement les pages Web et utiliser Ajax, généralement à l’aide de frameworks comme jQuery. Encore une fois je caricature, d’autres technologies comme Google Web Toolkit  permet de faire des applications en javascript très impressionnantes depuis de nombreuses années (Gmail en est l’exemple le plus parlant).

L’arrivée de Node.js et surtout son adoption massive au fil des années a mené à l’élaboration de très nombreux framework JavaScript MVC, parmi lesquels , ReactMeteorEmber.js, Angularjs (ça fait un paquet de « js »).

Ces frameworks ne sont pas forcément équivalents, ne font pas forcément tous la même chose mais ils ont tous un point commun : ils cherchent à faciliter la vie des développeurs web en inventant de nouveaux paradigmes et en encourageant l’adoption de best practices.

Mais c’est carrément la jungle ?!

Un peu oui ! Ce blog va vous mettre dans la même position que moi : s’initier à l’ensemble de ces technologies, se poser des questions, essayer d’y apporter des réponses. N’attendez pas de tutoriels de ma part, de nombreux blogs le font déjà très bien et la documentation des projets qui seront évoqués ici sont généralement très complets.

Voyez ce blog comme mon journal de bord concernant l’apprentissage de ces technologies. Mon opinion, mes coups de cœur / coups de gueule vous aideront peut-être à vous dépatouiller d’une situation de crise qui sait !