SharePoint Conference 2008 : Porting SPD Worflow to VS.Net
Day 2: il est 09H00, nouvelle session d'un vrai personnage du monde SharePoint
Todd Bleeker de MindSharp
Ce Guru de code SharePoint s'est lancé un défi intéressant : montrer le mariage semi impossible entre SharePoint Designer et Visual Studio
Comme il l'a annoncé au début, la session sera plutôt PRO Dev avec :
- XOML
- NO Gui
- XML / XSL
- CodeDom
- Activities
Le tout avec du pep's et de l'energie car Todd en live, c'est du vrai Show à l'américaine, toujours prêt à sauter, chanter ou courir dans la salle, le tout avec du Code
Soit un One Man SharePoint Code Show
C'est parti
SPD est surtout connu pour être simple, trés rapide et productif. il contient de nombreux outils de génération ainsi que des Wizards gérant tout l'aspect plomberie ennuyeux de SP
Le tout en direct sans impact IT ou de code
Problème, il est aussi limité ...
- Lié en DUR à une seule instance de liste
- des WF séquentiel seulement
- impossible de copy un WF d'une liste à une autre
- ...
VS.NEt est lui l'outil de coding par définition
Les templates de WF permettent de quasimment tout faire mais demande un maximum de compétence pour en exploiter toutes les options
- Associé un WF à toute liste d'un collection
- construire une infinité d'activities
- utiliser le systéme de Feature/solution
Le Mariage des 2 outils est intéressant dans le sens ou :
- Vos utilisateurs peuvent déja modéliser la base de leur WF
- tester, maquetter
- l' améliorer encore et encore jusqu'a finaliser le besoin
- c'est bien meilleur qu'une documentation non ?
- Vos développeurs peuvent coder directement
- à partir d'une base pré généré
- l'étendre et le rendre paramétrable
- génerer les activities réutilisable
Les Demos commencent à partir d'une Site Collection toute vierge : pas de snippets, pas de sandbox de secours
>>> une VPC vierge de Demo et tout en live via la maîtrise
Un petit WF sous SPD
Genre Création de taches pour d'un user, log dans l'historique et form d' initialisation
Une fois la génération lancé, on le test et on l'exporte sur le filesystem (clique droit sur le WF depuis l'arbre de SPD)
Nous avons en pratique :
- WF.xoml
- WF.xoml.rules (codedom)
- WF.xoml.wfconfig.xml (association values)
- WF.aspx (forms and initiations page)
Techniquement parlant, un WF peut :
- tout code (VS powa only)
- tout XAML
- pas de compilation
- pro génération
- méthode USER via SPD
- peut être un mixe des 2
L'ensemble des étapes qui vas suivre sur le blog de son collègue http://Mindsharpblog/paul
Et hop, fin de slides, avec remerciement et feedback.
Maintenant, il reste 30 minutes et Todd passe en VPC plein écran, VS et code jusqu'à la fin !!!
il y a des sessions marketing d'autre par la maniére, à vous de choisir :)
- Création d'un projet WF sous VS.NEt
- renommer tout : fichier et code behind (bien faire attention, le designer ne le fait qu'en partie)
- Ajout des activities + code associé
- le signer
- mettre un version en dur
- Compléter la feature et l'element via le snippet et le publickeytoken
- Modifier la ligne de commande du build event pour utiliser le DEPLOY
- Rajout du fichier XOML de SPD
- on le renomme du nom du WF VS
- édition via l'XML pas le designer :
- changer la classe et la référence de classe "ROOT"
- changer les "Name" des activités par un libellé plus humain
- idem pour les rules
- association de l'initiation form
- instantiationUrl + layout
- on reprend les fields et le params du wfconfig.xoml
- attention du root de ces champs (XSD différent avec SPD et VS)
- copie des forms.aspx dans un folder TEMPLATE/LAYOUT/PROJET
- correction du SPWorkflowDatasource via un nouveau GUID pour la base et la liste
- modification des paramètres de la page d'initialisation via le code behind pour ne plus les avoir en dur
- ajout d'une classe dérivant le formulaire
- ajout d'un protected pour accéder au SPWorkflowDatasource
- ajout du code d'association (toujours le même, peut être repris du SDK)
"And it's over"
Simple non ?
Superbe session mais qui confirme bien la précision et la méthodologie nécessaire à coder du WF. Certes, rien ne me parait bien compliqué mais tout est extrêmement précis et le moindre manque peut bloquer complètement le WF.
Un peu comme le vélo la première fois
(genre VTT de descente sur une pente de montagne !)
Mais le jeu en vaut la chandelle car une approche ou une partie du WF est pré écris et validé par un utilisateur fonctionnel pour être finalement rendu générique est vraiment un plus !
En tout cas, encore une superbe session de EnergicTodd !!!
Renaud Comte aka TheMit (SDK me voila)
Member of WygTeam
http://www.wygwam.com
Technorati tags:
SPC2008,
SharePoint,
SPD,
VS,
WF
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :