Cet article a fait l'objet d'une traduction automatique.

Développement SharePoint

Création d'une architecture d'informations dans SharePoint 2010

Shahram Khosravi, pH.d.

Télécharger l'exemple de code

La version de Microsoft SharePoint 2010 vu des nouvelles fonctionnalités de gestion des contenus d'entreprise (ECM) ajoutées au logiciel de collaboration. Cet article explique comment tirer parti de ces nouvelles fonctionnalités pour créer l'architecture d'informations flexible, extensible et facile à gérer pour les deux types suivants de portails :

• Portails de publication/intranet/extranet connecté à Internet
• Portails de gestion des connaissances

Je vous décrirai par le biais de la conception et la mise en oeuvre de plusieurs composants personnalisés SharePoint qui peut être utilisé pour mettre en œuvre de l'architecture d'informations pour ces portails.

Architecture des informations de création pour/Intranet/Extranet orientés Internet portails de publication

Traditionnellement, les portails de publication/intranet/extranet orientés Internet suivent un modèle de navigation guidée strictement où les éléments GUI comme les menus sont utilisés pour guider les utilisateurs vers le contenu, qu'ils recherchent. Ces portails ont normalement un sommet et un menu de navigation de gauche.

Le menu de navigation supérieure est généralement un AspMenu qui permet aux utilisateurs d'effectuer des sélections des premier et deuxième niveaux de la taxonomie de portail. Le menu de navigation de gauche est généralement un AspMenu qui permet aux utilisateurs d'effectuer des sélections des niveaux de la taxonomie portail troisième et quatrième (ou d'éventuellement cinquième).

L'intégralité du contenu du portail est divisé en un ensemble de catégories qui forment le premier niveau. Je vais utiliser la convention d'affectation de noms suivante pour les catégories : termei où iprend en charge un nombre entier. Par exemple, les premier et deuxième catégories sont nommés Term1 et Term2, respectivement.

Le contenu de chaque catégorie est ensuite divisé en un ensemble de sous-catégories qui constituent le deuxième niveau. Je vais utiliser la convention d'affectation de noms suivante pour les sous-catégories : termeij où i et j prendre des valeurs entières. Par exemple, la première sous-catégorie de la première catégorie est nommée Term11.

Cette catégorisation du contenu continue jusqu'à ce que nous atteignions la granularité de votre choix. Figure 1 montre cette taxonomie portail.

Figure 1 portail taxonomie

Ce portail taxonomie est normalement implémenté dans SharePoint 2007 par le biais de l'établissement de la structure du site approprié. Je vais commencer par créer un site distinct pour chaque catégorie. Je vais ensuite créer des sous-sites distincts sous chaque site de catégorie pour les sous-catégories respectifs et ainsi de suite. Figure 2 montre la structure du site du portail.

Figure 2 la Structure du Site du portail

En fait, chaque catégorie, sous-catégorie, sub-subcategory etc. possèdent son propre site dédié. Ce site dédié contient une bibliothèque de documents Pages contient les pages de ce site. Si je devais utiliser le langage de mise en réseau social, je pourrais en dire que toutes les pages de la bibliothèque de documents Pages d'un site sont implicitement balisés de catégorie, sous-catégorie ou sub-subcategory qui représente le site. D'une manière, j'ai balise implicitement une série de pages associées à une catégorie, sous-catégorie ou un sub-subcategory en les créant dans un site qui représente cette catégorie ou sous-catégorie sub-subcategory. De cette façon, je crée une nouvelle balise implicite (ou le terme), en créant un nouveau site.

La barre de navigation supérieure AspMenu affiche ces catégories (premier niveau) et leurs sous-catégories (L2). L'utilisateur sélectionne une catégorie ou sous-catégorie dans cette AspMenu pour accéder à la page est marquée implicitement avec cette catégorie ou sous-catégorie.

Lorsque l'utilisateur sélectionne une sous-catégorie à partir du menu de navigation supérieure, la barre de navigation gauche AspMenu (lancement rapide) affiche les sub-subcategories associés à cette sous-catégorie. L'utilisateur sélectionne un sub-subcategory à partir de cette AspMenu pour accéder à la page est marquée implicitement avec ce sub-subcategory. La bibliothèque de documents Pages d'un site donné peut contenir plusieurs pages, qui signifie que plusieurs pages peuvent être marqués avec la même catégorie ou sous-catégorie sub-subcategory implicitement. La barre de lancement rapide affiche les liens vers toutes les pages sont implicitement balisés avec la même sub-subcategory.

Comparaison des Figure 1 et Figure 2 clairement montre que l'architecture de classification ou informations portail reflète directement le portail de structure du site. Cela rend l'architecture d'informations fixes et présente les problèmes suivants :

• Création d'une nouvelle balise implicite requiert l'autorisation d'administration de site pour créer un nouveau site.
• Modification d'une page nécessite déménagement physique de la page d'un site à l'autre.
• Réorganisation de l'architecture d'informations requiert physiquement déplacement et suppression de sites et pages.
• Les auteurs de contenu ne sont pas en mesure de partager la même page dans plusieurs catégories, sous-catégories, sub-subcategories et ainsi de suite. Ils doivent créer une page distincte pour chaque catégorie et sous-catégorie ainsi de suite, car chacun est un site distinct. L'option uniquement out-of-the-box consiste à copier la page aux sites respectifs. Cette solution présente deux problèmes de facilité d'utilisation. Tout d'abord, l'auteur du contenu a copier la page dans différents endroits. Ensuite, chaque fois que l'auteur du contenu modifie le contenu dans une page, il a revenir en arrière à toutes ces copies dans tous ces sites pour effectuer les mêmes mises à jour ou de copier la page à nouveau. Cette solution constitue un risque d'erreur.
• Étant donné que la modification de taxonomie requiert des modifications structurelles dans la structure du site, qui implique beaucoup de temps et d'efforts, la classification est très strictes. Taxonomie est étroitement liée à la manière des informations sont stockées dans la collection de sites.

Saisissez SharePoint 2010 ECM. Vous pouvez désormais implémenter votre portail taxonomie dans une application de service de métadonnées managé où vous le gérer centralement. Cette mise en oeuvre plus dépend de la structure de votre site portail :

• Vous n'avez pas besoin de provisionner de nouveaux sites juste à créer de nouveaux marqueurs implicites. Vous ajoutez simplement les nouveaux termes à taches souhaités dans la taxonomie portail dans le magasin de terme. De cette façon, vous pouvez maintenant conserver toutes vos pages dans la bibliothèque de documents Pages sur le même site car l'évolutivité des bibliothèques de documents n'est plus un problème dans SharePoint 2010. Cet article suppose que toutes les pages sont conservées dans une seule bibliothèque de documents Pages dans un site unique.
• Vous pouvez modifier le balisage d'une page avec un nouveau terme sans avoir à déplacer physiquement la page.
• Vous pouvez réorganiser votre taxonomie en réorganisant simplement votre taxonomie dans le magasin à terme sans avoir aux déplacer ni supprimer des sites et pages.
• Vous pouvez partager la même page dans plusieurs catégories, sous-catégories et ainsi de suite par balisage simplement la page avec plusieurs termes — où chaque terme représente une catégorie, sous-catégorie etc. — sans avoir à copier physiquement la page entre les sites.

Je vais implémenter la taxonomie de portail comme un seul terme, comme indiqué dans Figure 3.

Figure 3 mise en œuvre de portail taxonomie dans l'Application de Service de métadonnées managé

Toutefois, la mise en œuvre de la taxonomie portail dans un magasin à terme à la place de la structure du site portail introduit deux défis présentés dans les sections suivantes.

Le contrôle TaxonomyDataSource

Tout d'abord, la page maître v4.master est livré avec un AspMenu qui affiche le menu de navigation supérieure. Ce contrôle est lié à un contrôle site map data source utilise un fournisseur pour récupérer les données de plan de site à partir de la structure du site portail. Cela ne va pas fonctionner dans ce cas car je souhaite que les données de plan de site provenant de la banque à terme, pas la structure du site physique du portail.

Une option consiste à implémenter un fournisseur de plan de site personnalisé qui extrait les termes appropriés à partir du magasin à terme. Une autre option consiste à implémenter un contrôle de source de données personnalisé. J'utiliserai ce dernier dans la mesure où ASP.NET est fourni avec un contrôle de source de données puissante nommé XmlDataSource je peux facilement étendre mon objectif. Je nommerai ce contrôle de source de données personnalisé TaxonomyDataSource.

TaxonomyDataSource expose une propriété booléenne nommée IsGlobal. Nous allons inclure deux instances de TaxonomyDataSource dans la page maître. Une seule instance sera liée à la AspMenu affiche le menu de navigation supérieure. La propriété IsGlobal de cette instance est fixée à true pour récupérer tous les termes du mandat défini qui contient la taxonomie de portail. Ainsi, le menu de navigation supérieure pour afficher toutes les catégories et leurs sous-catégories. Gardez à l'esprit que les catégories et leurs sous-catégories respectifs sont nothing, mais les termes enfant et petit-enfant de ce terme définis.

La deuxième instance sera liée à la AspMenu affiche le menu de navigation de gauche (menu de lancement rapide). La propriété IsGlobal de cette instance est fixée à false pour récupérer uniquement les subterms du terme en cours. Laissez-moi élaborée sur ce que je veux dire par « terme en cours ».

Rappelez-vous que lorsque l'utilisateur sélectionne une sous-catégorie à partir du menu de navigation supérieure, le menu de navigation de gauche doit afficher la liste des sub-subcategories associées à cette sous-catégorie. Le terme courant dans ce contexte est la sous-catégorie. La deuxième instance renvoie essentiellement enfant du terme en cours et des termes de petit-enfant, qui ne sont rien, mais la sub-subcategories et sub-sub-subcategories.

TaxonomyDataSource substitue la propriété de données pour récupérer la taxonomie portail à partir du magasin à terme. L'objectif principal de la propriété de données consiste à créer le document XML que XmlDataSource utilise pour créer les nœuds qu'il transmet à AspMenu. Cette propriété utilise tout d'abord les métadonnées SharePoint 2010 managed API pour accéder au jeu de terme qui contient la classification de portail, comme illustré ici :

TaxonomySession taxonomySession = new TaxonomySession(SPContext.Current.Site);
TermStore termStore = taxonomySession.TermStores[this.TermStore];
Group group = termStore.Groups[this.Group];
TermSet termSet = group.TermSets[this.TermSet];

La propriété utilise tous les termes à terme défini si IsGlobal est vraie :

termsToReturn = termSet.Terms;

Si IsGlobal est false, la propriété accède tout d'abord le GUID du terme en cours, qui est exposé via le paramètre de chaîne de requête CurrentTermId. Ensuite, il utilise les termes enfant et petit-enfant de la durée actuelle :

Term currentTerm = taxonomySession.GetTerm(
  new Guid(this.Page.Request.QueryString["CurrentTermId"]));
termsToReturn = currentTerm.Terms;

La propriété Data démarre ensuite la création du document XML. Ce document contient un élément de document nommé <Terms>, qui contient une hiérarchie de <Term> éléments. TaxonomyDataSource crée un <Term> distinct élément à représenter chaque terme elle tire de la banque à terme. Voici un exemple de tel un document XML :

<Terms>
  <Term Name="Term1" URL="PageUrl?CurrentTermId=">
    <Term Name="Term11" URL="PageUrl?CurrentTermId=">
      <Term Name="Term111" URL="PageUrl?CurrentTermId="/>
    </Term>
  </Term>
  <Term Name="Term2" URL="PageUrl?CurrentTermId=">
    <Term Name="Term21" URL="PageUrl?CurrentTermId="/>
  </Term>
</Terms>

Notez que le <Term> élément possède deux attributs nommés nom et l'URL. L'attribut Name est définie sur le nom du terme et l'URL est défini à l'URL de la page est balisée avec ce terme. Cette URL inclut un paramètre de chaîne de requête nommé CurrentTermId qui contient le GUID du terme en cours.

La propriété Data parcourt les termes récupérées et appelle la méthode GetXmlFragment pour chaque terme énumérée. L'objectif principal de cette méthode consiste à construire la <Term> élément qui représente le terme énuméré et cette <Term> élément <Term> sous-éléments qui représentent les termes enfant et petit-enfant du terme énuméré :

foreach (Term term in termsToReturn)
{
  GetXmlFragment(publishingPageCollection, term, ref xml);
}

Notez que TaxonomyDataSource utilise l'API de publication de SharePoint pour accéder à la collection qui contient les pages de publication.

Ensuite, je vais étudier l'implémentation de GetXmlFragment. Toutefois, vous devez tout d'abord comprendre l'importance de la colonne de site de balises, qui est de type métadonnées managé. Vous devez créer cette colonne de site et de lier à l'ensemble du terme qui contient la taxonomie portail et d'ajouter la colonne de site pour le type de contenu associé de la mise en page de publication. La colonne de balises permet à l'auteur du contenu baliser les pages de publication avec les termes de la taxonomie de portail.

GetXmlFragment se compose de trois parties. En tant que Figure 4 indique, les recherches d'articles premier à travers les pages dans la bibliothèque de documents Pages pour la première page qui est marqué avec le terme spécifié et génère le rendu d'un <Term> élément à représenter le terme.

Figure 4 la première partie de GetXmlFragment

foreach (PublishingPage publishingPage in publishingPageCollection)
{
  TaxonomyFieldValueCollection values =
    publishingPage.ListItem["Tags"] as TaxonomyFieldValueCollection;
               
  foreach (TaxonomyFieldValue value in values)
  {
    if (value != null && value.TermGuid == term.Id.ToString())
    {
      url = publishingPage.Uri.AbsoluteUri;
      xml += "<Term Name='" + term.Name + "' URL='" + url +
        "?CurrentTermId=" + term.Id.ToString() + "'>";
      closeTerm = true;
      defaultPublishingPage = publishingPage;
      break;
    }
  }
 
  if (closeTerm)
    break;
}

L'attribut URL de cette <Term> ensemble d'éléments à l'URL de cette page et le paramètre de chaîne de requête CurrentTermId a la valeur GUID de ce terme. Cette page sert de la page par défaut pour le terme spécifié. Cela simule fondamentalement la page par défaut d'un site si vous deviez créer un site pour représenter le terme spécifié.

Le code dans Figure 4 génère en fait le fragment XML suivant :

<Term Name='TermName' URL='DefaultPageURL?CurrentTermId=GUID>

Notez que le <Term> élément n'est pas encore clôturé, car je dois toujours effectuer une itération dans les termes enfant et petit-enfant de ce terme et restituer <Term> sous-éléments dans cette <Term> chaque élément énuméré terme enfant et petit-enfant. C'est exactement ce que fait la deuxième partie de GetXmlFragment :

foreach (Term cterm in term.Terms)
{
  GetXmlFragment(publishingPageCollection, cterm, ref xml);
}

GetXmlFragment ferme enfin le parent <Term> élément. Ensuite, GetXmlFragment rend <Term> éléments pour le reste des pages dans les Pages du document library qui se trouvent sur le même terme. Ces <Term> éléments sont traités comme des frères de la <Term> élément qui représente la page par défaut. Cela permet de lancement rapide restituer les liens vers toutes les pages sont marquées avec le terme courant. Cela simule fondamentalement les pages par défaut d'un site si je devais pour représenter le terme avec un site, comme indiqué dans Figure 5.

Figure 5 la troisième partie de GetXmlFragment

if (!this.IsGlobal)
{
  foreach (PublishingPage publishingPage in publishingPageCollection)
  {
    if (publishingPage == defaultPublishingPage)
      continue;
 
    TaxonomyFieldValueCollection values =
      publishingPage.ListItem["Tags"] as TaxonomyFieldValueCollection;
                   
    foreach (TaxonomyFieldValue value in values)
    {
       if (value != null && value.TermGuid == term.Id.ToString())
       {
         url = publishingPage.Uri.AbsoluteUri;
         xml += "<Term Name='" + publishingPage.Title + "' URL='" +
           url + "?CurrentTermId=" + term.Id.ToString() + "'/>";
         break;
       }
     }
   }
 }

Figure 6 montre un exemple d'une page basée sur la page maître qui utilise TaxonomyDataSource.

Figure 6 un exemple de Page basée sur une Page maître qui utilise TaxonomyDataSource
Grâce à TaxonomyDataSource, les menus de navigation supérieure et gauche affichent différents niveaux de la taxonomie de portail géré centralement dans le magasin de terme.

Le contrôle ListSiteMapPath

Comme mentionné, la mise en œuvre de la taxonomie portail dans un magasin à terme à la place de la structure du site portail présente deux défis. Dans la section précédente, j'ai abordé le premier défi et a fourni une solution. Cette section décrit le deuxième défi et fournit une solution pour y remédier.

v4.master contient un contrôle nommé PopoutMenu qui génère le rendu d'un contrôle nommé ListSiteMapPath. ListSiteMapPath affiche l'arborescence de navigation qui s'affiche lorsque l'utilisateur clique sur PopoutMenu, qui est affichée sous forme d'icône dans la page.

ListSiteMapPath hérite de SiteMapPath, qui est un contrôle traditionnel pour le rendu de l'arborescence de navigation. En outre, default.master utilise SiteMapPath, alors que v4.master utilise ListSiteMapPath.

ListSiteMapPath expose une propriété nommée SiteMapProviders qui accepte une liste séparée par des virgules des noms de fournisseurs de plan de site. En tant que tel, ListSiteMapPath peut fonctionner avec plusieurs fournisseurs. ListSiteMapPath parcourt ces fournisseurs et effectue les étapes suivantes pour chaque fournisseur énumérée. Tout d'abord, elle appelle la méthode FindSiteMapNode du fournisseur, en passant HttpContext pour renvoyer le nœud de plan de site actuel. Il puis appelle de manière récursive la méthode GetParentNode du fournisseur pour accéder à tous les nœuds de plan de site ancêtre du nœud de plan de site actuel vers le nœud de plan de site racine. Enfin, il restitue un élément dans l'arborescence de navigation pour chaque nœud de plan de site ancêtre à partir du nœud de plan de site racine jusqu'au nœud de plan de site actuel.

Comme vous pouvez le voir, ListSiteMapPath génère le rendu d'une hiérarchie complète des éléments pour chaque fournisseur de plan de site énumérée. De cette manière, chaque fournisseur de plan de site contribue à l'arborescence de navigation. Cela permet de ListSiteMapPath restituer des nœuds de plan de site à partir de différents types de sources. Dans mon cas, je veux ont ListSiteMapPath rendu des nœuds de plan de site à partir de la taxonomie portail mis à jour dans la banque à terme. Je vais implémenter un fournisseur de plan de site personnalisé nommé TaxonomySiteMapProvider pour y parvenir.

TaxonomySiteMapProvider remplace FindSiteMapNode, où il utilise le contexte spécifié pour accéder ensuite au SPListItem respectif. Il s'agit essentiellement le contexte en cours. Ensuite, la méthode accède à l'URL, le code et le titre de cet élément de liste et crée un nœud de plan de site pour le représenter. Gardez à l'esprit que cet élément de liste dans la publication de sites représente une page de publication.

ListSiteMapPath appelle cette méthode pour accéder au nœud de plan de site actuel :

SPContext spContext = SPContext.GetContext(context);
SPListItem listItem = spContext.ListItem;
string url = listItem.Url;
string key = listItem.ID.ToString();
string title = listItem.Title;
return new SiteMapNode(this, key, url, title);

ListSiteMapPath appelle ensuite GetParentNode, en passant dans le nœud de plan de site en cours pour renvoyer le nœud de plan de site qui représente le parent du nœud actuel. Gardez à l'esprit que le nœud de plan de site en cours représente la page de publication en cours et le nœud de plan de site parent représente le parent de cette page de publication. Dans ce cas, le parent d'une page de publication est la page de publication est balisée par le terme parent du terme avec lequel la page de publication en cours est balisée.

La substitution de TaxonomyDataSource de GetParentNode tout d'abord accède à la liste SharePoint en cours, qui n'est rien d'autre que la bibliothèque de documents Pages contient les pages de publication. Il crée ensuite une requête de langage CAML (Collaborative Application Markup Language) pour rechercher cette liste pour la page de publication en cours et il peut accéder à l'entrée du glossaire avec lequel la page en cours est balisée. Cette fois-ci, je n'utilise l'API de publication pour accéder à cette page de publication. À l'aide d'une requête CAML offre de meilleures performances, surtout si les Pages de bibliothèque de documents contient des dizaines de milliers de pages.

La section de code suivante de GetParentNode Renvoie en fait la page de publication représentant le nœud spécifié, puis récupère la valeur du champ balises, qui est le terme balisée avec lequel la page :

SPQuery query = new SPQuery();
 
query.ViewFields = "<FieldRef Name='Tags'/>";
query.Query = "<Where><Eq><FieldRef Name='ID'/><Value Type='Integer'>" +
  node.Key + "</Value></Eq></Where>";
SPListItemCollection listItems = list.GetItems(query);
SPListItem listItem = listItems[0];
 
TaxonomyFieldValueCollection values =
  listItem["Tags"] as TaxonomyFieldValueCollection;
TaxonomyFieldValue value = values[0];
 
Guid termGuid = new Guid(value.TermGuid);
TaxonomySession taxonomySession = new TaxonomySession(context.Site);
Term term = taxonomySession.GetTerm(termGuid);

Ensuite, GetParentNode accède le terme parent du mandat actuel et recherche dans la bibliothèque de documents Pages pour la page de publication est balisée avec ce terme parent. Il enfin accède à l'URL et l'ID de cette page de publication et utilise ces deux éléments d'information, ainsi que le nom du terme parent, le formulaire le nœud de plan de site parent, comme indiqué dans Figure 7.

Figure 7 formant le nœud de plan de Site Parent

Term parentTerm = term.Parent;
if (parentTerm != null)
{
  int[] wssIds = TaxonomyField.GetWssIdsOfTerm(context.Site, parentTerm.TermStore.Id,
    parentTerm.TermSet.Id, parentTerm.Id, false, 500);
  query = new SPQuery(list.DefaultView);
  query.Query =
    "<Where><In><FieldRef LookupId='True' Name='Tags'/><Values>";
  foreach (int wssId in wssIds)
  {
    query.Query += ("<Value Type='Integer'>" + wssId.ToString() + "</Value>");
  }
  query.Query += "</Values></In></Where>";
    listItems = list.GetItems(query);
    listItem = listItems[0];
 
    string url = listItem.Url;
    string key = listItem.ID.ToString();
    string title = parentTerm.Name;
 
      return new SiteMapNode(this, key, url, title);
}

Le code dans Figure 7 utilise la méthode statique GetWssIdsOfTerm de la classe TaxonomyField. Cette méthode retourne l'ID Windows SharePoint Services (WSS) de la durée spécifiée dans la liste masqués taxonomie, qui est une liste SharePoint au niveau de la collection de sites où SharePoint met en cache des termes utilisés dans la collection de sites. Chaque fois que vous balisez un élément avec un nouveau terme, SharePoint ajoute automatiquement une entrée à cette liste masquée pour ce terme. Le même terme peut avoir plusieurs entrées dans cette liste masquée taxonomie si, par exemple, le terme est réutilisé.

GetWssIdsOfTerm renvoie les ID de tous les éléments de liste qui représentent le terme spécifié dans la liste masqués de classification. Vous devez utiliser ces ID dans les requêtes CAML filtrer en fonction des champs de métadonnées managé, qui est le champ balises dans ce cas.

Figure 8 indique le ListSiteMapPath est lié à la TaxonomySiteMapProvider. Notez que le contrôle restitue la hiérarchie entière à laquelle appartient la page en cours.

Figure 8 la ListSiteMapPath qui est lié à la TaxonomySiteMapProvider

Architecture des informations de création de portails de gestion des connaissances

Comme indiqué, une approche traditionnelle de la navigation guidée mène à travers un ensemble d'options de menu pour les aider à trouver le contenu, qu'ils recherchent. C'est assez différent des portails de réseau sociales, où les approches tels que les opérations suivantes sont utilisées pour vous aider à trouver du contenu aux utilisateurs :

• Moteur de recherche : les utilisateurs effectuent des recherches par rapport aux index de recherche pour rechercher le contenu.
• Filtrage des métadonnées : les utilisateurs utilisent des métadonnées de filtrage pour filtrer les résultats de recherche.
• Des liens Wiki : Pages sont reliées par le biais des liens wiki. Les utilisateurs utilisent ces liens pour naviguer entre les pages.
• WebParts correctif cumulatif : Les Pages contiennent de WebParts de Rollup reporter le contenu à partir de divers endroits. Utilisateurs utilisent les liens dans ces WebParts pour naviguer entre les pages.

Les portails de réseau sociales promouvoir l'approche de la libre circulation à la navigation par opposition à l'approche guidé linéaire utilisée dans des portails traditionnels. Par conséquent, les utilisateurs peuvent arriver à une page par divers moyens. Dans les sections suivantes, je vais étudier la conception et la mise en oeuvre d'un portail de gestion des connaissances qui tire parti du modèle de navigation réseau social. Jean Squires et DeMaris Lincoln présenté cette conception pendant une session à la 2009 de conférence Microsoft SharePoint. Je couvre certains aspects de cette conception et également présenter mes propres personnalisations et des améliorations lui. La section suivante traite de la page d'accueil de ce portail de gestion des connaissances.

La page d'accueil

L'objectif principal de la page d'accueil est de fournir les deux possibilités suivantes : zone et Rollup WebParts de recherche. La zone de recherche permet aux utilisateurs de rechercher du contenu. C'est le principal composant de la page d'accueil. Le WebParts Rollup reporter contenu depuis différents emplacements dans toute l'entreprise.

Ce contenu peut être tout ce qui est intéressant certains utilisateurs. Par exemple, il peut être bénéfique aux utilisateurs pour leur montrer le contenu affiché de la plupart et recherche dans la plupart de l'entreprise. 2010 SharePoint est fourni avec une partie Web Analytics Web out of box que vous pouvez configurer pour afficher ce type de contenu.

Normalement, un portail de gestion des connaissances stocke les documents dans un référentiel central. SharePoint est fourni avec un modèle de site d'out of box appelé centre de documents. Vous pouvez créer un site à partir de ce modèle de site pour stocker vos documents. Vous pouvez ensuite ajouter une composant WebPart requête de contenu à la page d'accueil pour regrouper les documents jour le plus récemment.

Lorsque l'utilisateur utilise la zone de recherche affichée dans la page d'accueil pour effectuer une requête de recherche, elle est dirigée vers la page de résultats. Cette page est la page de résultats de recherche d'emploi SharePoint standard fourni avec un panneau Optimisation. Ce panneau contient les catégories que l'utilisateur peut utiliser pour filtrer les résultats de recherche. L'une de ces catégories est types de résultats.

L'utilisateur sélectionne le type de résultat associé aux pages Web pour afficher uniquement les pages Web. Le panneau de raffinement présente également les termes du contrat avec laquelle ces pages Web sont balisés. Voici les termes de la taxonomie de portail. L'utilisateur utilise ces termes pour filtrer davantage ces pages pour parvenir à la page souhaitée. L'utilisateur clique ensuite sur le résultat de recherche pour accéder à la page, ce qui est essentiellement une page wiki d'entreprise.

Structure d'une Page Wiki d'entreprise

Toutes les pages de mon portail de gestion des connaissances sont créés à partir de la même version personnalisée de la mise en page d'enterprise wiki.

Pour personnaliser la mise en page, je commence par remplacement du contrôle de champ de catégories de Wiki avec le contrôle de champ de balises. Je vais également placer un contrôle de champ de balises à l'intérieur d'un EditModePanel afin qu'il affiche uniquement lorsque la page est en mode édition. La raison pour laquelle je ne veux pas le contrôle de champ de balises s'affiche dans l'affichage en mode est parce que je vais utiliser le menu de navigation de gauche pour afficher les termes du contrat avec lequel la page en cours est balisée au lieu du contrôle de champ de balises. Comme vous le verrez bientôt, à l'aide de AspMenu me permettra non seulement pour rendre les conditions actuelles, mais aussi subterms des conditions actuelles, sub-subterms et ainsi de suite.

Je dois également apporter des modifications dans l'implémentation de TaxonomyDataSource le contrôle n'utilise pas la chaîne de requête pour obtenir le terme courant. Au lieu de cela, il doit récupérer les conditions actuelles du champ balises de la page actuelle. C'est pourquoi je tire n'est plus l'utilisateur via le menu de navigation supérieure, c'est-à-dire comment cela fonctionne dans un modèle de navigation guidée utilisé dans des portails traditionnels. L'utilisateur peut accéder à la page en cours de n'importe où. Par exemple, un lien wiki peut être sur une page qui dirige l'utilisateur vers la page actuelle. Par conséquent, il n'existe aucun paramètre de chaîne de requête doit informer le terme courant. Cela signifie également que le terme courant ne peut plus être un seul terme, car la page en cours ont été marquée avec plusieurs termes.

La nouvelle version de TaxonomyDataSource tout d'abord accéder à tous les termes avec lequel la page en cours est balisée. Il parcourt ces termes et crée des fragments XML pour ces termes et leurs descendants, comme indiqué dans Figure 9.

La figure 9 la nouvelle Version de TaxonomyDataSource

TaxonomyFieldValueCollection values =
  SPContext.Current.ListItem["Tags"] as TaxonomyFieldValueCollection;
Term currentTerm = null;
foreach (TaxonomyFieldValue value in values)
{
  currentTerm = taxonomySession.GetTerm(new Guid(value.TermGuid));
  GetXmlFragment(publishingPageCollection, currentTerm, ref xml);
  termsToReturn = currentTerm.Terms;
 
  if (termsToReturn != null)
  {
    foreach (Term term in termsToReturn)
    {
      GetXmlFragment(publishingPageCollection, term, ref xml);
    }
  }
}

La figure 10 affiche une page en fonction de ma version personnalisée d'une mise en page d'enterprise wiki.

Figure 10 A Page basée sur une disposition de Wiki d'entreprise personnalisés

Notez que la barre de lancement rapide affiche les conditions actuelles, les subterms les termes en cours et les pages sont balisés avec les conditions actuelles et subterms des termes du contrat en cours. Notez également que la page n'affiche pas le contrôle de champ de balises dans le mode d'affichage.

La figure 11 affiche la page en mode d'édition où apparaît le champ balises, permettant à l'auteur du contenu de balise ou modifier la page.

Figure 11 une Page en Mode édition, autorisant le balisage ou modification

Grâce à TaxonomyDataSource, le menu de navigation de gauche présente des liens vers toutes les pages qui sont liées à la page en cours. Il expose des liens vers les pages qui sont balisés avec les mêmes conditions que la page en cours, mais aussi pour les pages qui se trouvent des termes descendants de ces termes. Vous pouvez améliorer TaxonomyDataSource pour donner la possibilité de spécifier si vous souhaitez afficher uniquement les termes enfant de termes avec lequel la page en cours est balisée, les termes de l'enfant et les termes de petit-enfant, ou les termes enfant, termes petit-enfant et les termes de Godos-petit-enfant à l'auteur du contenu et ainsi de suite. Vous pouvez également donner à l'auteur la possibilité d'afficher les termes parent des termes avec lequel la page en cours est balisée, les termes parent et le grand-parent et ainsi de suite.

Ainsi, TaxonomyDataSource devient un outil puissant qui garantit que lorsqu'un utilisateur visite une page, la page présente à l'utilisateur avec des liens vers toutes les pages connexes au sein de l'entreprise. En plus de pages sont ajoutés et balisés avec les mêmes termes avec lequel la page en cours est balisée ou avec les termes de descendants de mêmes termes, TaxonomyDataSource récupèrent automatiquement leur, afin que la barre de lancement rapide est automatiquement mis à jour pour inclure des liens vers ces nouvelles pages. TaxonomyDataSource rend possible d'utiliser la taxonomie de portail comme le thread courant que les chaînes ensemble toutes les pages et des documents au sein de votre entreprise.

Les liens dans la barre de lancement rapide sont tout simplement un moyen d'établir des connexions entre les pages de votre portail. Une autre méthode consiste à utiliser la liaison de page wiki style. Encore un autre moyen consiste à utiliser de WebParts de synthèse de contenu associé à partir de l'entreprise. Par exemple, vous pouvez configurer un composant WebPart requête de contenu aux documents extraits à partir de votre centre de documents et filtrer en fonction des termes avec lequel la page en cours est balisée. Lorsque les utilisateurs chargement de nouveaux documents pour le centre de documents et de les baliser avec les mêmes termes avec lequel la page en cours est balisée, ce composant WebPart requête de contenu met automatiquement à jour pour afficher ces nouveaux documents également.

Comme l'auteur du contenu ajoute une nouvelle balise à la page, modifie la balise existante ou supprime une balise existante, le contenu de tous les WebParts de synthèse sur la page et le contenu du lancement rapide change automatiquement. Il s'agit d'un exemple de réseau social contextuel, où la page affiche le contenu en fonction de la taxonomie.

TaxonomyDataSource, la liaison du style de wiki et Rollup WebParts transformer une page en un forefront pour l'extraction du contenu connexe de toute l'entreprise d'un seul emplacement, filtré selon les termes du contrat avec laquelle la page est balisée. Pages sont structurées n'est plus explicitement par l'intermédiaire de la structure physique du portail. Au lieu de cela, ils sont structurés implicitement via les relations qu'ils ont via la taxonomie, liaison wiki style et Rollup WebParts.

Architecture d'informations flexibles et personnalisés

Conclusion de l'aide de fonctionnalités de SharePoint 2010 ECM nouvelle génération et implémenter l'architecture d'informations flexible pour publication/intranet/extranet connecté à Internet et les portails de gestion des connaissances. Cette souplesse devient plus importante que la page Web et conception de site évoluent pour tenir compte de nouvelles façons d'utiliser Internet, telle qu'illustrée par la prolifération des sites de réseau social. Alors que j'ai présenté la conception et la mise en oeuvre de plusieurs composants personnalisés SharePoint qui peut être utilisé pour mettre en œuvre de l'architecture d'informations, bien d'autres qui peut être effectuée, et je vous invite à découvrir les nouvelles possibilités.

Shahram Khosravi est spécialisé dans le et a professionnelles approfondies expérience SharePoint architecture, design et de développement. Il est l'auteur des ouvrages suivants: « Expert WSS 3.0 et MOSS 2007 programmation » (Wrox, 2008), « Professional SharePoint 2007 Workflow Programming » (Wrox, 2008), « sécurité ASP.Référence du programmeur NET AJAX » (Wrox, 2007), « sécurité ASP.NET 2.0 contrôle de serveur et de développement de composants » (Wrox, 2006) et « IIS 7 et ASP.NET intégré programmation"(Wrox, 2007).