Este artigo foi traduzido por máquina.

Desenvolvimento do SharePoint

Criando a arquitetura de informações no SharePoint 2010

Shahram Khosravi, Ph.d.

Baixar o código de exemplo

O lançamento do Microsoft SharePoint 2010 viu os novos recursos do Enterprise Content Management (ECM) adicionados ao software de colaboração. Este artigo mostra como aproveitar esses novos recursos para construir a arquitetura de informações flexível e extensível, passível de manutenção para os seguintes dois tipos de portais:

• Portais de publicação/intranet/extranet voltados para Internet
• Portais de gerenciamento do conhecimento

Vou lhe apresentar através do design e implementação de vários componentes do SharePoint personalizados que podem ser usados para implementar a arquitetura de informações para esses portais.

Arquitetura de informações do edifício voltados para a Internet/Intranet/Extranet-portais de publicação

Tradicionalmente, portais para publicação/intranet/extranet voltados para Internet seguem um modelo de navegação interativa estritamente onde os elementos de GUI como menus são usados para orientar os usuários ao conteúdo que estão procurando. Esses portais normalmente têm um superior e um menu de navegação à esquerda.

No menu de navegação superior geralmente é um AspMenu que permite aos usuários fazer seleções de primeira e segunda camadas do portal taxonomia. No menu de navegação à esquerda é geralmente um AspMenu que permite aos usuários fazer seleções de camadas terceira e quarta (ou possivelmente quinta) do portal taxonomia.

Todo o conteúdo do portal é dividido em um conjunto de categorias que formam a primeira camada. Usarei a seguinte convenção de nomenclatura para categorias: termoi onde iassume um valor inteiro. Por exemplo, as categorias de primeira e segunda são denominadas Term1 e Term2, respectivamente.

O conteúdo em cada categoria é dividido em um conjunto de subcategorias que formam o segundo nível. Usarei a seguinte convenção de nomenclatura para subcategorias: termoij onde i e j assumir valores inteiros. Por exemplo, a primeira Subcategoria da primeira categoria é denominada Term11.

Esta categorização do conteúdo continua até alcançarmos a granularidade desejada. Figura 1 mostra esta taxonomia de portal.

Figura 1 Portal taxonomia

Tal taxonomia portal normalmente é implementada no SharePoint 2007 por meio do estabelecimento da estrutura do site apropriado. Começarei criando um site separado para cada categoria. Eu, em seguida, irá criar subsites separadas em cada site de categoria para as respectivas subcategorias e assim por diante. Figura 2 mostra a estrutura do site do portal.

Figura 2 A estrutura do Site do Portal

Basicamente, cada categoria, subcategoria, por sub-subcategory e tem seu próprio site dedicado. Este site dedicado contém uma biblioteca de documentos de páginas que contém as páginas desse site. Se eu tivesse de usar linguagem rede social, eu podia dizer que todas as páginas na biblioteca de documentos páginas de um site implicitamente estão marcadas com a categoria, subcategoria ou sub-subcategory que representa o site. Uma forma, posso marca implicitamente um monte de páginas com uma categoria, subcategoria ou sub-subcategory criando-as em um site representando essa categoria, subcategoria ou sub-subcategory. Dessa forma, crio uma nova marca implícita (ou prazo), criando um novo site.

O AspMenu de navegação superior exibe essas categorias (primeiro nível) e suas subcategorias (segunda fileira). O usuário seleciona uma categoria ou subcategoria desse AspMenu para navegar até a página que está implicitamente marcada com esta categoria ou subcategoria.

Quando o usuário seleciona uma subcategoria no menu de navegação superior, a AspMenu (inicialização rápida) de navegação à esquerda exibe os sub-subcategories associados a essa subcategoria. O usuário seleciona um sub-subcategory desta AspMenu para navegar até a página que é implicitamente marcada com esse sub-subcategory. A biblioteca de documentos de páginas de um determinado site pode conter várias páginas, o que significa que várias páginas podem ser implicitamente marcadas com a mesma categoria, subcategoria ou sub-subcategory. Início rápido exibe links para todas as páginas que implicitamente estão marcadas com o mesmo sub-subcategory.

