SharePoint 4 Developers

Oi pessoal,

Decidi escrever algo a respeito sobre alguns dilemas, devido a um projeto que trabalhei recentemente. Fazer ou não fazer? Eis a questão.

Se você enfrentar situações para as quais não tem uma resposta imediata, vai precisar despender um tempo pensando nisso.

Rebranding branded sites

Quando um cliente vem até você dizendo que quer fazer o rebrand de um site SharePoint já existente, a primeira coisa que vem à minha mente ... isso é um upgrade?

Acontece que, pelo fato de sempre ter trabalhado no desenvolvimento de Custom branded sites, sempre pensei dessa maneira.

Geralmente se faz o Rebrand de um site depois de atualizar o ambiente, mas isso não é uma regra.

Atualizar, ou não atualizar?

Se você for fazer o Rebrand de um site no SharePoint que já possui um branding aplicado, e se o orçamento lhe permitir ir mais longe, faça o planejamento de um upgrade antes de aplicar o rebranding. Isto vai minimizar qualquer retrabalho e, consequentemente, custos no futuro.

Mas se o orçamento não incluir o upgrade, é sua tarefa dizer ao cliente que por não fazer o upgrade do ambiente, os custos podem ficar caros no futuro, especialmente se você precisar pular plataformas. Ex: do MOSS 2007 para SP2013. Estes custos envolvem:

• Infra-estrutura - A nova arquitetura, recursos, hardware.
• Soluções - Compatibilidade de customisações.

Porém cabe ao cliente decidir onde investir o capital. O cliente precisa ser guiado para o que for melhor para o seu negócio.

No meu caso o cliente decidiu não fazer o upgrade do ambiente, por isso meu trabalho se resumiu em fazer o rebrand do branded site no mesmo ambiente. Embora possa parecer simples, não é, é preciso considerar:

• Design / Look and Feel – Alterações de site definitions, master pages e page layouts.
• Content Types – Novos campos (fields) disponíveis em page layouts.
• Web parts – Mapeamento do existente x novo.
• Navigation – Mudanças na navegação Top e da Esquerda.
• Reusable content – Seções de Cabeçalho e Rodapé.

Ser ou não ser guiado por mock-ups?

Antes dos mock-ups serem criados, converse com os business users sobre conteúdo, pergunte como as páginas vão exibir as informações criadas por content editors.

Não seja guiado por mock-ups, em geral agências de design não têm a menor idéia sobre SharePoint, muito provável o design que for criado pode ter algumas incompatibilidades com o SharePoint.

Atualizar ou não atualizar site definitions?

Nunca modifique schemas de site definitions depois que site collections / sites já tiverem sido provisionados. Isto não é suportado! Aqui está a prova: http://support.microsoft.com/kb/898631

Utilize o object model para alterar site definitions. Se você estiver provisionando sub-sites, adicione código à feature receiver (ativação ou desativação) para modificar site definitions.

Obs: Você pode criar um novo site definition se você quiser um novo começo, mas você precisará adaptar o código existente e migrar site collection existentes que usam a versão antiga do site definition. Pessoalmente não recomendo essa abordagem.

Criar ou não criar uma nova master page?

Depende. Sim, se você precisar manter a versão antiga, mas se você fizer isso vai precisar modificar a feature receiver para atribuir a nova master page programaticamente durante o provisionamento de um site collection / site. Lembre-se que a antiga master page ainda está atrelada ao schema do site definition!

Mas se você não precisar manter a master page eu digo que não, atualize a master page existente. Esta é a abordagem que recomendo.

Criar ou não criar novos page layouts?

Provavelmente existirão mudanças de layout / field como resultado dos novos mock-ups fornecidos.

Sinta-se à vontade em modificar ou criar novos page layouts, o que você não pode fazer é excluir page layouts existentes. Eles podem estar referenciados pelo schema do site definition, portanto, neste caso, você precisa mantê-los disponíveis.

Não quero dizer disponível aos usuários, para que eles selecionem quando criarem páginas (você pode escondê-los), mas apenas como parte do código, como um legado.

Obs: Os content types podem estar acoplados a page layouts, então, assim que criar páginas, os campos (fields) de content types são exibidos nas páginas.

Preservar ou não preservar webparts?

Faça o que quiser com elas. Você pode excluir web part descriptors da galeria de Web Parts e ainda possuir referências em páginas, o que significa que você pode modificá-las ou excluí-las.

Tudo depende do look and feel / funcionalidades requeridas pelo Rebranding do web site. Se a webpart ainda fazer parte do propósito do novo Rebranding, mantenha-a, caso contrário remova-a.

Criar ou não criar navegações customisadas?

Cabe a você decidir o que vai na barra superior ou de inicialização rápida (quick launch). Claro que você não quer que os usuários vejam listas / bibliotecas (libraries) exibidas na navegação. Assim, você pode modificá-la para não exibir esses objetos por padrão.

Existem melhores práticas na criação de custom navigations. Você não quer iterar manualmente pelos sites e sub-sites para isso.

Use os objetos sob o namespace Microsoft.SharePoint.Publishing.Navigation, pois proporcionam um desempenho muito melhor ao manusear itens de navegação.

No MOSS 2007 e SP2010 a classe PortalSiteMapProvider deve ser usada para percorrer os nodes (que representam sites, páginas, links), enquanto que no SP2013 a classe TaxonomySiteMapProvider deve ser usada por se tratar do Metadata Service Application.

Usar ou não usar conteúdo reutilizável?

Claro que você pode usar um conteúdo reutilizável. Isto é totalmente recomendado em publishing sites!

Usando a lista de Reusable Content você pode criar HTML reutilizáveis ou textos reutilizáveis.

Na maioria dos sites as seções de cabeçalho e rodapé são compartilhadas e exibidas em todas as páginas, então por que não usar esse recurso?

Aderir ou não aderir a essa abordagem?

Não é raro se encontrar travado em dilemas quando customisar o SharePoint. Baseado na minha experiência, a minha recomendação é aderir às melhores práticas de SharePoint e recomendações do pessoal que realmente trabalha com a plataforma.

Dê preferência à artigos da Microsoft que mostrem como fazer. Se você não encontrar nada específico, converse com outros profissionais sobre o problema que você tem.

Espero que isso ajude. Caso você tenha um ponto de vista diferente, compartilhe.

[]’s,

Marcel

Referências:
http://support.microsoft.com/kb/898631
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.aspx
http://office.microsoft.com/en-nz/sharepoint-server-help/use-reusable-content-HA010163838.aspx

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