Retrospective or die

Titre choc pour décrire une pratique très répandue dans les entreprises pratiquant l’agilité. La rétrospective peut se pratiquer comme un art, l’enchantement ou la surprise de l’équipe pouvant être au rendez-vous, et peut devenir une vraie source de motivation pour l’équipe.

En ce qui me concerne, j’ai vécu de nombreuses rétrospectives ennuyeuses, longues (parfois couteuses pour l’entreprise) sans que le résultat soit à la hauteur de l’enjeu: listes d’actions difficiles à mettre en oeuvre, pas d’engagement réel de l’équipe … un flop !

Entre parenthèses, une rétrospective ratée peut être le coup fatal donné à une équipe agile dans un contexte de transformation agile regardé avec « doute » par une direction pas forcément convaincue du bien fondé d’une réunion de barbus toutes les 2 ou 3 semaines…

Il existe de nombreux sites décrivant des « jeux agiles » pouvant être utilisés lors d’une retrospective. Mais est-ce vraiment si important de jouer ? Ne peut-on pas seulement se contenter de dresser une liste de points d’amélioration ?

Voici quelques points importants que j’ai pu remarquer lors de rétrospectives que j’ai eu le plaisir d’animer, et qui m’ont fait prendre conscience du fonctionnement de ce meeting un peu particulier.

Le lieu

Le lieu choisi pour faire la rétrospective doit être familier mais pas forcément confortable. ne pas avoir de chaises et de table n’est pas un problème, ça peut même être un avantage pour la dynamique de cette réunion. Avoir un tableau blanc à disposition est quasiment obligatoire car il est un support simple pour coller des post’it (SuperSticky!), dessiner ou écrire.

Le matériel

Des post’it SuperSticky (obligatoire, les autres se décollent souvent au bout de quelques minutes), des stylo pour tout le monde, des feutres pour tableau blanc, de la matière grise…

Le nombre de personnes

Si les participants se connaissent bien, le nombre idéal semble être de 4 à 10 personnes. Si les personnes se connaissent moins bien (cas de deux équipes de développement qui font une rétrospective commune), il faut mieux former des petits groupes pour réfléchir (ou prévoir un ice breaker en préambule).

Le jeu

Lancer un jeu implique d’expliquer les règles, éventuellement de définir un timing (si l’équipe a tendance à se disperser…mais ce n’est pas forcément le cas). Le jeu va permettre aux personnes de sortir du cadre « formel » imposé par leur travail et de se positionner en tant que « joueur » dans la réunion.

Pour commencer,  quelques jeux efficaces souvent très appréciés:

• Glad Mad Sad
• Keep Drop Start
• Speed boat

Après une courte introduction, laisser les participants s’exprimer librement sur les post’it afin de recueillir le maximum d’idées.

Je recommande ce jeu simple à mettre en oeuvre :

Dessiner quatres zones au tableau (un quadrant) et demander à l’équipe de placer des post’it dans chaque quadrant. Chaque quadrant correspond à un « sentiment » du participant parmi : Content / Pas Content (triste) / Reconnaissant. Un dernier quadrant est réservé aux idées d’améliorations.

Après 15 minutes, chaque participant vient  placer ses post’it sur le tableau dans le quadrant correspondant et exprime à haute voix ce qu’il a voulu dire. Les participants qui ont un post’it similaires peuvent en profiter pour le poser à proximité à ce moment là (inutile d’expliquer cela à l’équipe, elle le fera spontanément)

Une fois que tous les post’it sont posés sur le tableau, il faut maintenant animer le débat et faire ressortir les idées d’actions pour s’améliorer. Cela est rendu plus facile avec ce format de jeu car un quadrant est réservé aux idées d’amélioration. On peut donc commencer en priorité par discuter autour des post’it présents dans ce quadrant.

Dans cette phase, l’équipe doit s’exprimer librement. Il faut rester attentifs aux temps de paroles respectifs (éviter qu’une personne « monopolise » la parole, ou essaie d’imposer ses vues) et relancer si au contraire la parole ne semble pas se libérer facilement.

Cette phase doit aboutir à des actions concrètes. Profitez que l’équipe lance des idées pour en faire un résumé écrit au tableau. Il sera ensuite plus facile de résumer oralement ce qui s’est dit et de demander l’assentiment de l’équipe sur telle ou telle action.