Comparação de a Figura 1 e a Figura 2 claramente mostra que a arquitetura de taxonomia ou informações do portal reflete diretamente o portal de estrutura do site. Isso torna a arquitetura de informações inflexível e apresenta os seguintes problemas:

• Criar uma nova marca implícita requer permissão de administração de site para criar um novo site.
• Remarcação de uma página requer fisicamente movendo a página de um site para outro.
• Reorganizar a arquitetura de informações requer fisicamente movendo e excluindo páginas e sites.
• Os autores de conteúdo não são capazes de compartilhar a mesma página entre várias categorias, subcategorias, sub-subcategories e assim por diante. Eles precisam criar uma página separada para cada categoria, subcategoria e assim por diante, pois cada um é um site separado. A opção somente out-of-the-box é copiar a página aos respectivos sites. Essa solução apresenta dois problemas de usabilidade. Primeiro, o autor do conteúdo deve copiar a página para muitos locais diferentes. Em segundo lugar, cada vez que o autor do conteúdo alterado o conteúdo de uma página, ele tem que voltar para todas essas cópias em todos esses sites para fazer as mesmas atualizações ou copiar a página novamente. Isso é propenso a erros.
• Como a alteração de taxonomia requer alterações estruturais na estrutura do site, que envolve muito tempo e esforço, taxonomia é muito rígida. Taxonomia está intimamente ligada com o modo como a informação é armazenada no conjunto de sites.

Inserir SharePoint 2010 ECM. Agora você pode implementar seu portal taxonomia em um aplicativo de serviço de metadados gerenciados onde você gerenciá-lo centralmente. Tal implementação não depende de sua estrutura de site de portal:

• Você não precisará provisionar novos sites apenas para criar novas marcas implícitas. Basta adicionar novos termos para os pontos desejados na taxonomia portal no armazenamento do termo. Dessa forma, você pode agora manter todas as suas páginas na mesma biblioteca de documentos páginas no mesmo site porque a escalabilidade das bibliotecas de documentos não é mais um problema em 2010 do SharePoint. Este artigo presume que todas as páginas são mantidas em uma única biblioteca de documentos de páginas em um único site.
• Remover marcas de você pode formatação uma página com um novo termo sem precisar mover fisicamente a página.
• Você pode reorganizar seu taxonomia simplesmente reorganizando sua taxonomia no armazenamento do termo sem precisar mover ou excluir páginas e sites fisicamente.
• Você pode compartilhar a mesma página em várias categorias, subcategorias e assim por diante marcando simplesmente a página com vários termos — onde cada termo representa uma categoria, subcategoria e assim por diante — sem precisar copiar fisicamente a página em sites.

Implementarei a taxonomia de portal como um termo único conjunto, conforme mostrado na a Figura 3.

Figura 3 implementação de taxonomia de Portal no aplicativo do serviço de metadados gerenciados

No entanto, a implementação de taxonomia portal em um armazenamento do termo em vez da estrutura do site de portal apresenta dois desafios discutidos nas próximas seções.

O controle de TaxonomyDataSource

Primeiro, a página mestra v4.master vem com um AspMenu que exibe o menu de navegação superior. Este controle está acoplado a um controle de fonte de dados de mapa do site que usa um provedor para recuperar os dados de mapa do site da estrutura do site de portal. Isso não vai funcionar nesse caso porque quero que os dados do mapa de site vir do armazenamento do termo, não a estrutura de site físico do portal.

Uma opção é implementar um provedor de mapa de site personalizado que recupera os termos apropriados de armazenamento do termo. Outra opção é implementar um controle de fonte de dados personalizados. Usarei o último porque o ASP.NET vem com um controle de fonte de dados poderosa denominado XmlDataSource que posso estender facilmente atingir o meu objetivo. Denominarei esse controle de fonte de dados personalizado TaxonomyDataSource.

