500 000 lignes générées !
Je n’arrive pas à croire que SharePoint Designer ne corrige pas cette histoire de lignes vides générées par milliers quand on modifie une page (surtout en manipulant du XSLT).
Si jamais une page ou une vue devient si grosse que le Designer n’arrive plus à l’ouvrir, voici comment faire :
– Sous le Designer 2010, faire Fichier > Options > Général > Options des applications > Configurer les éditeurs
– Placer en 1er le bloc-note comme éditeur des ASPX
– Ainsi, il sera possible d’ouvrir plus facilement…
Pour éliminer les lignes vides, reste à utiliser Notepad++, avec le plugin TextFX…
Étiquette : XSL
XSL / Sharepoint : "L'affichage spécifié n'est pas valide"
C’est pas du 16/9ème ?
… ou encore en anglais : « The specified view is invalid ».
Cette erreur peut intervir lorqu’on créé une DataFormWebPart (DFWP) sous le SharePoint Designer (en partant d’une webpart native (ListViewWebPart), et en la convertissant en vue XSL).
Lorsqu’on va exporter cette webpart, et l’intégrer dans une page, l’erreur va survenir. Il va alors falloir aller dans la page de maintenance et supprimer la WP.
Certains forums donneront cette solution : Editer le fichier *.webpart dans un bloc-note, et supprimer la propriété « viewflag« . Mais cette action à des effets de bord bien plus perfides.
Je pense (pour l’instant) que la meilleure chose à faire et de partir d’une source de données (au lieu d’une webpart native) pour créer sa DFWP.
XSL / Sharepoint : Doublons des entrées dans les filtres (DataFormWebParts)
La chose faite d’houblon.
Dans le cas de DataFormWebParts à sources de données aggrégées, il se peut que les filtres des en-têtes contiennent plusieurs fois les mêmes valeurs.
Ce petit bug d’affichage est corrigible en allant manipuler le code XSL de la page (via le SharePoint Designer).
Dans le template nommé « dvt.filterfield« , trouver une boucle for-each qui appelle le template « filteroption » :
<xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />
</xsl:call-template>
La boucle qui appelle ce template est censée faire un « distinct » sur les données à lister, mais ça ne fonctionne pas toujours.
Les données sont cependant triées, on va donc autoriser l’affichage de la donnée à chaque fois qu’on change de valeur dans la boucle. Pour cela, il suffit d’encadrer cet appel par la condition suivante :
<xsl:variable name="OptionValue" select="ddwrt:NameChanged(string(.), 0)" />
<xsl:if test="string-length($OptionValue)">
<xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" /> </xsl:call-template>
</xsl:if>
NB : NameChanged teste si une valeur change depuis sa dernière affectation.
XSL / XPath / Sharepoint : Problème du double encodage des données.
L’esperluette m’a tué
J’ai rencontré ce problème en créant une « DataFormWebPart » sous le Sharepoint Designer. Les données finales affichées (HTML) étaient doublement encodées par rapport à la source de données.
Prenons cet élément d’une liste SharePoint :
L'iPad est nul
A travers une DataFormWebPart créée sous le sharepoint Designer, il ressortira ainsi
L"iPad est nul
Cause : il y a eu double encodage : L'iPad est nul -> L"iPad est nul -> L&quot;iPad est nul
Et sur le navigateur, le résultat est celui-ci : L"iPad est nul
Le problème vient du XSL, au moment d’afficher la valeur :
<xsl:value-of select="@Valeur"/>
Il faut ajouter l’attribut suivant : disable-output-escaping= »yes »:
<xsl:value-of select="@Valeur" disable-output-escaping="yes" />
Sans aller dans les tréfonds du code XLS, le Sharepoint designer peut aider à la tache :
- Se mettre en mode « création »
- Survoler l’un des éléments de la webpart
- Changer le type d’affichage (passer le « texte brut » à « texte enrichi »).