SharePoint 4 Developers

Oi pessoal, tudo bem? Gostaria de informar a todos que na Revista .net Magazine edição 80 meu artigo exclusivo sobre desenvolvimento de WebParts no SharePoint 2010 foi publicado. Seguem mais detalhes: Do que trata o artigo O artigo mostrará ao leitor uma introdução ao funcionamento de Web Parts e como desenvolver Visual Web Parts para deploy no SharePoint 2010, mostrando as novidades no desenvolvimento com o Visual Studio 2010 e como usufruir os recursos que a ferramenta oferece. Para que serve Uma maneira de customizar sites e portais no SharePoint é através da adição de Web Parts. O Visual Studio 2010 torna-se agora um poderoso aliado no desenvolvimento para o SharePoint 2010 e traz novos templates para desenvolvimento. Visual Web Parts estão entre esses novos templates que facilitam o trabalho do desenvolvedor.

Em que situação o tema é útil Com o lançamento do SharePoint 2010 muitos desenvolvedores .NET podem iniciar o desenvolvimento nessa plataforma com mais facilidade e sem apuros, ao contrário das versões anteriores que dificultavam o acesso de novos desenvolvedores. Esse artigo traz uma abordagem para desenvolvedores .NET que desejam se beneficiar das novas funcionalidades do Visual Studio 2010 para o desenvolvimento no SharePoint 2010. Acredito que vocês vão gostar! Já nas bancas! Link para a revista: http://www.devmedia.com.br/post-18775-Revista--net-Magazine-Edicao-80.html []’s Marcel Medina

Clique aqui para ler o mesmo conteúdo em Inglês.

Oi pessoal, tudo bem?

Tenho encontrado coisas interessantes no SharePoint Server 2010 após o projeto de migração do MOSS 2007 que trabalhei recentemente. Segue uma delas, você consegue identificar a diferença entre as Figuras 1 e 2 abaixo?

Figura 1 – Document Content Type

Figura 2 – Report Content Type

Parece óbvio não? Os botões de Salvar e Cancelar ficam evidentes, mas a principal diferença que afeta os usuários está na seleção do tipo de content type.

No exemplo das Figuras 1 e 2 foram utilizados os content types Document e Report respectivamente. Cada um deles faz referência a um tipo de Form Template.

OBS: Para efeito de comparação excluí as demais colunas que compõe o content type Report da Figura 2.

O que fazer se você precisar disponibilizar o campo Content Type Choice (Figura 1)? Vou mostrar algumas abordagens para mudar esse cenário.

Abordagem 1 - SharePoint Manager 2010

Essa ferramenta é sensacional, pois facilita muito o trabalho. Ajudando na rápida alteração dos objetos do SharePoint. Se você é SharePointer, precisa conhecer!

Utilizando a ferramenta fica muito simples de alterar o Form Template, conforme a Figura 3:

Figura 3 – Alteração do Form Template

O Form Template chamado RptLibraryForm é responsável por não apresentar o campo para seleção de content types (Figura 2). Conforme Figura 3, a solução seria a alteração dos atributos DisplayFormTemplateName, EditFormTemplateName e NewFormTemplateName para um outro form, ex: DocumentLibraryForm (Esse form é o mesmo exibido na Figura 1).

Os form templates são encontrados nos content types, e eles podem ser alterados em 2 locais: no root do site collection ou em document libraries. Esse tipo de alteração seria recomendada apenas para alteração direta em document libraries, pois não recomendo mudar um objeto base do root do site collection. Qualquer erro nesse nível afetará os seu site e sub-sites!

Nesse ponto é que entra uma solução mais sustentável, com o desenvolvimento de form templates.

Abordagem 2 – Script

O script pode ser criado com um Console Application no Visual Studio ou via PowerShell.

Independente da maneira que isso será executado, o resultado será o mesmo da utilização do SharePoint Manager 2010, porém será realizado através de script.

Segue código abaixo para atualização via Console Application:

OBS: O código acima é aplicado na alteração de um content type vinculado a um Document Library.

Esse é o Powershell script equivalente ao Console Application:

Figura 4 – Powershell script

Faça o download do script aqui.

Abordagem 3 - Desenvolvimento de Form Templates

Uma solução segura é o desenvolvimento de features no SharePoint, pois os pacotes podem ser facilmente adicionados e ativados. Da mesma forma quando não utilizados, desativados e removidos.

Recomendo sempre abordagens sustentáveis, pois vão funcionar sem problemas e não te trarão dores de cabeça no futuro.

Crie uma nova solução no Visual Studio 2010 e nomeie de CustomLibraryFormSolution, conforme a Figura 5:

Figura 5 – Nova Solução

Defina a solução como uma Farm Solution, valide-a e aguarde sua criação pelo Wizard, conforme Figura 6:

Figura 6 – Wizard