TaxonomyDataSource expõe uma propriedade Boolean chamada IsGlobal. Eu incluirá duas instâncias de TaxonomyDataSource na página mestra. Uma instância será vinculada a AspMenu que processa o menu de navegação superior. A IsGlobal propriedade desta instância será definida para true para recuperar todos os termos do termo conjunto que contém a taxonomia de portal. Isso permite que o menu de navegação superior para exibir todas as categorias e suas subcategorias. Tenha em mente que categorias e subcategorias seus respectivas são nada, mas os termos do filho e neto deste termo definidas.

A segunda instância será vinculada a AspMenu que processa o menu de navegação à esquerda (inicialização rápida). A propriedade IsGlobal desta instância ser definirá como false para recuperar apenas os subterms do termo atual. Deixe-me elaboradas no que quero dizer com "prazo atual".

Lembre-se de que, quando o usuário seleciona uma subcategoria no menu de navegação superior, no menu de navegação esquerdo deve exibir a lista de sub-subcategories associada a essa subcategoria. O termo atual neste contexto é a subcategoria. A segunda instância basicamente retorna filho do termo atual e termos de neto, que são nada, mas o sub-subcategories e sub-sub-subcategories.

TaxonomyDataSource substitui a propriedade de dados para recuperar a taxonomia de portal do armazenamento do termo. É o principal objetivo da propriedade dados criar o documento XML que XmlDataSource usa para criar os nós que ele passa para AspMenu. Essa propriedade pela primeira vez usa os metadados do SharePoint 2010 gerenciados API para acessar o termo definido que contém a taxonomia de portal, como mostrado aqui:

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];

A propriedade utiliza todos os termos no prazo definido se IsGlobal for verdadeiro:

termsToReturn = termSet.Terms;

Se IsGlobal for false, a propriedade acessa pela primeira vez o GUID do termo atual, que é exposto através do parâmetro de seqüência de caracteres de consulta CurrentTermId. Em seguida, ele usa os termos do filho e neto do termo atual:

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

A propriedade de dados, em seguida, começa a criar o documento XML. Este documento tem um elemento de documento denominado <Terms>, que contém uma hierarquia de <Term> elementos. TaxonomyDataSource cria um separado <Term> elemento para representar cada termo que ela puxa do armazenamento do termo. A seguir é um exemplo de como um documento 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>

Observe que o <Term> o elemento tem dois atributos denominados nome e URL. O atributo Name é definido para o nome do termo e a URL está definida para a URL da página que está marcada com esse termo. Esse URL inclui um parâmetro de seqüência de caracteres de consulta chamado CurrentTermId que contém o GUID do termo atual.

A propriedade Data itera através os termos recuperados e invoca o método de GetXmlFragment a cada termo enumerado. O objetivo principal desse método é criar a pasta <Term> elemento que representa o termo enumerado e este <Term> elemento <Term> subelementos que representam os termos do filho e neto do termo enumerado:

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

Observe que o TaxonomyDataSource usa o API de publicação do SharePoint para acessar a coleção que contém as páginas de publicação.

Em seguida, discutirei a implementação de GetXmlFragment. No entanto, primeiro você precisa entender o significado da coluna site marcas, que é do tipo gerenciado metadados. Você precisará criar esta coluna do site e vinculá-lo para o termo definido que contém a taxonomia de portal e adicionar a coluna de site para o tipo de conteúdo associado de layout de página do publicação. A coluna de marcas permite que o autor do conteúdo marcar as páginas de publicação com os termos da taxonomia portal.

GetXmlFragment consiste em três partes. Como a Figura 4 mostra, a primeira parte procura por meio das páginas na biblioteca de documentos páginas na primeira página que está marcado com o termo especificado e processa um <Term> elemento para representar o termo.

Figura 4 A primeira parte do 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;
}

O atributo de URL deste <Term> elemento está definido para o URL desta página e o parâmetro de seqüência de consulta de CurrentTermId é definido no GUID do termo. Esta página atua como a página padrão para a condição especificada. Basicamente, isso simula a página padrão de um site se eu fosse criar um site para representar o termo especificado.

O código de a Figura 4 basicamente gera o seguinte fragmento XML:

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

Observe que o <Term> elemento não é fechado ainda porque ainda precisa percorrer os termos do filho e neto deste termo e renderizar <Term> subelementos dentro deste <Term> elemento para cada enumerados termo filho e neto. Isso é exatamente o que faz a segunda parte da GetXmlFragment:

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