Pour terminer, demandez à l’équipe si les actions listées sont suffisantes ou s’il faut continuer. Une liste de 3 à 5 actions est déjà très bien, mais tout dépend du type d’action et du temps dont vous disposez pour les réaliser, à vous de voir.

La conclusion et le feedback

Afin de terminer en beauté, vous pouvez demander un feedback de l’équipe sur la rétrospective, un simple « ça vous a plu ? » ou « qu’est-ce que vous auriez aimé de plus ? », ou mieux : un ROTI.

N’hésitez pas à demander à l’équipe de nouvelle idées ou proposez de nouveaux formats, ça peut aider si vous sentez que l’équipe se lasse.

Enfin, restez à l’écoute de l’équipe après la rétrospective (à la pause café…), certaines bonnes idées peuvent s’exprimer plus tardivement…il serait dommage de les louper !

Bonnes rétrospectives 🙂

 

 

 

 

 

 

 

 

« Adobe Experience Manager » dans la pratique, REX

Après avoir passé quelques mois en tant que lead technique sur des projets de tailles diverses et variées (de quelques dizaines de jours.hommes à quelques centaines de jours.hommes), je me propose de faire un petit retour d’expérience sur l’utilisation d’AEM (Adobe Experience Manager) en tant qu’outil mais également en tant que plateforme de développement.

Cet article qui se veut le plus objectif possible, vous permettra d’apprécier vous développeurs, chefs de projet quels sont les avantages et les inconvénients d’une telle plateforme. L’idée étant bien sûr de vous aider à mieux appréhender et à anticiper les problèmes ou au contraire à profiter au maximum des atouts de la plateforme.

Tout d’abord, AEM est un outil de type CMS (Content Management System). Il est doté de nombreux outils permettant aux différents acteurs d’un projet de communiquer avec la plateforme. Pour n’en citer que quelques uns:

• CRX Explorer : permet aux développeurs de consulter les noeuds de données.
• Siteadmin : un outil pour les gestionnaires de contenus chargés d’administrer le site.
• Damadmin : un outil pour administrer les « assets » (images…)

La présence de ces différents outils (quelquefois un peu redondants) amène également un premier constat : l’outil est fait pour que de nombreux spécialistes puissent travailler de concert. C’est un point fort.

Le travail de développement est extrêmement « découplé » du travail d’alimentation de contenu (Contenus, SEO). Cela peut-être un avantage, mais également un inconvénient si les rôles ne sont pas bien explicités dans les différentes équipes. Le « qui fait quoi » est donc primordial pour éviter que certaines tâches incombent systématiquement aux équipes de développement ou inversement que certaines tâches trop techniques soient déportées vers les gestionnaires de contenu qui du coup peuvent se retrouver un peu « perdus ».

Cela étant, qui peut le plus peut le moins, il est assez confortable de travailler avec AEM (CQ5). On est rarement bloqués, et l’utilisation d’outils de bas niveau est d’une grande aide parfois (CRXDE, Console Felix).

Sur la partie développement, on peut également trouver un certain confort. Le développement en Java peut être assez rapide si les briques de bases sont bien réalisées. Développer de gros sites va nécessiter de développer des composants communs qui devront être particulièrement soignés pour assurer une bonne maintenabilité.

Même si les sites développés sont éphémères (campagne de publicité, sites à fort traffic mais accessible dans une durée limitée), il est néanmoins important de garder un socle solide, et pour cela s’entourer d’un noyaux « d’architectes » ou de développeurs Sénior est une nécessité.

Sur ce type de projet, on fait souvent appel à des développements Off-Shore, ce qui peut se comprendre (Coût, disponibilité…). Il faut donc veiller à maintenir un socle documentaire bien ficelé (wiki…) afin de pouvoir expliquer rapidement comment fonctionnent les composants communs. Se reposer uniquement sur la connaissance des uns ou des autres est une gageure. Le « Time to market » implique une bonne documentation pour faciliter la montée en compétence des équipes.

