Showing posts with label Event Receivers. Show all posts
Showing posts with label Event Receivers. Show all posts

Monday, October 24, 2016

WebProvisioned event receiver

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers >
    <Receiver>
      <Name>EventReceiver1WebProvisioned</Name>
      <Type>WebProvisioned</Type>
      <Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>
      <Class>Stefan.SharePoint.EventReceiver1.EventReceiver1</Class>
      <SequenceNumber>10000</SequenceNumber>
    </Receiver>
  </Receivers>
</Elements>

Scope:

<Receivers Scope="Site">

custom WebProvisioned receiver provides:
<Properties>
  <Property Key="ReceiverScope" Value="Site" />
  <Property Key="Web.MasterUrl" Value="~SiteCollection/_catalogs/masterpage/v4.master" />
  <Property Key="Web.AlternateCssUrl" Value="/_layouts/styles/mydefault.css" />
  <Property Key="CustomProperty.Test" Value="Some value" />
  <Property Key="PublishingWeb.IncludeInCurrentNavigation" Value="true" />
  <Property Key="Navigation.GlobalIncludePages" Value="true" />
  <Property Key="Navigation.GlobalIncludeSubSites" Value="true" />
</Properties>


Property Key="Web.MasterUrl" Value="${~Parent}" />
  <Property Key="Web.CustomMasterUrl" Value="${~ParentNoRoot}" />
  <Property Key="Navigation.GlobalIncludePages" Value="${~SiteCollection}" />
As you see, you can specify special tokens in the “Value” attribute of the feature property elements too, these three options are available:
  • ${~Parent} – with this token you specify that the property of the “Key” attribute will be copied from the parent web of the current web
  • ${~ParentNoRoot} – this is almost the same as the first option, the only difference being that if the parent site is the root site of the current site collection the property won’t be copied to the current web (meaning that if the current web is not a child of the root web, the property will get copied).
  • ${~SiteCollection} – this token specifies that the property will be copied from the root web of the current site collection (no matter whether it is the parent of the current web or not)
In the case of the ${~ParentNoRoot} token you saw that there will be cases when the specified web property won’t get copied to the current web (for first level children). In this case you will need to specify two feature property elements with the same “Key”:
  <Property Key="Web0.CustomMasterUrl" Value="~SiteCollection/_catalogs/masterpage/v4.master" />
  <Property Key="Web1.CustomMasterUrl" Value="${~ParentNoRoot}" />






SPWeb’s MasterUrl, CustomMasterUrl and AlternateCssUrl properties for publishing sites). This sample would do the trick:
  <Property Key="Web.MasterUrl" Value="~SiteCollection/_catalogs/masterpage/v4.master" />
  <Property Key="Web.CustomMasterUrl" Value="~SiteCollection/_catalogs/masterpage/v4.master" />
  <Property Key="Web.AlternateCssUrl" Value="" />
  <Property Key="CustomProperty.__InheritsMasterUrl" Value="false" />
  <Property Key="CustomProperty.__InheritsCustomMasterUrl" Value="false" />
  <Property Key="CustomProperty.__InheritsAlternateCssUrl" Value="false" />

Tuesday, April 26, 2016

Item Adding / Item Added Event Receiver for Document Library

In this below script, Item Adding / Item Added Event Receiver

Item Adding / Item Added Event Receiver In SharePoint
Ways to retrieve data are:

Properties.ListItem[«FieldName »]

Properties.AfterProperties[«FieldName »]

Properties.BeforeProperties[«FieldName »]


we must add the synchronization parameter


 to our xml definition.


<Receiver>
<Name>EventReceiver1ItemAdded</Name>
<Type>ItemAdded</Type>
<Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>
<Class>TutoTaxonomy.EventReceiver1.EventReceiver1</Class>
<SequenceNumber>10000</SequenceNumber>
<Synchronization>Synchronous</Synchronization>
</Receiver>
In our code we add an update of the column “test”


public override void ItemAdded(SPItemEventProperties properties)
{
base.ItemAdded(properties);
properties.ListItem["test"] = "test synchro";
properties.ListItem.Update();
}

Thursday, May 21, 2015

Difference between the Event Receivers , Workflows and Timer Job in SharePoint 2013?

Event Recievers Workflow Timer Job
Can execute either before or after the operation Always executes after the operation We ll Add
Can cancel the operation Cannot cancel the operation as the item will have already been created We ll Add
Cannot be launched manually by the user Can be started manually by the user We ll Add
Not designed for user interaction Specifically designed for user interaction We ll Add
Can execute in response to many different actions, including deletes Can only execute in response to one of four events – Manual, an item being created, an item being edited, and an item being submitted for approval We ll Add
Must be created in Visual Studio Can be created with Visual Studio, Visio or SharePoint Designe We ll Add
Syncronous Events and Asyncronous EventsWorkflows are always async
Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up But Workflow Jobs are robust and can resume even after Reboots.
Usually Event handlers runs for short period Workflows can be longer even for years!
Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up But Workflow Jobs are robust and can resume even after Reboots.
There is no User Interface/user Interaction in Event Receivers Workflows can have user interactions such as getting user input in Initiation forms.
SharePoint Event receivers are triggered by events like New Item Adding-Added, Updating-Updated, Deleting-Deleted, etc Workflows triggered only on Creation/Change/deletion.
Event handler doesn't do such. Workflows leaves "Workflow History" logs which we can refer for debugging
Event receivers are better for large volume Workflows are better for small amount of data.