Discussion :

[Phoenix57]

Hello !
Une petite question qui me turlupine.
Quel est selon vous la meilleure façon d’implémenter une logique autours des formulaires d'affichage, d'ajout et de modification de SharePoint sur une version 2010 onpremise ?
Je pose cette question car je suis tombé sur ce billet :
http://ranaictiu-technicalblog.blogs...play-form.html
Il est expliqué comment associer une page aspx + code behind aux items d'une liste, en l'associant directement au type de contenu.
Cela permet de manipuler le modèle objet de SharePoint lors de l'ajout, édition et affichage d'items.
J'ai testé ça marche bien. En plus en changeant l'attribut codebehind en codefile de la directive page, on peut dev du code beside avec une compil à la volée.
Du coup plus besoin de faire des iisreset a tire larigot et s'endormir devant son écran.

Je trouve que c'est une alternative intéressante face aux devs plus classique avec EventReceiver.

Qu'en pensez-vous ?

[eldrad95]

Personnellement je modifie les pages de formulaire de cette manière (mais en gardant le code behind, j'aime pas la compile à la volée ^_^), ça à l'avantage de pouvoir faire tes vérification directement lors de la saisie .
En revanche je crois pas que tu sois obligé de mettre la dll en Gac (faut que je revérifie) du coup pas besoin de faire un iisreset, un simple recyclage fonctionne.


ps désolé pour la réponse plus que tardive .

[ludojojo]

Il faut distinguer deux choses, la saisie et l'enregistrement !
En effet, faire un formulaire custom est un très bon moyen d'appliquer une logique de saisie et de control avant la sauvegarde d'un élément.
Par contre ça ne protège pas... L'avantage du receiver, c'est que ça te permet de controler tout ce qui est fait un par un évènement tiers à ton Interface. Exemple Powershell, Timer job, application cliente, etc...

Je serais donc tenté de dire qu'il faut les deux options pour couvrir les différentes actions possibles.