Si l’on parle maintenant de l’exploitabilité de la plateforme, il y a quelques points négatifs. Le fonctionnement d’AEM CQ5 est basé sur un stockage de type TAR (http://dev.day.com/microsling/content/blogs/main/tarpm.html).

Ce mécanisme de stockage m’a posé des soucis à plusieurs reprises (inconsistence, volume des données trop important nécessitant un nettoyage régulier). La réplication de données (entre instances de contribution et instances de publication) pose également quelques problèmes. Même si l’on s’en sort, des erreurs de réplications arrivent régulièrement. Il existe d’ailleurs à ce sujet plusieurs façons de répliquer des noeuds de données, et toutes ces méthodes ne se valent pas.

Le point important est que l’exploitation ne doit pas être prise à la légère, le suivi des logs (prévoir un mécanisme adapté à la visualisation des logs sur plusieurs instances pour pouvoir diagnostiquer les problèmes comme par exemple kibana) ainsi que de bons tests de non régression (automatisés bien sûr ;-)) peuvent faciliter grandement l’exploitation de la plateforme. Le monitoring de la production devrait également être effectué avec soin…c’est un vaste sujet qui n’est d’ailleurs pas propre à AEM CQ5 mais plutôt au suivi de production d’une ferme de serveurs.

Au delà des ces aspects d’exploitation, les livraisons de contenus se font relativement facilement grâce au package manager (import/export des bundles OSGI et des noeuds de données) et aux tâches de déploiement Maven. C’est le point fort de la plateforme : assurer des livraisons sans redémarrage de serveurs !

N’ayant pas eu l’occasion encore de travailler sur AEM 6 utilisant MongoDB comme instance de stockage, je suis convaincu que AEM est un très bon outil mais qu’il reste encore une marge de progression afin que l’outil soit plus performant et plus stable.

Pour terminer ce court article, j’insiste sur le fait que l’outil ne fait pas tout et que même si AEM CQ5 dispose d’atouts indéniables, il doit également s’accompagner d’une organisation d’équipe hors pair afin que les différents acteurs produisent chacun dans leur rôle un travail de qualité.

Agile ou pas agile ?

 Agile ou pas agile…telle est la question ? 

Nous vivons une époque formidable ou le mot « Agile » est utilisé, ou devrait-on dire « sur-utilisé ». Objet de buzz, ou  utilisé comme argument marketing pour attirer des talents, dans tous les cas l’agilité est un mot tendance !

De plus en plus d’entreprises vantent leur organisation « agile ». Mais à quoi reconnaît-on une entreprise agile ? quels  sont les critères tangibles qui permettent de savoir si l’entreprise dans laquelle on travaille EST agile ?

C’est quoi l’agile ?

Tout d’abord, il existe une définition qui fait foi, celle du manifeste agile : http://www.agilemanifesto.org/iso/fr/

Celle-ci pose les bases de l’agilité mais laisse aussi une large part à l’interprétation, car elle ne définit pas les pratiques agiles mais seulement les directions à suivre.

Reprenons point par point les 4 piliers de l’agilité décrits dans le manifeste:

Les individus et leurs interactions

 Les individus doivent interagir…oui mais comment ? Le plus souvent les individus interagissent oralement (d’ou  l’importance de la colocalisation), on dessine, on utilise le management visuel… mais comment fait-on pour diffuser et  persister la connaissance au sein d’un équipe agile ? Un wiki, un canal de chat pour échanger…certains outils sont  nécessaires. Je n’ai pas encore vu d’équipe agile se reposant uniquement sur les individus pour la gestion de la  connaissance.

Nous n’opposons donc pas interactions et outillage…certains outils comme trello sont de puissants alliés dans une  organisation agile. L’outillage arrive pour servir un but précis dans l’organisation agile. L’outillage n’est pas la pour « formater » un savoir-faire ou rendre rigide l’organisation, mais il se positionne en appui de l’organisation en place.

Des logiciels opérationnels

Les logiciels doivent fonctionner. On parle ici de qualité logicielle. On n’oppose pas documentation (nécessaire dans tout projet) et qualité logicielle. On met la priorité sur le fonctionnement du logiciel et sa fiabilité. On parle aussi de design, d’ergonomie et de performance.

Si un logiciel est simple, intuitif, fonctionne rapidement, on aura moins besoin d’une documentation exhaustive. Les utilisateurs n’auront aucun mal à le prendre en main et les retours seront moins nombreux, synonyme d’un gain de temps.

En ce qui concerne la qualité logicielle, on peut parler de tests unitaires, tests automatisés, mais bien souvent on ne sera pas moins agile en réalisant des tests manuels. Ce qui compte au fond, c’est de tester à fond chaque fonctionnalité quelque soit le moyen (je sens que je vais en fâcher certains). La méthode pour arriver à une bonne qualité dépendra souvent des spécificités du projet et des ressources disponibles.

