Solution sans code : affichage des jours depuis la dernière modification d’un élément de liste

Vue d’ensemble : Rapports personnalisés de vieillissement sans code

L’un des éléments fonctionnels souvent demandés d’un site SharePoint est un rapport vieillissant pour les tâches ou les éléments de liste. En d’autres termes, depuis combien de jours/mois cet élément de liste a-t-il été modifié pour la dernière fois ?

En surface, cela semble être une demande très simple. Après tout, nous avons des dates pour les éléments en cours de création et de modification, nous avons la possibilité de stocker des dates personnalisées lorsque certaines modifications apportées aux éléments ont lieu via des récepteurs d’événements. Nous avons calculé des colonnes dans lesquelles nous pouvons inclure des formules de type Excel pour utiliser nos informations. Cela semble être une proposition assez simple. Nous choisissons un champ de date, créons une colonne calculée, puis nous effectuons une formule sur les lignes [DateField] – [Aujourd’hui]. Ah, pas si vite ! Comme le sait toute personne ayant tenté cette tâche « simple », essayer d’utiliser quelque chose comme [Aujourd’hui] dans une colonne calculée entraîne des problèmes. Essayez d’insérer [Aujourd’hui] dans la zone de formule de votre colonne calculée pour obtenir un message d’erreur semblable à celui-ci :

Pourquoi ? Eh bien, cela a à voir avec la façon dont les colonnes calculées sont calculées.

Prenons une formule simple comme exemple :

= IF( [Column1]<=[Column2], « OK », « Not OK »)

Cela signifie que si Column1 est inférieur ou égal à Column2, affichez OK, sinon affichez Non OK. Il s’agit d’une formule de base assez classique pour une colonne calculée qui fait une hypothèse de base sur l’élément de liste qui contient ces colonnes : les valeurs de Column1 et Column2 ne pourront jamais être modifiées sans un événement Update sur l’élément de liste.

C’est exact, les colonnes calculées ne sont recalculées que lorsque la liste est mise à jour (ou créée), car elles supposent que les informations que vous calculez sont contenues dans l’élément lui-même. Cela crée un problème lorsque vous essayez d’utiliser un élément qui change indépendamment des champs de l’élément, comme la date du jour.

Maintenant, je n’étais pas dans la réunion où ils ont décidé que c’est la façon dont les colonnes calculées fonctionneraient, cependant, si je devais faire une estimation instruite, je supposerais qu’ils fonctionnent de cette façon pour les performances. Imaginez que vous disposiez d’une liste de plusieurs milliers d’éléments, chacun contenant une colonne calculée nécessitant une mise à jour « en direct ». Cela signifierait qu’un mécanisme, peut-être un travail de minuteur, devrait itérer au sein de chaque élément contenant cette colonne calculée à chaque fois et mettre à jour sa valeur. Cela peut être extrêmement lourd en termes de performances, car avec des déploiements plus importants, ce travail peut être constamment en cours d’exécution et changer les choses. C’est juste mon hypothèse, mais ça a un peu de sens si vous y pensez.

Il existe des suggestions pour des solutions similaires qui circulent autour de là qui impliquent de tromper SharePoint pour accepter une valeur Today en créant d’abord une colonne nommée Aujourd’hui, puis en l’ajoutant à votre formule, puis en la supprimant. Tout cela est bien, mais rappelez-vous ce que j’ai dit à propos de la mise à jour des colonnes calculées. Cette valeur change uniquement lorsque l’élément est mis à jour, ce qui signifie que vos valeurs seront bientôt incorrectes, en particulier dans le cas d’un calcul d’un jour.

J’ai vu d’autres utilisateurs utiliser un code JavaScript intelligent pour écrire les valeurs dans la page. Cela fonctionnerait aussi, mais je suis à peu près catégoriquement contre le script client quand il peut être évité.

Implémentation:

Alors que faire ? Les colonnes calculées sont hors de question pour les fonctions dites « volatiles » comme Today. Il est possible que nous puissions développer du code personnalisé pour prendre en charge cela pour nous, comme une colonne calculée, un travail du minuteur ou un processus planifié, afin de mettre à jour chaque élément qui a besoin de ce calcul. Cela nous ramène au problème de performance que j’ai mentionné dans le dernier paragraphe cependant, et en plus c’est une solution cassante qui serait très spécifique au site/liste/colonne en question. En plus de ces deux préoccupations, vous devrez également aller trouver un type nerdy, comme moi, qui sait comment coder et le persuader de développer cette solution pour vous. Mais il y a un moyen plus facile !

Si vous avez le droit de créer des champs et de modifier des pages sur votre site, et si vous avez un peu de connaissances sur XSLT et la création de vues, vous pouvez créer un modèle XSL qui peut être inclus dans un affichage de liste et calculera fidèlement votre valeur chaque fois que la page est demandée. Ce scénario supprime notre préoccupation en matière de performances et ne nécessite pas de développement et de déploiement de code personnalisé via une solution.

Parfait. Alors, comment faire ?

1. Créez ou sélectionnez le champ qui servira de source. Il doit s’agir d’un type date.

2. Créez notre champ qui servira d’espace réservé pour la valeur en cours de calcul.

3. Ajoutez ces deux champs à un type de contenu et ajoutez ce type de contenu à une liste.

4. Créez une vue de cette liste contenant à la fois les colonnes source et les colonnes d’espace réservé.

5. Chargez le modèle XSL dans la bibliothèque de styles.

6. Définissez la propriété « XSL Link » pour le composant WebPart Affichage de liste via l’interface utilisateur.

7. Réussite !

Explorons un exemple de cas d’usage et passons en revue l’implémentation. Notre client souhaitait avoir une vue de sa liste de main qui lui indiquerait depuis combien de temps un élément de liste particulier était assis à son status. Cette liste contenait un type de contenu de site personnalisé dérivé du type Item et ajouté à la liste. Il y avait déjà un récepteur d’événements en place qui capture chaque fois que status champ de l’élément de liste a été modifié et enregistré cette date dans une colonne appelée « Date de modification de l’état ». Tout ce câblage n’est pas obligatoire et peut être effectué avec n’importe quel champ de date (il se trouve que c’est notre implémentation, mais n’hésitez pas à expérimenter). Le strict minimum dont vous aurez besoin est votre champ de date source et le champ d’espace réservé pour contenir votre calcul (plus à ce sujet dans le paragraphe suivant) ajoutés à votre liste, même si je vous suggère d’utiliser des colonnes de site et des types de contenu de site au cas où vous souhaitez réutiliser cette solution à d’autres endroits sur votre site.

Nous avons donc notre date source que nous pouvons utiliser dans notre calcul par rapport à la date d’aujourd’hui. Nous pouvons maintenant créer une colonne de site personnalisée à utiliser comme conteneur pour notre valeur calculée. Dans ce cas, j’ai choisi d’utiliser une colonne calculée, car elle ne peut pas être modifiée sur les formulaires d’élément nouveau ou de modification, mais peut être sélectionnée pour être affichée dans les vues, car nous ne voulons pas que les utilisateurs entrent des valeurs arbitraires dans cette colonne. Il peut être confus quant à la raison pour laquelle il n’est pas affiché dans les vues, etc.

Maintenant que nous avons notre colonne de site, nous pouvons l’ajouter à nos types de contenu qui seront utilisés dans notre liste. Ensuite, nous devons créer notre vue qui sera personnalisée ultérieurement avec notre XSLT. Veillez à créer une vue standard qui contient votre colonne de date source et votre nouvelle colonne calculée qui fera office d’espace réservé pour la valeur calculée.

