The Mit's Blog

SharePoint Conference 2008 : Approche structurée de développement de site de publication

Voici la seconde session de Andrew Connell dans la continuité de publications WCM

C'est toujours un plaisir de participer à ces sessions beaucoup plus orienté méthode, best practices et tips and tricks. Et je vais le partager avec vous

La session repose sur une principe 50% slide/50% demo

Sous entendu, les slides vont passer rapidement pour gagner du temps sur les demos  avec pour objectifs :

• development process
• customisation versus dev
• tips and tricks

Avant tout rappelons quelques basiques de la technologie SharePoint. Dans SharePoint, la publication se base sur le principe que tout le filesystem web est virtualisé dans la base de contenu SharePoint. Ainsi il est plus simple de maitriser controller, générer des instances de ces propres templates, donc ses fichiers

Un fichier existe dans SP en tant que SPFile et sont stockés dans des SPFolders. Cependant, il faut bien faire la différence avec la notion de Ghosting

Pardon, ghosted étant un terme un peu trop SPS 2003. on parlera plus volontierement de

• uncustomized file = source sur le filesystem
• custolmised file = source dans la content DB

Et donc, n' oubliez pas que les fichiers customisés sont limités qu'aux pages aspx des sites SharePoint (le Layout ne compte pas !)

Le but ultime pour un développeur MOSS est de pouvoir reproduire et industrialiser son processus de création de site

>>>  Soit exploiter au mieux les outils et le framework de MOSS

Petit rappel de Andrew sur le poste de DEV SharePoint :"Please Use Virtual Machine and stop crying about your XP/Vista workstation"

>>> Entièrement d'accord et d'ailleurs le coding SP est un bon moyen de négocier des machines avec plus de 2GB de ram :pas le choix !

En ce qui concerne la customisation SharePoint,  attention à l'effet facilité de SP Designer. Le Wysiwyg ne vient pas gérer le publication de colonnes et de content type entre ferme. il faut savoir pondérer son utilisation à la partie maquette !

Le petit soucis de MOSS WCM est qu'il utilise absolument toutes les couches techniques de SharePoint : les challenges sont multiples face à un simple site collaboratif. il faut poser des règles, des méthodologies entre :

• tous les développeurs du projet
• tous les environnement (DEV/QA/UAT/IT)

En ce qui concerne le développement SharePoint, il faut passer du

• "Developers, Developers, Developers"

à

• "Features, Features, Features"

SharePoint via son moteur de génération CAML peut grâce aux Features créer tout plein de sites et de pages uncustomisés, il faut les utiliser

Cependant, le dev SP est loin d'être simple et pratique

• peu d'outils
  • pas de designer graphique
  • Plein, plein de flux CAML en XML
  • support minimal (mais vraiment minimal) du Debug
• le provisionning des fichiers demande une étape de packaging
• la désactivation de feature n'est pas un véritable RollBack, il faut des fois nettoyer

MAIS il y a quand même quelques points positifs

• Tout reste dans Visual Studio
• Le packaging gére le déploiement et la mise à jour en automatique
• Control complet sur la génération via le CAML
• garantit l'uncustomisation des pages de rendu sur le serveur

Exemple : une installation d'un livrable SharePoint peut se résumer à un simple fichier WSP à déployer en script et une feature à activer : "nothing more"

Demo : la grande classique création de layout depuis SPD avec des customs colonnes et un content Type.
>>> Mais comment la finaliser comme un VRAI projet SharePoint

Il faut simplement passer tout les fichiers utilisés dans MOSS dans un vrai projet VS.Net

>>> Je vous renvoit sur toutes les Demos de Features et de solution, du 12 comme celle des TechDays

Pour cela, Andrew s'est appuyé sur un ensemble d'outil communautaire pour lui faciliter la vie comme :

• Intellisense CAML via VS
• Extension CodeRush/Refactor pour SharePoint
• Extension WCM pour STSADM : récupération du Content Type et de ses colonnes en CAML
• WSPBuilder pour créer le package
• STSDev pour monter la solution Visual Studio rapidement
• Automatiser via MSBuild etle config VS
• Raccourci de publication de solution de Spencer Harbar
• un  café pour la soif

Que du classique, rien de nouveau (du moins pour les afficionados de ce blog, les autres ... désolé)

En résumé et en conclusion pour Andrew, il faut :

1. Créer sa configuration via SPD et le navigateur
2. Extraire les livrables via les API (ou les outils communautaires)
3. les FEATURISER
4. les déployer par des solutions

Je vais me permettre d'étendre sa conclusion un peu plus :
>>> Cette vision et manière de faire est valable pour tout développement SharePoint, WCM, ECM,WF compris

! Faites des Features !

Renaud Comte aka TheMit ( Featurator 12)

Member of WygTeam

http://www.wygwam.com