La collaboration avec les clients

 L’équipe de développement doit collaborer avec le client et vice versa. On parle ici de l’expression du besoin. Bien  souvent, dans une approche waterfall, on parle de « spécs incomplètes », « mauvaises spécs », « spécs pourries » pour justifier  un écart entre ce que l’on a livré et ce qui était prévu. Si il y a une chose importante dans les méthodes agiles c’est cette  collaboration avec le client qui va permettre d’éviter cet écart assez frustrant et pénalisant pour tout le monde.

Si vous recevez vos spécifications dans un beau paquet cadeau avec l’étiquette « Validé », et que vous n’avez jamais  l’occasion d’en discuter avec la personne qui les à écrites…c’est sûr l’agilité ne sera pas de la partie.

Au contraire, un document de spécification reste une bonne base de discussion mais ne doit pas devenir le centre d’attention de toute l’équipe : « c’est pas écrit dans les spécs! » 😉

La spécification est une étape essentielle du travail qui est réalisé par l’équipe de développement. Elle peut prendre la forme de dessins, de diagrammes (pourquoi pas UML), mais aussi de documents…évitions juste que cela devienne un contrat !

L’adaptation au changement

 Un logiciel est quelque chose d’artisanal, ça se construit avec de la sueur, de la matière grise, des échanges…chaque avis  compte. On ne peut pas négliger un changement dans le besoin : un nouveau concurrent arrive sur le marché, on veut se  différencier, on veut une nouvelle fonctionnalité; c’est en quelque sorte vital pour l’avenir de l’entreprise. Comment faire  passer en priorité ce changement sans avoir des échanges avec l’équipe de développement ? qui plus est, le changement étant  décidé rapidement, quoi de mieux qu’une bonne discussion autour d’une table pour savoir quoi faire ?

C’est aussi savoir s’adapter aux changements technologiques, on parle donc aussi d’excellence. Une bonne équipe agile est  une équipe ou chaque personne essaie de s’améliorer (dans son domaine de prédilection) et s’adapte en permanence  aux changements : curiosité et auto-formation sont de rigueur !

Un bémol: les changements trop fréquents dans les spécifications, le planning, ne peuvent être considérés comme de bonnes pratiques agiles, elles sont nuisibles (quelque soit la méthode utilisée).

Pour résumer…

Il existe autant de méthodes agiles qu’il y a d’équipes, voilà pourquoi le manifeste agile est aussi ouvert. Les bonnes équipes agiles sont avant tout des équipes qui savent remettre en cause l’organisation, qui enclenchent des actions d’amélioration continue et qui restent en mouvement !

Relooking d’un composant CQ5

Dans cet article nous allons reprendre le composant développé dans l’article précédent: developper-un-composant-cq5.

Ajoutons du style

Modifions un peu la page contact.jsp pour ajouter deux composants supplémentaires : header et footer.

Ces deux composants auront pour rôle de définir le layout global de la page.

</pre>
<pre><%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>

<cq:includeClientLib categories="democq5.style" />

<cq:include path="header" resourceType="democq5/pages/header"/>

<a href="contact.edit">Add a new contact</a>

<cq:include path="footer" resourceType="democq5/pages/footer"/></pre>
<pre>

Quelques explications: nous utilisons la taglib cq:include permettant d’inclure dynamiquement les deux composants header et footer. Ces deux composants sont construits de la même manière que le composant contact.

Fichier: header.jsp

</pre>
<pre><%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>
<html>
   <body>
        <div class="democq5-container">
            <div class="democq5-head">
                Contact
            </div>
            <div class="democq5-content">
                <!-- content --></pre>
<pre>

Fichier: footer.jsp

</pre>
<pre><%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>

            <!-- end of content -->
            </div>
            <div class="democq5-foot">
                Legal mentions and so on...
            </div>
        </div>
    </body>
</html></pre>
<pre>

Ces deux pages header.jsp et footer.jsp font référence à des classes css que nous avons choisi de placer dans une librairie dédiée de type ClientLibraryFolder.

De cette manière, nous allons pouvoir changer le style css sans affecter la logique métier du composant.

La seule chose que nous aurons à modifier est la déclaration suivante qui permet d’inclure la librairie de styling:

<cq:includeClientLib categories="democq5.style" />

Rentrons maintenant en détail dans cette fameuse librairie css que nous incluons dans notre composant.

Voila les fichiers que nous devons créer:

/apps/democq5/ui/.content.xml