Finalmente, GetXmlFragment fecha o pai <Term> elemento. Em seguida, GetXmlFragment processa <Term> elementos para o restante das páginas nas páginas do documento biblioteca que são marcados com o mesmo termo. Essas <Term> elementos são tratados como os irmãos de <Term> elemento que representa a página padrão. Isso permite o início rápido processar os links para todas as páginas que são marcados com o termo atual. Isso simula as páginas não-padrão de um site basicamente se eu fosse representar o termo com um site, como mostrado na a Figura 5.

Figura 5 A terceira parte da 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;
       }
     }
   }
 }

Figura 6 mostra um exemplo de uma página com base na página mestra que usa TaxonomyDataSource.

Figura 6 exemplo de um página com base em uma página mestra que usa TaxonomyDataSource
Graças às TaxonomyDataSource, os menus de navegação superior e esquerda exibem diferentes níveis da taxonomia portal, que é mantido centralmente no repositório do termo.

O controle de ListSiteMapPath

Conforme mencionado, Implementando a taxonomia de portal em um armazenamento do termo em vez da estrutura do site de portal apresenta dois desafios. Na seção anterior, eu discutido o primeiro desafio e forneceu uma solução. Esta seção discute o segundo desafio e fornece uma solução para solucioná-lo.

V4.master contém um controle denominado PopoutMenu que processa um controle denominado ListSiteMapPath. ListSiteMapPath processa a trilha que será exibido quando o usuário clica em PopoutMenu, que é mostrado como um ícone na página.

ListSiteMapPath herda de SiteMapPath, que é um controle tradicional para renderizar a trilha. Além disso, o default. master usa SiteMapPath, enquanto o v4.master usa ListSiteMapPath.

ListSiteMapPath expõe uma propriedade chamada SiteMapProviders que leva a uma lista separada por vírgulas de nomes de provedor de mapa do site. Como tal, ListSiteMapPath pode trabalhar com mais de um provedor. ListSiteMapPath itera através desses provedores e realiza as seguintes etapas para cada provedor enumerado. Primeiro, ele invoca o método FindSiteMapNode do provedor, passando HttpContext para retornar o nó de mapa do site atual. Ele então recursivamente chama o método GetParentNode do provedor para acessar todos os nós do mapa de site ancestral do nó atual site map para cima até o nó raiz do mapa de site. Finalmente, ele processa um item do breadcrumb para cada nó do mapa de site ancestral a partir do nó do mapa de site raiz para baixo até o nó de mapa do site atual.

Como você pode ver, o ListSiteMapPath processa uma hierarquia completa dos itens para cada provedor de mapa do site enumerados. Dessa forma, cada site map provider contribui para a trilha. Isso permite que ListSiteMapPath processar nós do mapa do site de diferentes tipos de fontes. No meu caso, eu quero ter ListSiteMapPath processar nós do mapa do site de portal taxonomia mantidos no armazenamento do termo. Implementarei um provedor de mapa de site personalizada denominado TaxonomySiteMapProvider para conseguir isso.

TaxonomySiteMapProvider substitui o FindSiteMapNode, onde ele usa o contexto especificado para acessar a SPListItem respectiva. Nesse contexto é basicamente o contexto atual. O método então acessa o URL, a identificação e o título deste item de lista e cria um nó do mapa de site para representá-lo. Tenha em mente que esse item de lista na publicação de sites representa uma página de publicação.

ListSiteMapPath invoca esse método para acessar o nó de mapa do site atual:

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, em seguida, chama GetParentNode, passando o nó de mapa do site atual para retornar o nó do mapa de site que representa o pai do nó atual. Tenha em mente que o nó atual do mapa de site representa a página de publicação atual e o nó do mapa de site pai representa o pai desta página de publicação. Nesse caso, o pai de uma página de publicação é a página de publicação que está marcada com o termo do pai do termo com o qual a página de publicação atual está marcada.

