J’ai des xsl qui transforment du contenu Opale like vers du LaTeX. tout se passe à peu près bien sauf que j’ai besoin de connaitre la nature des ressources pour produire les bonnes balises LaTeX. J’ai utilisé pour ça des requêtes du style : <xsl:variable name="uri" select="@sc:refUri" /> <xsl:choose> <xsl:when test="substring($uri, (string-length($uri) - string-length('.jpg')) + 1) = '.jpg'...> blabla
Dans Builder/test tout est ok. Dans SCchain en local tout est ok mais quand je passe sur un sernariserver là ça coince. Je pense que les sc:refuri sont modifiés pour que ça correponde aux infos de la bdd qui gère les items scserver. J’ai par exemple ceci dans l’éditeur texte.
<sp:res sc:refUri="id:zq4blAkZdZIcbwUpPFJJ3i">
Par contre dans l’éditeur XUL ça conserve bien le nom de la ressource donc je suppose que c’est requétable.
Du coup est-ce que vous pourriez me dire comment récupérer le nom du fichier en xsl pour pouvoir faire le ou les traitements dont j’ai besoin.
Effectivement, il ne faut pas utiliser la valeur de sc:refUri en tant que tel pour déterminer la nature de l’item fils, car ce champ possède des morphologies très différentes en fonction des environnements techniques (SCENARIchain-server, SCENARIchain-serverLite, …).
Dans le contexte d’un générateur :
Approche 1 : récupérer le path (srcUri dans le langage scenari)
Pour récupérer le path de façon fiable dans un contexte XSL, tu peux écrire : srcFields(resolveSrcPath(@sc:refUri), 'srcUri')
Approche 2 : récupérer le code de la primitive associée au .model fils : srcFields(resolveSrcPath(@sc:refUri), 'itModel')
Approche 3 : récupérer le « type » du transformer (agent) fils : typeAgent(concat('@',gotoSubModel()))
On pourrait imaginer d’autres approches encore en fonction des besoins
J’ai testé avec l’approche 1 est ça marche effectivement comme je le souhaitais.
Le temps pour faire le test est du coup un peu plus long à cause de la génération du pack puis déploiement et en mode essai/erreur tu fais ça x fois mais le principal c’est que ça roule.
Si j’ai bien compris ta dernière remarque : dans l’onglet « Compil » du wspDef, tu as l’option « Contexte de test », si tu choisis « Base de données » et non « Système de fichier », l’environnement de test intégré à SCbuilder se comporte comme un serveur.