Il s’agit du fichier de définition de la ressource JCR que nous voulons créer. Ici nous souhaitons créer une librairie donc le type est « cq:ClientLibraryFolder »

/apps/democq5/ui/source

Il s’agit du répertoire qui va contenir les sources de notre librairie (on peut y mettre à peu près ce que l’on veut: fichiers js, css…)

/apps/democq5/ui/source/democq5.css

Il s’agit du fichier principal : notre feuille de style CSS

/apps/democq5/widgets/css.txt

Il s’agit d’un fichier qui définit quels sont les fichiers que nous incluons dans notre librairie.

Fichier: .content.xml

</pre>
<pre><?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    categories="democq5.style"
    jcr:primaryType="cq:ClientLibraryFolder">
</jcr:root></pre>
<pre>

Fichier: css.txt

#base=source

democq5.css

Fichier: democq5.css

# CSS for democq5

body {
    background-color: #eee
}

.democq5-container {
    margin: 0 auto;
    width: 600px;
    background-color: white;
}

.democq5-head {
    width: 100%;
    background-color: black;
    color: #eee;
}

.democq5-foot {
    width: 100%;
    background-color: #eee
}

.democq5-content {
    margin: 50px 20px 100px 20px;
}

Allons un peu plus loin…

Nous allons maintenant séparer la feuille de style en deux, de manière à démontrer les capacités de la balise cq:includeClientLib

Créons le fichier base.css:

body {
    font-face: Arial, Helvetica, Sans-serif;
    background-color: navy;
}

le fichier democq5.css contiendra désormais uniquement le styling du composant avec le code suivant:

.democq5-container {
    margin: 0 auto;
    width: 600px;
    background-color: white;
}

.democq5-head {
    width: 100%;
    background-color: black;
    color: #eee;
}

.democq5-foot {
    width: 100%;
    background-color: #eee;
}

.democq5-content {
    margin: 50px 20px 100px 20px;
}

Le fichier css.txt sera modifié comme suit:

#base=source

base.css
democq5.css

rechargeons la page http://localhost:4502/apps/democq5/component/contact.html

et affichons le code source de la page, vous devriez voir ce code:

Les deux fichiers css ne sont pas présents, ils ont été fusionnés dans le fichier ui.css

Il est donc très simple d’inclure des librairies css dans une page sans que la structure des feuilles de styles développées apparaissent dans le site.

Cela permet en outre de télécharger moins de fichiers (même si ceux-ci se retrouvent en cache par la suite).

Sources complètes de la démo:

https://github.com/ptrouillard/democq5

Pour en savoir plus:

https://dev.day.com/docs/en/cq/5-5/developing/components/clientlibs.html

http://docs.adobe.com/docs/en/cq/5-6/howto/taglib.html

Développer un composant CQ5

Dans cet article, nous allons développer un composant CQ5 de prise de contact. Le composant sera constitué d’un formulaire permettant de saisir les coordonnées d’un contact. Le contact sera ensuite stocké dans l’arborescence du JCR.

Les prérequis sont :
Le démarrage d’une instance author de CQ5.

Vous devez avoir accès à cet outil : http://localhost:4502/crx/de/index.jsp#/apps (CRXDE Lite)

Cet outil vous permet de visualiser votre JCR et de manipuler les données.

Un peu d’organisation

Un composant CQ5 est représenté par un noeud dans le JCR. Nous devons donc choisir un emplacement dans le JCR pour y créer ce noeud. L’emplacement conventionnel pour stocker les composants est /apps.

Nous allons donc créer notre composant dans un noeud appelé /apps/democq5/contact

Pour simplifier cette première étape, je vous conseille de lire l’article « Créer un projet maven pour CQ5 » sur ce blog, le résultat servira de base à la suite de cet article.

Affichage d’un titre et d’une description

Nous voici donc maintenant avec un projet maven opérationnel qui va nous permettre de développer notre composant.

Pour commencer, nous allons juste afficher un titre avant d’attaquer la partie formulaire.

Dans le module maven « content », trouvez le répertoire « jcr_root » (c’est le répertoire de base de notre JCR) et créez-y les fichiers suivants:

/apps/democq5/pages/contact/contact.jsp
/apps/democq5/component/contact/.content.xml

Voici le contenu des fichiers:

fichier: contact.jsp

<%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>
<html>
   <body>
        <cq:text property="jcr:title" tagName="h2"/>
        <cq:text property="jcr:description" tagName="p"/>

    </body>
</html>