A substituição de TaxonomyDataSource do GetParentNode acessa pela primeira vez lista do SharePoint atual, que não é nada, mas a biblioteca de documentos de páginas que contém as páginas de publicação. Em seguida, ele cria uma consulta CAML Collaborative Application Markup Language () para pesquisar esta lista para a página de publicação atual, para que ele possa acessar o termo com o qual a página atual está marcada. Nesse momento, em torno, não estou usando a API de publicação para acessar essa página de publicação. Usando uma consulta CAML fornece melhor desempenho, especialmente se as páginas de biblioteca de documentos contém dezenas de milhares de páginas.

A seguinte seção de código do GetParentNode basicamente retorna a página de publicação que representa o nó especificado, e recupera o valor do campo Tags, que é o termo com o qual a página seja marcada:

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);

Em seguida, GetParentNode pesquisas na biblioteca de documentos de páginas para a página de publicação que está marcada com esse termo pai e acessa o termo do pai do termo atual. Ele finalmente acessa o URL e a identificação da página desta publicação e usa essas duas informações, mais o nome do termo pai, ao formulário o nó de mapa do site pai, conforme mostrado na a Figura 7.

Figura 7 formando nó do mapa do Site pai

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);
}

O código de a Figura 7 usa o método estático GetWssIdsOfTerm da classe TaxonomyField. Esse método retorna as IDs de Windows SharePoint Services (WSS) do termo especificado na lista oculto taxonomia, que é uma lista do SharePoint no nível do conjunto de sites onde o SharePoint armazena em cache termos usados no conjunto de sites. Toda vez que você marca um item com um novo termo, o SharePoint automaticamente adiciona uma entrada para essa lista oculta para esse termo. O mesmo termo pode ter várias entradas nesta lista de taxonomia oculto se, por exemplo, o termo é reutilizado.

GetWssIdsOfTerm retorna as IDs de todos os itens de lista que representam o termo especificado na lista de taxonomia ocultos. Você precisa usar essas identificações nas consultas CAML que filtrar com base nos campos de metadados gerenciados, que é o campo Tags nesse caso.

Figura 8 mostra o que é vinculado a TaxonomySiteMapProvider ListSiteMapPath. Observe que o controle processa toda a hierarquia à qual pertence a página atual.

Figura 8 O ListSiteMapPath que é vinculado a TaxonomySiteMapProvider

Arquitetura de informações de construção para portais de gerenciamento do conhecimento

Conforme discutido, uma abordagem tradicional de navegação interativa leva o usuário através de um conjunto de opções do menu para ajudá-los a encontrar o conteúdo que estão procurando. Isso é bem diferente de portais de rede sociais, onde as abordagens, como a seguir são usadas para ajudar os usuários a localizar conteúdo:

• Mecanismo de pesquisa: os usuários realizam consultas pesquisar índices de pesquisa para localizar conteúdo.
• Filtragem de metadados: os usuários usam metadados de filtragem para filtrar os resultados da pesquisa.
• Links de wiki-style: páginas vinculadas por meio de links no estilo wiki. Os usuários usam estes links para navegar entre páginas.
• Pacote cumulativo de atualizações Web Parts: Páginas contêm Web Parts pacote cumulativo de atualizações que acumular o conteúdo de vários lugares. Os usuários usam os links desses Web Parts para navegar entre páginas.

Portais de rede sociais promover a abordagem de fluxo contínuo para navegação em oposição a abordagem interativa linear usada em portais tradicionais. Assim, os usuários podem chegar a uma página por meios diferentes. Nas seções a seguir, discutirei o design e implementação de um portal de gerenciamento do conhecimento que aproveita o modelo de navegação de rede social. Sean Squires e DeMaris Lincoln apresentados neste projeto durante uma sessão na 2009 de conferência do Microsoft SharePoint. Vou abordar alguns aspectos desse design e também apresentar minha própria personalizações e aprimoramentos para ele. A próxima seção aborda a home page deste portal de gerenciamento do conhecimento.

A home page

O objetivo principal da home page é fornecer os seguintes recursos de dois: Rollup Web Parts e caixa de pesquisa. A caixa de pesquisa permite que os usuários pesquisem o conteúdo. Este é o componente principal da home page. O pacote cumulativo de atualizações Web Parts agregar conteúdo em vários locais em toda a empresa.

