We besteden collectief een groot deel van tijd te denken over SharePoint oplossingen — hoe ze te maken, welke tool om te gebruiken, Wat gebeurt er wanneer ze niet implementeren, timeropdrachten, scopes, etc. Wij besteden zoveel tijd te denken over de up-front bits dat het is gemakkelijk om te vergeten dat we moeten ze ook intrekken. Intrekken van oplossingen is waarschijnlijk moeilijker, vanuit een ontwerp perspectief, dan het implementeren van hen. Implementatie is in feite een kookboek-affaire. Meestal, installeren van een functie, Misschien hebben een functie ontvanger laden van sommige gegevens in een lijst, dat soort dingen. Echter, intrekken is potentieel meer complexe.
Een bepaalde oplossing kan leiden tot artefacten als deze:
- Type inhoud
- Lijstdefinitie voor
- Sitedefinitie
- Gegevens in een lijst
- Zelfs ontvangers
- InfoPath-formulieren
De lijst gaat op.
Terwijl het is uiteraard van groot belang om een oplossing te ontwerpen instantieert die die artefacten correct, het is net zo belangrijk rekening houden met de update en gevallen verwijderen. Als uw oplossing wordt een nieuwe lijst gemaakt en wordt die lijst met gegevens gevuld, Wat gebeurt er als de oplossing wordt teruggetrokken? In sommige gevallen, de lijst moet worden verwijderd. In andere gevallen, het moet worden intact gelaten voor historische doeleinden. Uw zakelijke behoeften zal u begeleiden naar de juiste beslissing.
Om te helpen met dit, een matrix waarin elke artefact die uw oplossing op SharePoint implementeert maken. Lijst drie kolommen per artefact, een voor maken, bijwerken en verwijderen. Voor elk geval, de juiste uitkomst voor die bewerking bepalen.
Dit soort analyse is uiteraard het beste gedaan voordat de oplossing is ooit geïmplementeerd op een SharePoint-farm. Echter, Als roken, het is nooit te laat om te beginnen om dingen goed te doen. Dat matrix maken en ontwikkelen van een plan om aan te pakken van de ontbrekende update/verwijderen-scenario 's. Het kan zijn een moeilijk probleem op te lossen, maar in ieder geval zult u een vak rond het probleem hebben gezet.
</einde>
Volg mij op Twitter op http://www.twitter.com/pagalvin
@no naam
Dat is wat de functie ontvanger klasse voor. U schrijven aangepaste code voor het afhandelen van wat ooit u wilt binnen het objectmodel in override methoden binnen uw aangepaste functie ontvanger. Zie de MSDN-artikel Hier.
Hope that helps 🙂
@Paul
Ik ben het koppelen van dit artikel in deze maanden SharePoint gebruiker groep presentatie omdat, zoals werd besproken tijdens deze maanden SPUG, Dit is echt een centraal aandachtspunt voor het maken van robuuste SharePoint functies.
-John bender
nickelcode.com (Blog)