fichier: .content.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:description="Contact"
    jcr:primaryType="cq:Template"
    jcr:title="Contact"
    allowedPaths="[]"
    ranking="{Long}100"
    sling:resourceType="democq5/pages/contact">
</jcr:root>

La propriété sling:resourceType contient l’emplacement vers le(s) page(s) utilisées par le composant. Cette propriété est utilisée par le framework Sling pour déterminer ou sont stockées les pages lors de la résolution d’URL. Nous y reviendrons plus tard.

Comme expliqué dans l’article sur l’intégration maven, déployer le composant sur votre instance author CQ5.

Une fois le composant déployé, ouvrez votre browser et tapez l’url http://localhost:4502/apps/democq5/component/contact.json

La représentation json de notre noeud JCR apparaît:

{"jcr:description":"Contact","allowedPaths":[],"jcr:created":"Thu Nov 13 2014 16:26:36 GMT+0100","sling:resourceType":"democq5/pages/contact","jcr:primaryType":"cq:Template","jcr:createdBy":"admin","jcr:title":"Contact","ranking":100}

Ce qui nous intéresse maintenant est de voir le rendu final en HTML lorsque l’on invoque notre composant. Tapez cette adresse dans votre browser: http://localhost:4502/apps/democq5/component/contact.html

Cette fois-ci titre et description apparaissent. On note bien que les valeurs affichées viennent des attributs jcr:title et jcr:description du composant.

De manière à démontrer la puissance du moteur Sling, nous allons ajouter une réprésentation texte à notre page.

Créez le fichier /apps/democq5/pages/contact/contact.txt.jsp

fichier: contact.txt.jsp

</pre>
<pre><%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>

Title : <%=currentNode.getProperty("jcr:title").getValue().getString()%>
Description : <%=currentNode.getProperty("jcr:desription").getValue().getString()%></pre>
<pre>

Pour afficher la version texte de notre template, rien de plus simple, tapez l’url http://localhost:4502/apps/democq5/component/contact.txt

l’extension « .txt » est détectée par le moteur Sling comme étant un sélecteur de contenu, ce qui lui permet d’invoquer la page contact.txt.jsp pour le rendu.

Ce concept de sélecteur permet par exemple d’afficher une page au format PDF, html ou texte, sans changer la logique métier du composant et sans configuration supplémentaire au niveau du mapping d’url.

Passons maintenant à notre formulaire de prise de contact…

Création du formulaire

Nous allons maintenant créer une nouvelle page qui contiendra notre formulaire.

fichier: contact.edit.jsp

</pre>
<pre><%@ page language="java" import="java.util.*" errorPage="" %>
<%@include file="/libs/foundation/global.jsp"%>
<cq:defineObjects/>
<html>
   <body>
        <form action="/content/contacts/*" method="POST">
        <table>
            <tbody>
                <tr>
                    <td>First name</td>
                    <td><input type="text" name="firstName"/></td>
                </tr>

                <tr>
                    <td>Last name</td>
                    <td><input type="text" name="lastName"/></td>
                </tr>

                <tr>
                    <td>Email</td>
                    <td><input type="text" name="email"/></td>
                </tr>
                <tr>
                    <td>Save contact</td>
                    <td><input type="submit"/></td>
                </tr>
            </tbody>
        </table>
        </form>
    </body>
</html></pre>
<pre>

Tapez maintenant cette url pour afficher le formulaire : http://localhost:4502/apps/democq5/component/contact.edit

Et voila un « beau » formulaire de saisie :

Essayez de saisir un contact, voici grosso modo ce que vous devriez voir après validation du formulaire :

Il semblerait que notre contact ait été sauvé avec succès…mais ou est-il et comment y accéder ?

Sur la ligne commençant par « Location » se trouve l’url d’accès au contact. copier cette url et ajoutez y l’extension « .json » de manière à pouvoir visualiserson contenu. Les informations de votre contact (firstName, LastName, email) ont été sauvées dans le JCR, et sont tout de suite accessible par une simple URL REST :

Voici ce que vous devriez voir après avoir tapé l’url http://localhost:4502/content/contacts/1_1415894985510.json (à adapter en fonction de l’identifiant de votre contact)

{"email":"monemail@gmail.com","firstName":"Pierre","jcr:created":"Thu Nov 13 2014 17:09:45 GMT+0100","lastName":"Tr","jcr:createdBy":"admin","jcr:primaryType":"sling:OrderedFolder"}

