Forum Ametys

D'accord. On s'éloigne de la remontée de contenus mais le fonctionnement reste dans la même veine : c'est le générateur du service qui doit faire une requête sur le repository pour récupérer les contenus dans la page courante (récupérable en attribut de requête) possédant un certain tag.
Alternative : si vous ne voulez récupérer vraiment que les contenus de la page courante, vous pouvez récupérer la page en question, puis parcourir simplement les contenus de celle-ci et tester votre étiquette, cela vous évitera une requête qui pourrait être complexe.

J'imagine que les bouts de XSL que vous collez ici se trouvent dans la XSL de rendu du service : il est donc normal que vous puissiez retrouver une page tagguée à partir d'ametys:sitemap() (accessible dans la skin, dans les XSL de rendu de contenus ou de services) mais pas à partir de /cms/inputData/sitemap, qui n'est accessible que dans la skin (XSL de templates).

Bonne réponse, pour plus d'informations :

A noter que si vous voulez juste modifier les types de contenus existants (ajouter des champs aux articles, masquer un champ des actualités, etc.) le mieux est de surcharger les metadata/metadata-sets des types de contenu existants plutôt que tout redéfinir, comme indiqué ici :

In its default database Users implementation, Ametys uses unquoted lowercase columns in its queries.

Then, it depends on the JDBC driver you use: for instance, Oracle creates all its identifiers (table name, column name, and so on) uppercase but is not sensitive to the case in the queries.

If the HSQLDB JDBC driver is case-sensitive, you should use quoted identifiers in your creation script to make them lowercase. The alternative would be to declare a specific JdbcUsersManager which would work on capital columns (it's easily done, it is only XML configuration).

La documentation de jetty pour les classpaths additionels est ici :
J'imagine que vous n'avez pas modifié le script de démarrage de jetty "start" pour ajouter l'option "-Djetty.class.path", ou modifié le contexte "jetty/contexts/ametys.xml" pour ajouter un Set "extraClasspath".

Du coup, je pencherais aussi pour qu'OS X ajoute un classpath par défaut et que vous ayez un connecteur oracle dans celui-ci. D'après  essayez de regarder dans /Library/Java/Extensions ou ~/Library/Java/Extensions, ou potentiellement dans votre variable d'environnement CLASSPATH.

Quelle est la version de votre connecteur JDBC oracle (le jar ojdbc-xxx.jar dans le dossier WEB-INF/lib) ?

Cette erreur peut apparaître quand la version 10.x du connecteur est utilisée, si c'est bien le cas, passer à la version 11.x devrait résoudre le problème.

Okay, sorry, I hadn't seen your previous message with the patches.
I encourage you to open the feature request ticket in our issue tracker, and attach your patches to it. However, there will be a bit more work to do to adapt the DBMS-specific code I was talking about, but nothing impossible 

Hi, Ametys currently supports only MySQL, Oracle, Derby and Postgres DBMS. Whereas you could easily adapt the table creation scripts, some parts of the CMS use DBMS-specific code, and there's very little chance all of it will work with HSQLDB.

The problem here is that the CMS uses DBCP for connection pooling, and the connection testing query doesn't seem to work with HSQLDB.

Apache Derby is fully compatible with Ametys, and seems to cover the same features as HSQLDB (embedded or server mode). Is there a specific reason for you to use HSQLDB or could you consider using Derby instead?

You still can use HSQLDB as a storage engine for the repository, as jackrabbit is compatible with it. There's absolutely no need to use the same database engine for the jackrabbit storage and for the CMS.

Si vous utilisez le workflow standard (avec le plugin default-workflow tiré de l'application de démo), le nom du workflow est "content".
L'URL serait plutôt de la forme "plugins/mypage/person/create-content?siteName=default&lang=fr&workflowName=content&login=XXX" (XXX étant l'uid LDAP de la personne à créer) sans "/default" au début.

J'ai bien une idée mais ce n'est pas gagné : avez-vous désactivé le contenu "page perso" original ?
Cela se fait en ajoutant la ligne suivante à la liste des features exclues dans le fichier WEB-INF/param/runtime.xml (section plugins/exclude) :

<feature>mypage/org.ametys.mypage.content-type</feature>

Avez-vous des erreurs spécifiques dans les logs de l'application site ?

Le paramétrage se fait dans le fichier "WEB-INF/param/runtime.xml" de l'application site, où vous devez spécifier des CredentialsProvider, UsersManager et GroupsManager cohérents.
Le UsersManager et le GroupsManager doivent de plus correspondre aux UsersManager.FO et GroupsManager.FO déclarés dans le fichier "WEB-INF/param/runtime.xml" de l'application back-office.

J'imagine que la solution qui consiste à modifier directement les libellés dans le LDAP n'est pas satisfaisante...

Le plus simple reste donc de surcharger le rendu du service annuaire. Pour cela, créez le dossier "services/mypage/pages/services" dans le répertoire de votre skin, puis placez un fichier "search_1.3.xsl" à l'intérieur (ou éditez-le s'il existe déjà), avec la structure suivante :

<xsl:stylesheet version="1.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
        xmlns:ametys="org.ametys.web.transformation.xslt.AmetysXSLTHelper">
    
    <xsl:import href="plugin:mypage://pages/services/search/search_1.3.xsl"/>
    
    <xsl:template match="attribute[@id = 'affectation']" mode="input">
    </xsl:template>
    
</xsl:stylesheet>

Le template viendra surcharger le rendu de votre champ affectation. Il faudra que vous recopiiez le bloc de XSL qui génère la liste à choix, qui se trouve dans le fichier dans la balise <xsl:template match="attribute" mode="input"> dans le fichier search_1.3.xsl original (qui peut être trouvé dans le plugin mypage ou à l'adresse

Le rendu de la liste est géré dans le bloc suivant, il va falloir que vous travailliez au niveau du <xsl:value-of select="."/> pour ne garder que ce qui vient après les ":" dans vos libellés. Et pour les classer par ordre alphabétique, cela se fait par un tri au niveau du "xsl:for-each".

<select id="{$fieldId}" name="{@name}">
    <option value=""></option>
    <xsl:for-each select="value">
        <option value="{.}">
            <xsl:if test="ancestor::search/values/value[@attribute = $id and @value = current()]">
                <xsl:attribute name="selected">selected</xsl:attribute>
            </xsl:if>
            <xsl:value-of select="."/>
        </option>
    </xsl:for-each>
</select>