Où puis-je trouver la documentation de la taglib en 10SP2 ?
Bonjour,
Il me semble que le lien vers la documentation des tags et celle de l'UI n'ont plus de lien dans le BO, depuis la v10 SP2.
A la place, il y a un lien vers le nouveau site de documentation (docs.jalios.com).
Est-ce que cela montre une volontée d'enlever, à terme, la documentation développeurs de la WebApp ?
Je sais où est cette documentation dans la WebApp donc je suis en mesure de recréer l'URL mais les nouveaux développeurs, eux, n'ont pas forcément l'idée d'aller faire un tour dans le dossier "docs" de la WebApp : en ça, les liens étaient pratiques.
Comme les liens ont été enlevés, j'en déduis qu'il est voulu que nous allions chercher la documentation autre part : pouvez-vous nous indiquer où trouver cette documentation, s'il vous plait ?
Sauf erreur de ma part, il y a des informations dans la documentation de la taglib qui ne sont disponibles nulle part ailleurs.
Merci.
Cordialement
Meilleure réponse
Bonjour @Pierre MORIN , @Benoît Dissert ,
Comme toutes les documentations techniques, c'est désormais sur docs.jalios.com qu'il faudra se tourner (tout n'a pas encore été migré mais c'est là que toutes les docs développeurs seront rédigées / déplacées).
Pour la taglib : https://docs.jalios.com/jplatform10/jcms/taglib
On ne vous demande pas de justifier vos développements. C'est juste que ce point est pour nous, intégrateurs, un point critique.
C'est pas que ce serait pratique, c'est juste qu'on peut pas travailler sans.
Je vais expliquer plus précisément la situation dans laquelle on se trouve, pour vous faire comprendre que ce n'est :
- ni de la mauvaise volonté de type 'c'était mieux avant'
- ni de la réticence par rapport au fait de faire migrer les clients
- ni un petit plus pour lequel on fait pression
et qu'on en a vraiment besoin.
Je pense pouvoir parler au nom de tous les intégrateurs en disant que nous recommandons systématiquement des montées de version et qu'en plus c'est dans notre intérêt.
En effet :
- c'est un devoir déontologique de notre part de recommander les dernières versions par rapport aux problémes de sécurité ;
- avec les dernières versions, nous avons moins de travail de qualification des bugs à remonter au support ;
- l'hétérogénéïté des versions des clients nous est préjudiciable par rapport à la montée en compétences des développeurs et à la maintenance de nos outils de productivité.
Mis bout-à-bout, le fait que nos clients ne migrent pas nous coûte très cher.
Sachant cela, je vous prie de croire qu'on leur préconise fortement de migrer.
Mais nos préconisations sont des arguments pour nos clients, au milieu d'un ensemble de contraintes qui sont les leurs et qui ont autant d'importance :
- budgets / contraintes formelles d'appels d'offre
- contraintes de planning et de ressources internes (recette, exploitation, ...)
- référentiel d'entreprise (et en particulier compatibilité des versions avec les socles logiciels)
- mise à niveau des compétences internes
- disponibilité des intégrateurs
- incompatibilité
- ...
Tout ça fait que, de fait, les clients ne migrent pas au rythme qu'on voudrait, et nous demandent tout de même de faire la maintenance.
Et la maintenance corrective en tout cas, ça consiste essentiellement à comprendre les intentions des développeurs au moment où le comportement initial a été réalisé.
Et comprendre l'intention initiale ne peut se faire sans savoir exactement quels étaient les éléments (dont la doc de référence) que le développeur avait au moment du développement initial.
C'est pourquoi avoir la documentation d'une version précise est un impératif pour nous. On ne peut pas travailler sans.
Alors on apprécie énormément que vous ayez décidé de clarifier et réordonner pour rendre l'accès à toute la documentation plus facile. Même pour moi, qui connait la structure de l'acienne documentation depuis plus de quinze ans, ce sera un plus (je connais même l'url par coeur de certaines d'entre elles).
Mais disposer de toutes les versions de la documentation de référence est plus important pour nous que ce gros chantier.
Par ailleurs, la solution qui était présente avant (javadoc et taglib dans toutes les versions, en ligne) était parfaite par rapport à ces problématiques.
Je vous prie de croire que nous ne voulons pas mettre de la mauvaise volonté par rapport au chantier en cour, dont nous reconnaissons la valeur.
Très bon résumé, @Benoît Dissert .
@Olivier Jaquemet : nous sommes évidemment très heureux de voir la qualité du travail que vous accomplissez (pour avoir travailler sur du Liferay et du WebSphere, je peux vous assurer que vous n'avez pas à rougir), nos remarques sont là uniquement pour vous aider à nous aider. ;-) Nous sommes partenaires : nous voulons tous aller dans le même sens. Cependant, en tant qu'intégrateurs, nous avons des contraintes qui nous sont propres et ne sont pas évidentes ; c'est pourquoi nous vous les exposons, en toute bienveillance.
Merci de tes retours @Benoît Dissert
C'est pourquoi avoir la documentation d'une version précise est un impératif pour nous. On ne peut pas travailler sans.
[...]
Mais disposer de toutes les versions de la documentation de référence est plus important pour nous que ce gros chantier.
Par ailleurs, la solution qui était présente avant (javadoc et taglib dans toutes les versions, en ligne) était parfaite par rapport à ces problématiques.
Les documentations automatiquement générées pour chaque version sont toujours fourni dans les war.
- javadoc : docs\javadoc\
- tag library : docs\jcms\taglib.jsp
Statuts
J'ai posé la même question lors de la sortie de la 9, alors que les liens vers la taglib ont été enlevés de JavaDoc et documentation de Tag Library.
Jalios m'a alors répondu que c'était fait exprés et que maintenant c'était prévu de l'avoir dans la webapp. J'ai donné mon avis en disant que c'était moins pratique : ça l'est encore moins maintenant.
Merci pour ce témoignage. Ce n'est pas très rassurant, malheureusement...