Bonjour à tous,

Cette fois encore je vais écrire une série de posts qui traitent d'un sujet commun mais que je préfère écrire en plusieurs fois pour rendre la lecture plus simple. Chaque post traitant d'une partie du sujet indépendante des autres.

Ce premier post traitera des noms intenes, des noms d'affichages et des URLs dans SharePoint, le second traitera de quelques limites fixées de l'outil SharePoint sur ces éléments (et il arrivera bientôt).

SharePoint est un progiciel, et qui dit progiciel dit paramétrage à outrance. Le progiciel étant la volonté d’avoir un outil à la fois très générique pour s’adapter au plus grand nombre et tout en même temps assez spécifique (vertical dit-on dans le métier) pour permettre une mise en œuvre rapide (vous sentez le paradoxe ?). De plus dans la globalisation du travail à laquelle nous faisons face, SharePoint se devait d’être multilingue.

"Jusque-là aucun problème ?" me direz-vous.

Et bien si, ceci est un problème car développer et paramètrer un environnement entièrement polymorphe (dont les noms et champs peuvent changer tout le temps) n’est pas du tout envisageable. Or un progiciel a besoin d'être polymorphe pour réellement s'adapter au métier et à l'organisation des clients.

D’un autre côté, fixer le nom des champs pour l’intégralité de l’application n’est pas envisageable non plus !

Imaginez : créer une colonne dont le nom serait fixé à l’avance et que vous ne pourriez pas changer, type : data1, data2, data3,… Bonjour l'horreur pour la mise en oeuvre...


Alors que faire ?

Recourir aux noms internes pardi ! Ainsi beaucoup d'éléments dans SharePoint possèdent un nom interne (qui ne varie pas) et un nom d’affichage qui lui peut varier à tout moment. Certains éléments comme les sites ou les listes possèdent eux plutôt une URL (qui fait office de nom interne) et un nom d'affichage.

Ainsi à présent nous avons un champ interne dont le nom ne varie pas (et donc auquel nous pouvons faire référence sans risque) et un nom d'affichage qui peut varier et s'adapter au contexte, à la langue, au grés et envies de l'utilisateur...

"Tout ça c’est bien beau", me direz-vous, "mais encore une fois beaucoup de texte et toujours pas de problème à l'horizon..."

Et encore une fois votre optimiste fait chaud au coeur mais vous conduira droit à votre perte (de cheveux dans ce cas...). Car le soucis c’est que SharePoint vous a masqué (légèrement) qu’un tel nom interne existait !!! Et surtout qu'il ne supportait pas les caractères spéciaux et espaces !

 

(Sentez-vous la tension monter maintenant ?)

 

Disgression 1 : Bon, soyons honnête, l’apprentissage de SharePoint n’est pas forcément des plus aisé, et si au départ on parlait de champs internes et de noms d'affichage certains se jetteraient par les fenêtres. C'est pourquoi souvent cette notion est passée sous silence. Cependant c'est très important de bien comprendre le fonctionnement de ces noms comme nous allons le voir à présent.

Donc comme je le disais, un des premier soucis auquel on peut être confronté avec ce nom interne c'est qu'il n'accepte pas les caractères spéciaux ni les espaces, et qu'il les remplace donc par des équivalents.

Ainsi :

  • "espace" devient _x0020_
  • "é" devient _x00e9_
  • "è" deivent _x00e8_
  • "'" (apostrophe) devient _x0027_
  • ...

Ce qui rend la lecture un peu fastidieuse car le champ : "Interlocuteur demandé" devient "Interlocuteur_x0020_demand_x00e9_"

De plus lorsque ce nom doit être affiché dans une URL, le sous-tiret bas (underscore : _) est remplacé par des %5f et devient donc : "Interlocuteur%5fx0020%5fdemand%5f00e9%5f", ce qui est franchement illisible...

Pire ces remplacements allongent la taille du nom interne de l'élément, or ce nom interne a souvent une taille maximum et sera tronqué en cas de dépassement (voir prochain article pour ce problème...).