Pour comprendre comment tout cela fonctionne, revenons sur le formulaire. l’action du formulaire est « /content/contacts/* »

Cette action est interprétée comme une sauvegarde de donnée dans le JCR sous le noeud « /content/contacts ». Pour qu’un nouveau noeud soit créé à chaque nouveau contact, on ajoute « * » à la fin de l’action. Il est également possible de renvoyer vers une action plus classique en développant une servlet particulière, mais par défaut l’action de POST est interprétée dans CQ5 par une création de noeud dans le JCR.

Conclusion

Chaque champ du formulaire donne lieu à la création d’un attribut dans le noeud contact qui est créé. On peut ensuite facilement utiliser ce contenu dans une vue pour afficher la liste des contacts créés.

On voit donc avec quelle facilité ont peut créer du contenu avec CQ5, et comment l’utilisation d’un JCR prend tout son sens pour une fonctionnalité de ce type (sauvegarde d’un contenu non structuré, orienté document)

Prochain article : utilisation des taglibs et design de page avec CQ5 😉

Créer un projet maven pour CQ5

L’objectif de cet article est de comprendre comment utiliser les outils de développements classiques (maven, intellij, eclipse) pour travailler avec CQ5.

 

Création du squelette de projet maven

Pour commencer, créons un répertoire pour héberger notre projet cq5 que nous nommerons democq5

Je pars du principe que vous connaissez l’outil de gestion de projet maven et qu’il est correctement installé sur votre machine.

Lancez cette commande pour créer le squelette de projet maven:

mvn archetype:generate -DarchetypeRepository=http://repo.adobe.com/nexus/content/groups/public/
-DarchetypeGroupId=com.day.jcr.vault
-DarchetypeArtifactId=multimodule-content-package-archetype
-DarchetypeVersion=1.0.2
-DgroupId=decafeine.demo.cq5 -DartifactId=democq5 -Dversion=1.0-SNAPSHOT
-Dpackage=decafeine.demo.cq5 -DappsFolderName=democq5 -DartifactName="DemoCQ5";
-DcqVersion="5.6.1" -DpackageGroup="Decafeine blog"

Si vous voyez s’afficher le message suivant « BUILD SUCCESS », continuons….

Utilisez votre IDE préféré pour importer ce projet en tant que projet maven.

Vous devriez voir quelque chose qui ressemble à ça:

 

Le projet importé est constitué d’un projet parent et de deux modules bundle et content.

Le module bundle contiendra vos services (OSGi). Par défaut, un service HelloService est généré ainsi qu’un filtre Sling dont le but est de loguer les accès.

Le module content contiendra les données du projet, au sens JCR. les composants et les pages trouveront leur place ici.

 

Build du projet et déploiement dans le JCR

Nous voila maintenant avec un projet de site CQ5 tout neuf et prêt à l’emploi. Mais justement comment l’utiliser ?

Le cycle de vie de ce projet est géré par maven. Ouvrez le fichier pom.xml, vous y trouverez la déclaration du plugin content-package-maven-plugin

  <plugin>
    <groupId>com.day.jcr.vault</groupId>
    <artifactId>content-package-maven-plugin</artifactId>
    <version>0.0.20</version>
    <extensions>true</extensions>
    <configuration>
      <failOnError>true</failOnError>
      <username>${crx.username}</username>
      <password>${crx.password}</password>
    </configuration>
 </plugin>

Ce plugin s’occupera de déployer automatiquement le code contenu dans votre projet vers le JCR que vous aurez au préalable pris le soin de démarrer.

Par défaut, le plugin est configuré pour déployer sur l’instance CQ5 locale sur le port 4502, mais vous pouvez modifier ça dans les properties du fichier pom.xml

Pour compiler et déployer votre code, il vous suffit donc de taper:

mvn clean install -PautoInstallPackage

A l’issue du build, vous devriez voir s’afficher ces quelques lignes qui montrent que le projet a été déployé correctement sur votre instance CQ5:

[INFO] --- content-package-maven-plugin:0.0.20:install (install-content-package)
 @ democq5-content ---
[INFO] Installing democq5-content (E:\Workspace\democq5\content\target\democq5-c
ontent-1.0-SNAPSHOT.zip) to http://localhost:4502/crx/packmgr/service.jsp
[INFO] democq5-content, 1.0-SNAPSHOT (17826 bytes)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] DemoCQ5 - Reactor Project ......................... SUCCESS [1.240s]
[INFO] DemoCQ5 Bundle .................................... SUCCESS [15.713s]
[INFO] DemoCQ5 Package ................................... SUCCESS [5.162s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 26.844s
[INFO] Finished at: Thu Nov 13 14:25:53 CET 2014
[INFO] Final Memory: 21M/253M
[INFO] ------------------------------------------------------------------------

 

Introduction à Adobe CQ5

Adobe CQ5, également appelée AEM (Adobe Experience Manager) est une plateforme de développement Web complète basée sur de nombreux projets open sources tels que Apache Felix, Apache Sling et aussi les standards OSGi et JCR.

Voici un article qui permettra aux néophytes de ne pas êtyre perdu, car dès le départ cette plateforme est déroutante. Surtout pour ceux qui sont habitués à travailler avec un modèle MVC (Struts, Spring MVC) et une architecture de type trois-tiers.

Adobe CQ5 se repose principalement sur un JCR (Java Content Repository). C’est un repository de stockage « Objet » (arborescent) dont l’utilisation tranche pas mal avec celle d’une base relationnelle.

Les deux principaux concepts qu’il faut comprendre rapidement en commençant à travailler avec CQ5 est que « tout est donnée » et que « toute donnée est stockée dans le JCR ».
Nous y reviendrons tout au long de cet article…mais autant annoncer la couleur tout de suite 😉

Cela étant dit, ça marche comment et ça sert à quoi CQ5 ?

Une approche « composant »

Adobe CQ5 fonctionne avec des composants. Ces composants peuvent faire à peu près tout ce qui possible dans un site Web.

Un composant du point de vue CQ5 est un assemblage de fichiers (CSS, JS, HTML…) fournissant une brique fonctionnelle au site que vous allez développer.

On peut citer comme exemples: Un composant pour enregistrer un utilisateur, un composant pour afficher un flux RSS.

Le principal avantage de cette approche est de favoriser la réutilisabilité du code que vous allez développer (pour peu que cette réutilisabilité soit décidée dès le départ et fasse partie du cahier des charges!). Imaginons que vous êtes une agence de création de sites web. Vous pouvez développer des composants pour un client, et enrichir progressivement la bibliothèque de composants que vous pouvez proposer à vos autres clients.

Le travail du développeur dans CQ5 est donc de développer des composants. Mais pas seulement.

Pour que ces composants s’affichent, il faut les insérer dans des pages.

Des pages pour assembler des composants

Adobe CQ5 permet de facilement créer des pages via des interfaces de création WYSIWYG. Le principal avantage de cette méthode est de fournir des interfaces de création de pages à des "non développeurs". Mais qui peuvent-être ces "non développeurs" ? Auteurs, Editeurs de contenu, graphistes...ce sont toutes les personnes qui participent à la création d'un site Web.

Les composants dont nous parlions plus hauts font partie intégrante de ces interfaces de création car les éditeurs de contenu vont pouvoir placer ces composants à loisir dans leurs pages.

Il y a donc deux types de tâches dans CQ5:

• Le développement de composants
• L’assemblage de pages : 1 page = un ensemble de composants

Un peu d’architecture …

CQ5 est un produit s’appuyant sur des brisques open source comme Felix, Sling, ainsi que Jackrabbit.

Felix : Il s’agit d’un conteneur OSGi permettant de déployer des bundles (sorte de package) contenant des services. L’avantage principal de passer par OSGi est d’avoir des bundles autonomes pouvant être arrêtés, démarrés indépendamment les uns des autres. On peut également exécuter plusieurs versions du même bundle dans la même JVM (à chaque bundle est associé un class loader distinct).

Sling : C’est un « dispatcheur » dont le rôle principal est d’associer une ressource JCR à une URL. Dans le monde JCR, chaque noeud de donnée est appelée une ressource. Comme la structure du JCR est arborescente, chaque ressource est accessible via un chemin (path).

Sling permet donc d’associer à une URL rentrée par l’utilisateur un chemin vers une ressource, on peut y voir un parallèle avec le mapping d’url fait dans les frameworks MVC comme struts ou spring mvc. Néanmoins, le mapping est ici beaucoup plus puissant : à creuser

Jackrabbit : Il s’agit de l’implémentation de référence du JCR

Voila c’est tout pour aujourd’hui.

Dans le prochain article, nous déveloperons un composant CQ5 permettant de saisir un contact et de le stocker dans le JCR.