Forum Ametys

Bonjour,

J'ai créé une page Wiki sur le sujet :

En gros, la migration est principalement manuelle et va s'opérer en 3 étapes :
- la charte graphique. Il y a un guide sur le wiki (destiné à la 2.9 mais il s'applique également à la 2.6), mais ce n'est pas très complexe, le mécanisme général a peu changé.
- les données. C'est le point le plus délicat, car le stockage a fortement évolué pour optimiser les performances. La page Wiki fournit un projet Java sous Eclipse qui permet d'effectuer cette migration. Attention, la procédure n'est pas standard et il faut sans doute modifier plusieurs paramètres directement dans le code Java pour l'adapter à votre projet (il y a 3 sections statiques au début du fichier contenant d'éventuels paramètres à modifier).
- les plugins. Ca dépend des fonctionnalités de votre propre application et des plugins que vous aviez. La 3.0 étant bien plus riche fonctionnellement que la 2.6, la plupart des plugins de l'époque sont maintenant natifs. Il reste les plugins développés par vous-même qu'il faudra migrer au cas par cas.

Bien cordialement,
Cédric Damioli

Non les urls n'ont pas besoin du nom de domaine.
J'ai "snifé" les traces HTTP et le fichier htc est chargé correctement par contre il ne cherche jamais à charger le fichier blank.gif.

Alors que la même chose coté CMS le fait.
J'ai un peu l'impression que le script "plante" et ne va pas jusqu'au bout.

Mais là je viens de rafraichir sur IE6 et cela fonctionne. Avez-vous changé quelque chose entre temps ?

--
Raphael

Si ce bout de code est déclaré au sein d'une CSS, il suffit de mettre
une url relative à l'emplacement de la CSS.
Si ce bout de code est dans le corps du template dans une balise style,
vous avez aussi la possibilité d'utiliser du xsl :

<style>
img, div, a, input { behavior: url("<xsl:value-of
select='$skincontext'/>/pngfix/iepngfix.htc"); }
</style>
par exemple

Raphael

oui il faut échapper les < et > qui doivent être recopié dans le code,
je n'ai pas vu que mon copié collé les avait enlevé

<xsl:comment>[if IE 8]&gt;
         &lt;link rel="stylesheet" type="text/css" href="<xsl:value-of
select="$skincontext" />/css/layoutIE8.css" media="screen" /&gt;
   &lt;![endif]</xsl:comment>

Pour créer une nouvelle skin, vous pouvez tout à fait copier-coller une skin existante en renommant simplement le répertoire : c'est même conseillé !
(sauf si la charte est mal faite et au lieu d'utiliser $skin, marque son nom en dur dans le code - ce qui n'est pas le cas de celle de démo)

Je viens de relire le code de la charte : elle affiche dans le menu les pages à la racine du plan du site qui portent l'étiquette "rubrique" sans porter l'étiquette "invisible"

Voilà.

Dans ce cas cela provient du cache de tomcat.
Il faut effacer le répertoire work et le contenu du répertoire temp dans tomcat.
(attention, le répertoire temp peut être vide, mais doit exister au démarrage - contrairement à work)

En, c'est une bonne idée, d'effacer ces répertoires au démarrage du tomcat.
Car toute mise à jour des jars d'Ametys peut le nécessiter.

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

Ok. Au temps pour moi.
Le problème vient de la configuration de tomcat.

Sur votre connecteur 8080, vous devez indiquer que Tomcat est utilisé via un proxy.
Dans le fichier tomcat/conf/server.xml, cherchez la balise

<Connector port="8080"

et ajoutez l'attribut
   proxyPort="80"
et si votre serveur tomcat utilise un nom de domaine différent de httpd
   proxyName="NOMDUSERVEURHTTPD"

Bonjour,
Est-ce que le message "Erreur interne de servlet" est au look Ametys ?
Si oui, un clic sur "Show details" devrait afficher les détails de l'erreurs.

Sinon, les logs pouvant contenir l'erreur sont :
* celui d'Apache httpd (notamment, si c'est une erreur de configuration)
* celui de Tomcat (notamment, si c'est une erreur grave)
* celui de l'application front (si c'est une erreur de proxy)
* celui de l'application back (pour toutes les autres erreurs)

Il faut comprendre que l'application front fait principalement proxy (avec cache) des requêtes mais c'est le back qui génère les pages : donc, si une erreur survient à la création de la page, elle est logguée dans le back, le front lui se content de faire passer l'affichage de la page d'erreur.

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

Nous avons dans les cartons de ne pouvoir surcharger qu'une seule clé d'un catalogue, mais ça ne sera pas fait rapidement.

Une autre option est de ne plus s'appuyer sur le helper pour créer les commentaires, en surchargeant par exemple article.xsl / news.xsl
et en copiant et modifiant le helper.xsl qui crée les commentaires
il suffirait de remplacer le template "comment" qui se charge d'afficher un commentaire.

Bonjour,
l'export proposé est en fait un html pour 'Excel' pour le moment
pourquoi est-ce que vous pensiez qu'il s'agissait de CSV ? peut-être que certains tooltips / aide sont erronés...