Esse conteúdo pode ser qualquer coisa que seja de interesse para os usuários. Por exemplo, pode ser benéfico aos usuários mostrar-lhes o conteúdo mais visualizados e pesquisados a maioria da empresa. 2010 Do SharePoint vem com um out-of-the-box Web Analytics Web Part que você pode configurar para exibir o conteúdo.

Um portal de gerenciamento do conhecimento normalmente armazena documentos em um repositório central. SharePoint vem com um modelo de site de out-of-the-box denominado Central de documentos. Você pode criar um site com base neste modelo de site para armazenar seus documentos. Em seguida, você pode adicionar uma Web Part de consulta de conteúdo para a home page para acumular os documentos carregados mais recentemente.

Quando o usuário utiliza a caixa de pesquisa mostrada na home page para executar uma consulta de pesquisa, ela é levada para a página de resultados de pesquisa. Esta página é a página de resultados de pesquisa out-of-the-box SharePoint padrão que vem com um painel de refinamento. Este painel contém categorias que o usuário pode usar para filtrar os resultados da pesquisa. Uma dessas categorias é tipos de resultado.

O usuário seleciona o tipo de resultado associado a páginas da Web para exibir páginas da Web somente. O painel de refinamento também apresenta os termos com os quais essas páginas da Web estão marcadas. Estes são os termos da taxonomia portal. O usuário usa esses termos para filtrar essas páginas para chegar a página desejada. Em seguida, o usuário clica no resultado da pesquisa para navegar até a página, que é basicamente uma página de wiki corporativo.

Estrutura de uma página de Wiki corporativo

Todas as páginas do meu portal de gerenciamento do conhecimento são criadas da mesma versão personalizada do layout enterprise wiki.

Para personalizar o layout de página, começo, substituindo o controle de campo categorias Wiki com o controle de campo de marcas. Eu também colocará um controle de campo Tags dentro de um EditModePanel para que ele só aparece quando a página estiver no modo de edição. O motivo não quero o controle de campo de marcas seja mostrada na exibição do modo é porque o menu de navegação à esquerda se usará para processar os termos com os quais a página atual está marcada em vez do controle de campo de marcas. Como você verá em breve, usar o AspMenu permitirá que eu não processar somente os termos atuais, mas também subterms os termos atual, sub-subterms e assim por diante.

Também preciso fazer alterações na implementação de TaxonomyDataSource para que o controle não usa a seqüência de caracteres de consulta para obter o termo atual. Em vez disso, ele deve recuperar os termos do campo Tags da página atual. Isso ocorre porque não quero levá-o usuário através do menu de navegação superior, que é como isso é feito em um modelo de navegação interativa usado em portais tradicionais. O usuário pode acessar a página atual de qualquer lugar. Por exemplo, pode haver um link de wiki em alguma página que leva o usuário para a página atual. Como tal, não há nenhum parâmetro de seqüência de caracteres de consulta que o informa sobre o termo atual. Isso também significa que o termo atual pode não estar mais um termo único, porque a página atual talvez foram marcada com vários termos.

A nova versão do TaxonomyDataSource acessa pela primeira vez todos os termos com os quais a página atual está marcada. Em seguida, itera esses termos e cria fragmentos XML para estes termos e seus termos descendentes, conforme mostrado na a Figura 9.

Figura 9 A nova versão do 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);
    }
  }
}

Figura 10 mostra uma página com base na minha versão personalizada de um layout de página de wiki corporativo.

Página de pré-requisitos de figura com base em um Layout de Wiki corporativo personalizado

Observe que início rápido exibe os termos, os subterms dos termos e as páginas que estão marcadas com os termos e subterms dos termos atuais. Observe também que a página não exibe o controle de campo de marcas no modo de exibição.

Figura 11 mostra a página no modo de edição onde o campo de marcas é mostrado, permitindo que o autor de conteúdo à tag ou ' Alterar ' da página.

Figura 11 uma página no modo de edição, permitindo a marcação ou remarcação

