Xsl personnalisé rendu par champ de recherche dans la vue liste (SharePoint 2010)

Je suis en train de modifier le rendu de l'une des colonnes de la liste sur la page d'affichage de liste.

Après quelques tutoriels et certains de s'arracher les cheveux, j'ai réussi à créer une transformation xslt pour un calculés et de la monnaie (de fldtypes_XXXXXX.xsl):

<xsl:template match ="FieldRef[@Name='MarkCalc']" mode="Text_body">
  <xsl:param name="thisNode" select="."/>
  <xsl:value-of select="$thisNode/@*[name()=current()/@Name]" disable-output-escaping ="yes"/>
</xsl:template>

<xsl:template match="FieldRef[@Name='CurrencyTest']" mode="Number_body">
  <xsl:param name="thisNode" select="."/>
  <b><xsl:value-of disable-output-escaping="yes" select="$thisNode/@*[name()=current()/@Name]" /></b>
</xsl:template>

Puis j'ai essayé de faire la même chose pour un champ de recherche, mais il juste ne fonctionnera pas. C'est ma dernière tentative (j'ai copié à partir de SharePoint designer). Ce qui me manque?

<xsl:template match="FieldRef[(@Encoded) and @Name='Lookup1']" mode="Lookup_body">
  <xsl:param name="thisNode" select="."/>
  <b><xsl:value-of select="$thisNode/@*[name()=current()/@Name]" disable-output-escaping="yes" /></b>
</xsl:template>

OriginalL'auteur Luc | 2010-05-28

  1. 8

    Comme il s'avère, c'est tout à fait xsl problème.

    Processeur Xsl choisit d'utiliser un modèle basé sur le "match" et "mode" des attributs. Lorsque deux ou plusieurs modèles de match, le seul à utiliser est choisi en priorité. Par défaut, il existe trois niveaux de priorités qui sont assignées en fonction de la façon spécifique de votre match.

    De http://www.codetoad.com/xml/xslt8.asp:

    • Motifs qui correspondent à une classe de nœuds, tels que *, qui correspond à toutes les
      éléments, sont affectées d'un implicite
      la priorité de -0.5

    • Motifs qui correspondent à des nœuds en fonction de leur nom, tels que le Caractère,
      ce qui correspond à des éléments,
      sont affectés implicite de priorité de 0

    • Motifs qui correspondent à des nœuds en fonction de leur contexte, comme
      CastMember/Caractère, ce qui correspond à
      les éléments dont le parent est un
      élément, est attribué à une
      implicite priorité de 0,5

    Lors de l'attribution des priorités sur la base de
    modèles, il n'a pas d'importance comment
    spécifique de l'information de contexte est:
    si vous spécifiez le contexte d'un nœud
    ensuite, le modèle a une priorité
    0.5. Par exemple, la Description/Liaison/Personnage a exactement
    de la même priorité que
    Description/Caractère/.

    Dans SharePoint, il existe deux modèles pour les champs de recherche

    <xsl:template name="FieldRef_Lookup_body" match="FieldRef" mode="Lookup_body" ddwrt:dvt_mode="body">...

    et

    <xsl:template match="FieldRef[@Encoded]" mode="Lookup_body" ddwrt:dvt_mode="body">

    Premier a la priorité 0 (match en fonction de son nom), le second, a la priorité de 0,5 (selon le contexte).

    Mon modèle personnalisé qui doit l'emporter sur les codée de recherche

    <xsl:template match="FieldRef[(@Encoded) and @Name='Lookup1']" mode="Lookup_body">...

    dispose également d'une priorité par défaut de 0,5 (rappelez-vous, "...il n'a pas d'importance comment le contexte spécifique de l'information, c'est..."), de sorte processeur xsl choisit le dernier définies(*).

    Pour surmonter cela, vous pouvez utiliser l'attribut de priorité et de le régler à plus de valeur que le modèle par défaut. Dans mon cas, je l'ai mis à 1.

    <xsl:template match="FieldRef[(@Encoded) and @Name='Lookup1']" priority="1" mode="Lookup_body">...

    (*) Apparemment SharePoint charges de modèles personnalisés avant de chargement de son propre. Si c'était un choix en fonction de certains critères techniques ou pour m'assurer d'en apprendre xsl, restent un mystère.

    J'aime votre (*) note 🙂

    OriginalL'auteur Luc

  2. 0

    J'ai eu un problème similaire, mais j'ai été à l'aide de Sharepoint 2013. Dans Sharepoint 2013 ceci est fait en utilisant le client de rendu, de sorte que cette méthode ne fonctionnera PAS. Insted découvrez http://www.sharepointnutsandbolts.com/2013/01/using-jslink-to-change-ui-of-sharepoint_20.html, ou l'utiliser (http://social.msdn.microsoft.com/Forums/sqlserver/en-US/9425e392-26ec-466b-a086-6581e035258f/sharepoint-2013-fldtypesxsl) méthode pour forcer le serveur de rendu.

    OriginalL'auteur Christian Flem