Nous avons maintenant tout ce dont nous aurons besoin pour prendre en charge notre rapport personnalisé sur le vieillissement. Il ne reste plus qu’à créer notre modèle XSL, à le charger dans la bibliothèque de styles du site et à le lier à notre affichage liste. Le modèle XSL que nous allons utiliser contiendra un balisage généré par SharePoint normal pour générer l’affichage, ainsi que notre propre balisage personnalisé utilisé pour remplacer certaines parties de ce et calculer la valeur souhaitée pour nous.

En donnant un crédit là où le crédit est dû, les modèles XSL pour effectuer les calculs réels que j’utilise pour cette solution ont été gracieusement fournis par « swirch » sur les forums MSDN :
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Téléchargez la feuille de style XSL (aging.zip) que j’ai rassemblée ici :
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

En ouvrant cela dans votre éditeur de texte favori, vous verrez beaucoup de balises XSL SharePoint normales pour le rendu des vues. Si vous continuez à faire défiler jusqu’à la ligne 357, vous verrez le début des modèles personnalisés que j’ai ajoutés au balisage, le premier étant le modèle « DateDiff » suivi de « calculate-julian-day » et « FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status ». Il s’agit de nos trois modèles qui effectuent et affichent nos calculs dans nos vues. Si vous envisagez d’utiliser des noms de champs différents de ceux spécifiés précédemment dans cet article, vous devez parcourir ces modèles et remplacer toutes les références aux autres noms. N’oubliez pas que pour cela, vous devez utiliser le nom INTERNE du champ et non le nom d’affichage.

Une fois que vous êtes convaincu que le modèle est prêt, accédez à votre bibliothèque de styles et chargez-le sous le dossier « Feuilles de style XSL », puis copiez le lien vers le bas vers le fichier. Cela nous permettra d’y apporter facilement des modifications ultérieurement ou de l’ajouter à différentes parties du site à notre guise.

Ensuite, accédez à votre liste et sélectionnez la vue que vous avez créée précédemment dans cet article. Dans le menu « Actions du site », cliquez sur « Modifier la page ».

Recherchez votre composant WebPart Affichage de liste sur la page et ouvrez le menu Du composant WebPart en cliquant sur la petite flèche vers le bas dans le coin supérieur droit. Dans ce menu, sélectionnez « Modifier le composant WebPart ».

Cela ouvre le menu du composant WebPart sur le côté droit de la fenêtre de votre navigateur.

Cliquez sur + pour la section « Divers » et recherchez la propriété « XSL Link ».

Collez le lien vers votre fichier XSL dans votre bibliothèque de styles que vous avez copiée précédemment (il peut s’agir d’un lien relatif ou absolu).

Cliquez sur « OK » pour enregistrer vos modifications, puis cliquez sur le bouton « Arrêter la modification » dans le ruban « Page » en haut de la page.

Si tout a été configuré correctement, vous devez maintenant voir des nombres dans votre colonne « Jours à l’état ».

Et enfin, voici à quoi il ressemblerait avec quelques données de test de différentes dates :

Résumé

Voilà : un moyen bien mis en forme, robuste et plus performant de créer un rapport vieillissant dans SharePoint. Avec une implémentation simple sans code. Ceci a un certain nombre d’applications potentielles en dehors du cas d’usage que nous avons exploré ici. Un autre scénario courant pour ce type de rapport consiste à l’attacher à une liste de tâches afin que vous puissiez voir depuis combien de temps une tâche a été créée en un coup d’œil.

Amusez-vous bien !

--Justin

Justin Joyce, LANtek

Commentaires

Étapes manquantes
8/10/2012 3:51 AM
Ok j’ai suivi les étapes, mais il doit y avoir quelque chose manquant - comment le XSL saura-t-il quelle date utiliser, ou quel champ ajouter les jours depuis ? haïssez-le quand des étapes sont manquées.

