utiliser des parametres de requetes http au niveau XSLT template

François Jannin · 21/10/2010 14:47:22

Bonjour,

Travaillant sur un nouveau skin pour le CMS Ametys, je voudrais savoir s'il est possible de récupérer au niveau des xsl de la skin des paramètres de requetes http ?

Je crois qu'il existe au niveau de cocoon un générateur dont le namespace est

Est-il intégré dans les pipelines ametys ? Sinon, où l'intégrer ?

L'idée est de modifier les élements affichés dans un template xsl en fonction de paramètres dynamiquement choisis et transmis dans l'url, pour profiler le contenu.

Merci

Raphaël Franchet · 21/10/2010 16:58:03

Bonjour,

Non, ce générateur (ou quelque chose d'équivalent) n'est pas intégré dans le pipeline qui s'occupe du rendu de la page elle même.

Pour récupérer ces paramètres :
* soit vous écrivez un rendu de service, auquel cas vous avez accès à une sitemap cocoon, et vous pouvez utiliser ce génréateur et c'est très facile
* soit vous écrivez un rendu de contenu, auquel cas vous pouvez surcharger le pipeline de rendu et/ou intervenir en java dans la chaine de transformation du contenu, mais c'est déjà pour les gros bras
* soit, enfin, c'est votre cas, vous le voulez directement dans la skin et là, pour avoir des choses en entrée, c'est le mécanisme des InputData.

Les inputdata par défaut vous fournissent le plan du site par exemple.
L'idée serait donc d'écrire en JAVA un inputdata qui fait ce boulot.

Pour ça les étapes sont :

* créer une classe java RequestParametersInputdata qui hérite de org.ametys.web.inputdata.InputData
* dans le toSAX, recupérer les paramètres de requetes, boucler dessus et les renvoyer
pour récupérer la requete il faut être Contextualizable (en implémentant org.apache.avalon.framework.context.Contextualizable)

  
private Context _context;

@Override
    public void contextualize(Context context) throws ContextException
    {
        _context = context;
    }

et faire dans la méthode toSAX

Request request = ContextHelper.getRequest(_context);

* ensuite, il faut déclarer cet inputdata dans un plugin (voici l'exemple du plan du site)

    <feature name="inputdata.sitemap">
        <extensions>
            <extension point="org.ametys.web.inputdata.InputDataExtensionPoint"
                       id="org.ametys.web.inputdata.SitemapInputData"
                       class="org.ametys.web.inputdata.SitemapInputData">
                <!-- Sitemap input data with default depth (initial-depth of 2 and descendant-depth of 1) -->
            </extension>
        </extensions>
    </feature>

* et dire qu'on souhaite l'utiliser en référençant l'id dans le fichier WEB-INF/param/inputdata.xml

Raphaël Franchet · 21/10/2010 16:58:41

mais tout ça est assez compliqué

qu'est-ce que vous souhaitez faire avec ces paramètres de requêtes ?

François Jannin · 22/10/2010 15:24:46

Merci pour ces indications et cette réponse rapide. Nous testerons ce mécanisme d'inputdata.

François Jannin · 10/11/2010 16:30:40

Bonjour,

J'ai essayé de suivre ces indications mais j'ai un ClassNotFound, (alors que ma classe est bien dans les sources du plugin) :

Caused by: org.apache.avalon.framework.configuration.ConfigurationException: Unable to instanciate class 'com.anwrt.inpt.siteweb.inpt.RequestParametersInputData' for plugin 'dsi_alert' / 'inputdata.requestparams' @file:///home/cms/Ametys_CMS/application/v1_0_0RC3/cms/plugins/dsi_alert/plugin.xml:94:87 at org.ametys.runtime.plugin.component.AbstractThreadSafeComponentExtensionPoint.addExtension(AbstractThreadSafeComponentExtensionPoint.java:142) at org.ametys.runtime.plugin.PluginsManager._loadExtensions(PluginsManager.java:1077) at org.ametys.runtime.plugin.PluginsManager._loadFeatures(PluginsManager.java:1030) at org.ametys.runtime.plugin.PluginsManager.initExtensions(PluginsManager.java:472) at org.ametys.runtime.cocoon.TreeProcessor.compose(TreeProcessor.java:65) ... 38 more Caused by: java.lang.ClassNotFoundException: com.anwrt.inpt.siteweb.inpt.RequestParametersInputData at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.ametys.runtime.plugin.component.AbstractThreadSafeComponentExtensionPoint.addExtension(AbstractThreadSafeComponentExtensionPoint.java:138) ... 42 more

Faut-il placé cette classe ailleurs ?
Merci

Raphaël Franchet · 15/11/2010 10:11:44

Bonjour,

en fait, ce qu'il faut surtout c'est compiler la classe java (en .class).
Le fait que le fichier source de la classe soit dans le plugin ne sert à rien techniquement, sinon à ce que le plugin fasse un tout : ce qui compte c'est que le fichier compilé (.class) soit accessible à l'application (donc dans le répertoire WEB-INF/classes)

Pour cela il faut configurer votre environnement de développement pour compiler le répertoire src de votre plugin à l'aide de toutes les librairies disponibles dans WEB-INF/lib et pour mettre le résultat dans WEB-INF/classes.

Raphael

François Jannin · 18/11/2010 15:09:20

Je pensais qu'il existait peut-être un mécanisme de compilation intégré dans le process de déploiement...
Il me faut donc déployer la classe compilée dans Eclipse sur mon poste de dev, dans le WEB-INF du serveur. A part ce petit bémol, tout fonctionne bien en suivant vos inidications.
Pour infos, l'usage que je fait de ce mécanisme : changer le comportement de la xsl en utilisant certains paramètres d'url afin d'avoir un semblant de vue profilée (contenu afficher selectivement selon la valeur des paramètres)
Je me pose cependant la question : est-ce que le cache du site publié va utiliser ces paramètres afin de distinguer les différentes pages ? Je n'ai pas encore eu l'occasion de tester...

Merci !

Raphaël Franchet · 18/11/2010 15:29:34

Aïe ! en effet cela posera problème : Il faut que la page en question ne soit pas mise en cache.
Certains services (comme le moteur de recherche) désactive la mise en place du cache de la page, mais dans votre cas qu'est-ce qui pourrait se charger de cela ?

Vous pourriez mettre un service non-cachable ou en créer un à cette fin...

François Jannin · 29/11/2010 11:26:12

Bonjour,

J'ai effectivement un problème avec le RequestParameterInputData : le cache des sites publiés ne prends pas en compte les paramètres d'url
En dehors du fait de créer un service non-cachable, n'y-a-t-il pas moyen de modifier le cache pour qu'il prenne en comptes les paramètres, c'est-à-dire que pour qu'il cache un contenu différent quand les paramètres d'url changent ?
Sinon, comment faut-il faire car en suivant vos recommandantions pour l'InputData je n'ai pas déclaré de nouveaux services ?

Merci

Raphaël Franchet · 29/11/2010 14:53:59

Le cache stocke sur le système de fichiers : les paramètres d'urls ne sont donc pas prises en compte.
Il faudrait que le paramètre lui-même fasse partie du chemin de l'url : mais ce n'est pas possible dans le cas d'une page.

Comme je le disais plus haut, vous pourrier faire un service qui ne fait rien (sinon désactiver le cache) mais c'est pas très satisfaisant.

En fait, au niveau conception ce que vous souhaitez faire n'est peut-être pas à traiter comme cela dans Ametys.
Pourriez-vous exposer ce que vous souhaitez faire en détail ? (ce que vous avez expliqué est un peu court, pour que j'arrive à me faire une idée de votre besoin)

François Jannin · 30/11/2010 14:40:53

Le besoin de départ est d'avoir un site qui permet de lister des services informatiques disponibles, et ce d'une façon générique (la totalité des services) ET de façon profilée en fonction du type d'utilisateur et de son appartenance à un département.
Il y a des services dont la description est commune à tous les profils, d'autres qui possèdent une description particulière en fonction du profil (type d'utilisateur + département donc)

Ce que je voulais faire, et qui fonctionne tant que l'on reste dans le CMS et non en version site, c'est utiliser des url de genre où les paramètres sont utilisés dans la xsl d'un gabarit chargé de lister les services adéquats. Les pages décrivant des services sont donc etiquetées par deux jeux d'etiquettes qui correspondent aux valeur des paramètres utilisateur et département

Le but était d'éviter de crééer autant de gabarit différents qu'il y a de combinaisons entre ces deux paramètres (18 pour l'instant mais qui vont être appelées à augmenter), et donc dix-huit gabarits avec juste des filtres qui différent.
D'autant que cette solution ne résout pas les problèmes de cohérence de la navigation :
il faut pouvoir retourner à cette page taggée listant les services depuis les pages décrivant les services remontées par le gabarit - or les pages communes n'ont pas les tags permttant d'identifier la page racine.

Mais tout ceci n'est peut-être pas réalisable à cause da la couche statique utilisée lors de la publication du site ?

Les seules solutions que je suis capable d'envisager :
-En faisant du rewriting sur les url avec paramètres ne pourrait-on faire en sorte que le cache stocke en filesystem une version différente de la page pour chaque combinaison de paramètres ?
- ou en créant un service qui remonte des pages filtrées sur plusieurs tag... mais le temps m'est compté, je ne sais pas si ce srait long ?
J'espère avoir été un peu plus clair...
Merci pour toute piste supplémentaire...

Raphaël Franchet · 30/11/2010 19:33:07

Même si la combinatoire le permettait, créer autant de gabarits que des pages éditoriales nécessaire est un peu un non sens : dans ce cas là autant créer un seul gabarit et éditer le contenu de manière personnalisée (avec un service de remontée de contenu au lieu de filtres).
Dans ce cas, couplé à la ré-écriture d'url ça pourrait marcher.

Je m'explique : dans le CMS vous créez n pages pour vos n profils (toutes filles d'une page commune), dans chacune, vous mettez de la remontée de contenu adaptée au profil. Et vous redirigez l'url de cette page commune vers la bonne page fille (grâce aux Alias qui supportent depuis peu les urls avec paramètres).
Les redirections ne sont pas mises en cache.
Par contre au niveau du fil d'ariane de la page vous verrez la page intermédiaire, et via le moteur de recherche ou le plan du site vous n'empéchez pas les visiteurs de voir les pages qui ne les concernent pas : c'est juste une redirection automatique.

(on aurait aussi pu simplement faire le travail en javascript, mais c'est pas très propre du tout !)

François Jannin · 07/12/2010 11:02:50

Bonjour,

La redirection me semble demander une structure de site difficilement compréhensible pour l'utilisateur... et ne remplit pas toutes les contraintes (le fil d'ariane)

Comment fait-on pour créer un service non-cachable qui ne fait rien ?
En l'etat, l'ideal serait de désactiver le cache et de n'utiliser que des pages dynamiques pour ce site, quitte à lui donner plus de cpu et de mémoire côté CMS si le nombre d'utilisateur est trop important.

Sinon, j'ai vu des jars ehacache dans le projet, et sur cette page cela semble indiquer que l'on peut cacher des pages avec url paramètres inclus :

Ne serait-ce pas plus simple d'utiliser cela ?
Le problème est que je ne sais pas ou modifier l'utilisation du cache dans le code...

Merci

Raphaël Franchet · 07/12/2010 19:34:44

Pour créer un service, il faut le déclarer dans un plugin.xml
Voici l'exemple du service "plan du site"

    <feature name="sitemap-service">
        <extensions>
            <extension point="org.ametys.web.service.ServiceExtensionPoint"
                          class="org.ametys.web.service.StaticService"
                          id="org.ametys.web.service.SitemapService">

                <url>service/sitemap.html</url>

                <cacheable>true</cacheable>
            
                <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_LABEL</label>
                <description i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_DESCRIPTION</description>
                <thumbnail>
                    <small>img/service/sitemap_16.png</small>
                    <medium>img/service/sitemap_32.png</medium>
                    <large>img/service/sitemap_48.png</large>
                </thumbnail>
                <parameters>
                    <parameter name="header" type="string">
                        <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_TITLE</label>
                        <description i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_TITLE_DESC</description>
                    </parameter>
                    <parameter name="depth" type="long">
                        <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_DEPTH</label>
                        <description i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_DEPTH_DESC</description>
                        <default-value>-1</default-value>
                    </parameter>
                    <parameter name="all" type="string">
                        <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_FROM</label>
                        <description i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_FROM_DESC</description>
                        <enumeration>
                            <entry>
                                <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_FROM_ALL</label>
                                <value>true</value>
                            </entry>
                            <entry>
                                <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_FROM_CURRENT_PAGE</label>
                                <value>false</value>
                            </entry>
                           </enumeration>
                    </parameter>
                    <parameter name="xslt" type="string">
                        <label i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_XSLT</label>
                        <description i18n="true">PLUGINS_WEB_SERVICE_SITEMAP_XSLT_DESC</description>
                        <default-value>pages/services/sitemap/sitemap.xsl</default-value>
                        <enumeration>
                                <custom-enumerator class="org.ametys.web.service.ServiceXSLTEnumerator">
                                <path>pages/services/sitemap</path>
                                </custom-enumerator>
                           </enumeration>
                    </parameter>
                </parameters>
            </extension>
        </extensions>
    </feature>

Dans votre cas, vous pouvez retirer les paramètres qui ne vous servent à rien, vous pouvez passer cachable à false.
(si vous n'avez pas besoin d'internationnaliser le backoffice, vous pouvez remplacer par exemple <label i18n="true">CLEFI18N</label> par <label i18n="false">Mon service</label>)

Ensuite, comme vous le voyez, un service est caractérisé par une url.
Il faut donc ajouter un pipeline cocoon à la sitemap.xmap de votre plugin pour gérer cette url ; le but de ce pipeline est de renvoyer un html vide dans votre cas

<html>
  <head></head>
  <body></body>
</html>

Pour ça dans la sitemap il faut mettre un pipeline comme celui-ci :

<map:match pattern="service/sitemap.html">
    <map:generate type="action-result"/> <!-- c'est un générateur qui ne fait rien de particulier -->
    <map:transform src="pages/maxsl.xsl"/>
    <map:serialize/>
</map:match>

et ensuite dans votre plugin vous créez le fichier "pages/maxsl.xsl" qui match / et qui créé le html que j'ai mis un peu plus haut

Attention ! Les modifications de plugin.xml nécessite un redémarrage.
Par contre, pour la sitemap et les xsl ce n'est pas la peine.

ps: pensez aussi à changer l'id de votre service dans le plugin.xml, sinon le CMS refusera de démarrer.

François Jannin · 09/12/2010 10:19:20

Bonjour,

Merci pour ces indications. Je vais les mettre en oeuvre de suite.

François Jannin · 09/12/2010 12:35:45

Encore un détail : y-a-t-il un moyen d'affecter automatiquement ce service à un gabarit sans passer par une manipulation via l'ihm ?

Merci encore.

Raphaël Franchet · 09/12/2010 19:15:46

Non malheureusement pas aujourd'hui.

Nous avons dans les cartons de créer des "macros", pour pouvoir par exemple en un clic : créer une page avec le gabarit "page" et un contenu de type "Article". Mais rien n'est planifié pour le moment.

Forum Ametys

#1 21/10/2010 14:47:22

utiliser des parametres de requetes http au niveau XSLT template

#2 21/10/2010 16:58:03

Re: utiliser des parametres de requetes http au niveau XSLT template

#3 21/10/2010 16:58:41

Re: utiliser des parametres de requetes http au niveau XSLT template

#4 22/10/2010 15:24:46

Re: utiliser des parametres de requetes http au niveau XSLT template

#5 10/11/2010 16:30:40

Re: utiliser des parametres de requetes http au niveau XSLT template

#6 15/11/2010 10:11:44

Re: utiliser des parametres de requetes http au niveau XSLT template

#7 18/11/2010 15:09:20

Re: utiliser des parametres de requetes http au niveau XSLT template

#8 18/11/2010 15:29:34

Re: utiliser des parametres de requetes http au niveau XSLT template

#9 29/11/2010 11:26:12

Re: utiliser des parametres de requetes http au niveau XSLT template

#10 29/11/2010 14:53:59

Re: utiliser des parametres de requetes http au niveau XSLT template

#11 30/11/2010 14:40:53

Re: utiliser des parametres de requetes http au niveau XSLT template

#12 30/11/2010 19:33:07

Re: utiliser des parametres de requetes http au niveau XSLT template

#13 07/12/2010 11:02:50

Re: utiliser des parametres de requetes http au niveau XSLT template

#14 07/12/2010 19:34:44

Re: utiliser des parametres de requetes http au niveau XSLT template

#15 09/12/2010 10:19:20

Re: utiliser des parametres de requetes http au niveau XSLT template

#16 09/12/2010 12:35:45

Re: utiliser des parametres de requetes http au niveau XSLT template

#17 09/12/2010 19:15:46

Re: utiliser des parametres de requetes http au niveau XSLT template

Board footer