Após a criação do projeto é necessária a configuração de um User Control e Feature para deploy.

Criação do User Control Custom Library Form

Esse User Control representará o novo form template que criaremos. Para começar faça o mapeamento do diretório 14\TEMPLATE\CONTROLTEMPLATES no seu projeto, conforme Figura 7:

Figura 7 – Mapeamento de diretório do SharePoint

OBS: Esse mapeamento é importante para deploy do User Control no local correto.

Adicione um novo User Control nesse diretório e nomeie de CustomLibraryForm, conforme Figura 8:

Figura 8 – User Control para criação do Form Template

OBS: Se você abrir o diretório 14\TEMPLATE\CONTROLTEMPLATES verá que contém diversos User Controls. Os principais form templates utilizados estão concentrados no arquivo DefaultTemplates.ascx.

Apague os arquivos .cs e deixe apenas o ascx disponível. Abra o User Control, delete todo o conteúdo e adicione o código abaixo:

OBS: O código acima foi extraído do User Control RptLibTemplate.ascx. A linha 12 foi a única linha adicionada que permite a seleção do Content Type.

Criação da Feature Custom Report

Essa feature será responsável pelo deploy de um Content Type que se utiliza do novo Form Template criado. Adicione um novo item do tipo Content Type e o nomeie de CustomReport, conforme Figura 9:

Figura 9 – Novo Item do tipo Content Type

O Wizard será exibido conforme Figura 10, então selecione o content type base do qual o novo content type herdará as configurações.

Figura 10 – Wizard

O XML do Content Type será exibido automaticamente após sua criação, modifique-o conforme o código abaixo:

OBS: Assegure-se de que a linha 8 seja alterada para Inherits=”FALSE”, pois isso impede que o Form Template informado na seção XmlDocuments seja sobrescrito pela herança. O interessante é que mesmo definindo esse atributo como falso, as colunas serão herdadas automaticamente. :)

Uma feature precisa ser criada para deploy do content type. Adicione uma Feature no projeto e defina seus atributos conforme a Figura 11:

Figura 11 – Detalhes da Feature Custom Report

Antes de qualquer coisa, check a propriedade Reset Web Server do package para garantir que o User Control seja identificado imediatamente após o deploy, conforme Figura 12:

Figura 12 – Detalhes do package

OBS: Baixe a solução pronta aqui.

Form Template Customizado

Ao final da criação do form, o resultado esperado pode ser visto logo abaixo na Figura 13, que mostra a utilização do CustomLibraryForm:

Figura 13 – Custom Form Template

OBS: Como podemos ver, trata-se do próprio form RptLibraryForm com a adição do campo Content Type Choice.

As três abordagens utilizadas funcionam muito bem. Conforme já disse, utilize sempre boas práticas e crie soluções sustentáveis.

Ao contrário da utilização de features, com scripts a solução é rápida, porém nesse caso temporária. Digo isso pois no futuro alguma coisa pode “quebrar” em função do script executado (com ou sem documentação).

Espero que esse post venha a te ajudar.

Referências:
http://msdn.microsoft.com/en-us/library/aa544142.aspx
http://msdn.microsoft.com/en-us/library/ms468437.aspx
http://msdn.microsoft.com/en-us/library/aa544154.aspx

[]’s

Marcel Medina

Clique aqui para ler o mesmo conteúdo em Inglês.

Oi pessoal,

Essa semana realizei a migração de Lookup Lists e Lookup fields. Fiquei impressionado pela falta de documentação e exemplos de como trabalhar com Taxonomy field values.

Nessa nota rápida vou mostrar a vocês um exemplo de como se trabalhar com o novo modelo de objetos para a migração de field values (Lookup fields X Taxonomy fields).

Premissa

Considere a seguinte Lookup List e Term Store nesse exemplo, que contém os jogadores da seleção da Copa de 2010, conforme Figura 1:

Figura 1 – Lookup List vs Taxonomy Term Store

OBS: Como você pode perceber, a decisão em migrar Lookup fields para Taxonomy fields é uma batalha. Será que vale a pena? No meu caso como estou criando um Content Type Hub, todos os Site Columns não podem possuir dependencias, então uma solução é se livrar dos Lookup fields.

Lookup fields X Taxonomy fields

Imagine uma Lista que contenha ambos os campos (fields), o primeiro mapeia a Lookup List e o segundo o Term Store. Nesse cenário o Lookup field contém valores, porém o Taxonomy field não, pois foi recentemente criado e precisa ser populado.

Como uma solução para isso, o código abaixo mapeia os Lookup field values para Taxonomy field values, também conhecido como Managed Metadata field values.

OBS: O código acima está bem comentado, o que dispensa comentários.

Espero que essa nota rápida ajude.

Referência:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.taxonomy.taxonomyfield.aspx

[]’s,

Marcel Medina

Clique aqui para ler o mesmo conteúdo em Inglês.