Graças às TaxonomyDataSource, no menu de navegação à esquerda apresenta links para todas as páginas que estão relacionadas à página atual. Ela expõe links não apenas as páginas que estão marcadas com os mesmos termos como a página atual, mas também às páginas que são marcadas com os termos de descendentes destes termos. Você pode aprimorar o TaxonomyDataSource para fornecer ao autor de conteúdo a opção de especificar se deseja exibir somente os termos filha de termos com os quais a página atual é marcada, os termos do filho e os termos do neto, ou os termos filha, termos neto e os termos de Grão-neto e assim por diante. Você também pode fornecer ao autor a opção para exibir os termos do pai dos termos com os quais a página atual é marcada, os termos de pai e os termos de avô e assim por diante.

Assim, TaxonomyDataSource se torna uma ferramenta poderosa que garante que quando um usuário visita uma página, a página apresenta ao usuário com links para todas as páginas relacionadas em toda a empresa. Como mais páginas são adicionadas e marcadas com os mesmos termos com que a página atual está marcada ou com os termos dos mesmos termos de descendentes, TaxonomyDataSource escolherá automaticamente-los, portanto, inicialização rápida é automaticamente atualizado para incluir links para essas novas páginas. TaxonomyDataSource torna possível usar a taxonomia de portal como o segmento comum que encadeie juntos todas as páginas e documentos em toda a empresa.

Links no início rápido são apenas uma maneira de fazer conexões entre as páginas do seu portal. Outra maneira é usar a vinculação de página wiki-style. Ainda outro meio é usar o pacote cumulativo de atualizações Web Parts que atraem o conteúdo relacionado de toda a empresa. Por exemplo, você pode configurar uma Web Part de consulta de conteúdo para recepção de documentos a partir de seu centro de documentos e filtrá-los com base nos termos com os quais a página atual está marcada. Como usuários carreguem novos documentos para a Central de documentos e marque-os com os mesmos termos com os quais a página atual é marcada, esta Web Part de consulta de conteúdo é atualizado automaticamente para mostrar esses novos documentos, bem.

Como o autor de conteúdo adiciona uma nova marca para a página, edita a marca existente ou remove uma marca existente, o conteúdo de todos os Web Parts de pacote cumulativo de atualizações na página e o conteúdo de início rápido altera automaticamente. Este é um exemplo de contextual redes sociais, onde a página exibe o conteúdo com base na taxonomia.

TaxonomyDataSource, vinculando wiki estilo e pacote cumulativo de atualizações de Web Parts transformar uma página em um forefront para puxar o conteúdo relacionado de toda a empresa para um local, filtrado com base nos termos com os quais a página está marcada. Páginas não mais explicitamente são estruturadas por meio da estrutura física do portal. Em vez disso, eles implicitamente estão estruturados por meio de relacionamentos têm por meio de taxonomia, estilo wiki e vinculação de Web Parts pacote cumulativo de atualizações.

Arquitetura de informações flexível e personalizada

Resumindo, os novos recursos ajudam a SharePoint 2010 ECM você criar e implementa a arquitetura flexível de informações de publicação/intranet/extranet com a Internet e portais de gerenciamento do conhecimento. Essa flexibilidade está se tornando mais importante à medida que evoluem a página da Web e design de site para acomodar novas maneiras de usar a Internet, como exemplificado pelo detalhamento em sites de rede social. Enquanto eu apresentei o design e implementação de vários componentes do SharePoint personalizados que podem ser usados para implementar a arquitetura de informações, há muito mais que pode ser feito e solicito que você explore as novas possibilidades.

Shahram Khosravi especializada em e tem mercado amplo experiência com a arquitetura de SharePoint, design e desenvolvimento. Ele é autor dos livros a seguintes: "Expert WSS 3.0 e MOSS 2007 Programming" (Wrox, 2008), "Professional SharePoint 2007 Workflow Programming" (Wrox, 2008), "ASP.NET AJAX Programmer's Reference"(Wrox, 2007),"ASP.NET 2.0 controle de servidor e o desenvolvimento do componente"(Wrox, 2006) e"IIS 7 e o ASP.NET integrado programação"(Wrox, 2007).