No-Code, d’accord !
30/08/2012 12:12 PM
Je suis d’accord - je ne pense pas que cela compte vraiment comme « pas de code ».
Fait intéressant, grâce à une certaine visup de SharePoint, j’ai une colonne calculée de travail en utilisant Aujourd’hui... je ne sais pas comment ou pourquoi parce que je ne peux pas le faire à nouveau, mais celui-ci est toujours là et travaille.

Formule pour la colonne calculée « Jours à l’état » ?
02/05/2012 7:39 AM
Justin - Quelle est la formule que vous avez utilisée pour votre colonne de site calculée « Jours à l’état » (colonne d’espace réservé) ? C’était « =aujourd’hui » ?

SharePoint 2007
2/12/2011 11:29 AM
Actuellement, je n’ai pas essayé d’appliquer cette solution à SharePoint 2007, mais j’y cherche. Malheureusement, aucune propriété XslLink n’est exposée sur le composant WebPart via l’interface utilisateur.

Grand billet
30/11/2011 09:53
Bonjour
Super poste.
J’utilise SharePoint 2007.
Je n’ai pas de section Misc comme indiqué ci-dessus.
Avez-vous des étapes pour une configuration SP2007 ?
Merci.

Re : Solution sans code : affichage des jours depuis la dernière modification
d’un élément de liste SharePoint 11/10/2011 8:24 AM
Salut Chris.
grande trouva ment !
Je vais jeter un coup d’œil à ce que vous avez publié plus tard sur aujourd’hui et voir si je peux rendre cette solution un peu plus robuste.
Je suis heureux que vous avez aimé le poste, et je suis très heureux que vous ayez pu trouver une solution au format de date européen.
:) -Justin

Solution pour les formats
de date européens 11/10/2011 6:45 AM
Salut encore Justin,
Pour info, j’ai trouvé une solution pour le problème que j’ai mentionné précédemment sur cette page ;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Formats
de date européens 07/10/2011 3:59 AM
Bonjour Justin,
C’est une très bonne solution grâce, et juste le genre de chose que j’ai passé les deux derniers jours à chercher ! Mais j’ai un peu de problème avec ça et j’espérais que tu pourrais m’aider.
J’ai légèrement modifié votre code pour calculer le nombre de jours jusqu’à ce que quelque chose se produise, plutôt que depuis, en basculant les variables dans la dernière ligne de la fonction « DateDiff » ;

<xsl :value-of select="$JulianToday - $JulianStartDate"></xsl :value-of>

Cependant, je ne suis capable de l’obtenir pour caclulate la différence correctement la moitié du temps. Par conséquent, pour instance avec cette date (format jj/MM/aaaa) ;

30/12/2011

Il calcule correctement, mais avec cette date (même format)

10/12/2011

Il calcule comme si le 10-Déc-2011 plutôt que le 12-Oct-2011.
J’ai simplement essayé de changer les positions des valeurs jour et mois dans la variable « JulianStartDate », comme suit ;

<xsl :with-param name="Month » select="substring(ddwrt :FormatDateTime(string($StartDate), 1033, 'yyyyyMMdd'),7,2)"/>
<xsl :with-param name="Day » select="substring(ddwrt :FormatDateTime(string($StartDate), 1033, 'yyyyyMMdd'),5,2)"/>

Et cela a corrigé le problème avec la deuxième date, mais il était ensuite incorrect pour la première date !
J’ai également essayé de modifier les appels FormatDateTime pour utiliser des LCID européens et diverses modifications apportées au dernier paramètre de FormatDateTime (par exemple, ddMMyyyyy, MMddyyyy) avec les ajustements appropriés aux paramètres positionnels de sous-chaîne sans succès.
J’apprécierais beaucoup tous les conseils que vous pouvez offrir.
Merci
Chris

Sans code
21/09/2011 4:27
Je ne pense pas que XSL soit considéré comme une solution « sans code », car la compréhension du langage XSL n’est pas pour tout le monde - mais elle n’implique pas de programmation. D’ailleurs : Belle solution, merci !