"Hé là l'ami, arrête un peu ton char, j'ai jamais vu de champs nom interne et nom d'affichage dans SharePoint..."

Je ne sais qui a lancé cette remarque très judicieuse mais grand bien lui en a pris car c'était justement le sujet de mon prochain chapître...(Et hop une transition rondement menée, une !)

En effet, rares sont les pages de paramètrage dans SharePoint qui font état de ces deux noms, cependant ils existent (si si croyez moi monsieur l'agent je les ai vus !!!).

Et en voici donc des exemples :


A - Colonnes et colonnes de site

J'ai groupé ces 2 champs car leur comportement est identique. Ils sont sûrement les éléments dont les noms interne et d'affichage sont les moins visibles.

Voici donc un petit exercice...

1 - Création d'une colonne

Rendez-vous dans une liste quelconque et créez une colonne : "Interlocuteur demandé" de type texte :

1.png

2.png
Cliquez sur les images pour agrandir

Laissez les valeurs par défaut puis valider votre saisie. Vous devriez obtenir ceci (ici dans une liste personnalisée)

3.png
Cliquez sur l'image pour agrandir


2 - Visualisation du nom interne

Cliquez sur votre champ et regardez dans l'url la section après "&field=". Ceci est le nom interne de votre champ, vous voyez que ce n'est pas très lisible.

4.png
Cliquez sur l'image pour agrandir

Sachant que vous aurez parfois à faire référence à ce nom dans votre code ou paramètrage (comme pour la recherche par exemple), c'est pas gagné !


3 - Modification du nom d'affichage

Tant que vous êtes dans la page de modification, profitez-en pour modifier le nom de votre champ de "Interlocuteur demandé" en "Correspondant".

5.png
Cliquez sur l'image pour agrandir

Valider votre modification, votre nom de champ a changé mais ici ce n'est que le nom d'affichage

7.png
Cliquez sur l'image pour agrandir


4 - Visualisation du nom interne et d'affichage

Si vous retournez dans la page de modification vous voyez que le nom d'affichage du champ a été changé mais pas le nom interne.

6.png
Cliquez sur l'image pour agrandir

/!\ Attention : pour une colonne il n'est pas possible de changer le nom interne d'un champ, celui-ci est fixé à partir du nom d'affichage lors de la création du champ selon les règles précisées plus haut.

Conclusion : à la création de votre champ il faut penser à d'abord créer le nom interne (sans caractères spéciaux, ni espace) puis modifier le nom du champ pour lui donner le nom voulu. Ainsi pour notre champ d'exemple nous aurions d'abord créé le champ avec le nom : "InterlocuteurDemande" puis serions venu modifier le nom en "Interlocuteur demandé"



B - Listes et bibliothèques

Pour les listes et bibliothèques le nom interne correspond au nom utilisé pour composer l'URL (adresse) de la liste. Voici donc un exercice pour voir le comportement de SharePoint dans ce cas

1 - Création d'une nouvelle liste

Créez une nouvelle liste de type "Liste personnalisée" et appelez la : "Ma liste personnalisée"

8.png
Cliquez sur l'image pour agrandir


2 - Visualisation de l'URL

Une fois votre liste créée, regardez l'URL et vous verrez que le caractère "é" contenu dans "personnalisée" a disparu (car les caractères spéciaux sont supprimés par SharePoint pour les URLs), de plus pour être conforme à la norme URL, les espaces sont remplacés par un %20

9.png
Cliquez sur l'image pour agrandir


3 - Modification du nom de la liste

Allez dans les paramètres de la liste pour modifier son nom

11.png
Cliquez sur l'image pour agrandir

Remplacer le nom "Ma liste personnalisée" par "Ma liste à moi" et validez.

10.png
Cliquez sur l'image pour agrandir


4 - Visualisation du nom de la liste

Votre liste à bien changée de nom d'affichage

12.png
Cliquez sur l'image pour agrandir

Mais l'URL continue d'afficher le premier nom (le nom "interne")

13.png
Cliquez sur l'image pour agrandir


/!\ Attention : Comme pour les colonnes il n'est pas possible de modifier le nom interne (l'URL) d'une liste. On peut cependant copier la liste vers une autre destination (une autre URL, donc un autre nom interne) et supprimer la première liste.

Conclusion : comme pour les colonnes, pensez à créer d'abord votre liste avec le nom interne désiré puis changez son nom vers le nom d'affichage voulu.



C - Les sites

Les sites fonctionnent de la même manière que les listes sauf que l'URL du site peut-être fixée lors de la création du site et en modification.

1 - Création du site

14.png
Cliquez sur l'image pour agrandir

2 - Modification du site

En passant par les paramètres du site, dans la section "Titre, description et icône"

15.png
Cliquez sur l'image pour agrandir

On peut modifier cette URL après que le site soit créé (mais attention aux liens pointant sur cette "ancienne" URL)

16.png
Cliquez sur l'image pour agrandir

Conclusion : Penser à créer votre site avec une URL explicite et lisible, en remplaçant les espaces par des sous-tirets bas (underscore), et en ne mettant pas de caractères spéciaux.

Disgression 2 : Si vous vous dîtes que l'URL n'est pas importante car personne ne la lit, demandez-vous alors pourquoi on ne met pas que des URLs du type http://152650/121321564/?sddsfd122... Qui seraient plus simples à gérer côté code... L'URLs est lue bien plus souvent qu'on ne le croit par les visiteurs pour vérifier qu'ils se trouvent au bon endroit.



D - Cas spécial 1: Les vues (affichages)

Les vues représentent un cas à part car elles sont à mi-chemin entre les listes et les sites : on ne peux fixer leur URL à la création (qui est déduit du nom de la vue), mais on peut le faire à la modification

1 - Création d'une vue

18bis.png

17.png

18.png
Cliquez sur les images pour agrandir

Le résultat dans l'URL est le suivant

19.png
Cliquez sur les images pour agrandir

2 - Modification d'une vue

Au contraire des listes on peut modifier l'URL d'une vue en modification (comme pour les sites)

20.png

21.png
Cliquez sur les images pour agrandir

J'avoue que je suis un peu perplexe sur la démarche... Mais c'est ainsi.

Conclusion : Pensez à modifier l'URL de vos vues après création pour quelles soient plus explicites et lisibles, en remplaçant les espaces par des sous-tirets bas (underscore), et en ne mettant pas de caractères spéciaux.



E - Cas spécial 2 : Les types de contenu

Les types de contenu sont eux aussi un cas à part car ils n'ont pas à proprement parlé de nom interne, ils disposent cependant d'un ID qui est créé automatiquement à partir de l'ID du type de contenu dont il hérite (si cela vous semble nébuleux, passez votre chemin car l'explication de la création d'un type de contenu pourrait largement dépasser la taille de cet article déjà conséquent :D )

22.png
Cliquez sur l'image pour agrandir

Ici l'ID est visible dans l'URL en bas et suit le paramètre "?ctype="

/!\ Attention : Cet ID n'est modifiable ni à la création (à moins de créer son type de contenu avec une feature), ni en modification.


Conclusion générale:

Voilà, j'espère que ceci vous permettra de mieux comprendre le fonctionnement de SharePoint sur l'attribution des noms internes et des URLs. Ceci est souvent source de problème lors de développement car certains objets font référence aux noms internes, aux noms d'affichage ou aux deux... C'est aussi un problème pour du "simple" paramètrage, par exemple si vous créez de nouvelles propriétés gérées dans le moteur de recherche de MOSS pour créer de nouvelles étendues de recherche, le mappage de la propriété gérée vers un champ se fait sur le nom interne...

D'une manière générale il est important de garder des noms internes propres et courts car la limite se situe à 32 caractères maximum. Mais ceci fera l'objet d'un prochain article (et hop voici comment je vous tiens en haleine pendant la pub...)

Bon code à tous !