SharePoint: December 2009

Sunday, December 27, 2009

Sharepoint Articles links

How to optimize a sharepoint server 2007 with Web content management
1) http://msdn.microsoft.com/en-us/library/bb727371.aspx
2) http://msdn.microsoft.com/en-us/library/bb727372.aspx

10 steps to building XHTML compliant and performing MOSS publishing sites

http://blogs.code-counsel.net/Wouter/Lists/Posts/Post.aspx?ID=103

Best Coding practice while working with object model
http://msdn.microsoft.com/en-us/library/bb687949.aspx

Fire fox css issue
http://www.webmasterworld.com/forum83/7738.htm

Friday, December 18, 2009

Feature Stappling

Suppose when the site definition is already in use (and sites have been created) modifying a site definition once it has been deployed, since the site definition files on the filesystem are used for pages which are ghosted (not modified).
At this time we can go with feature stappling.
Some times it is also knows as site template association.
So finally feature-stapling Feature provides the mappings between the Feature and site definition.

Thursday, December 17, 2009

Deploying event receivers

There are 3 ways we can deploy the event receivers.
1) Deploying Programatically
2) Via Feature
3) With Content type

Programatically
This can be done only when an event receiver need to be associated with a single instance of a list rather than with all list of with template ID.

With Feature
Programmatic deploying will install the receiver againest a specific instance of a list and much reuse benefit is not possible in this.
To overcome this we can use this method.

Before creating any event handlers developers should think following points.

1. Security:

The assembly you deploy to the Global Assembly Cache(GAC) is running with full trust. Watch out for the following:

· Denial of Service attack: If a user uploads 10000 items to a list, what is the effect it will have to the systems your assembly uses.

· SQL Injection attack: If a user attempts to insert SQL statements into a column of a list that your assembly uses to update a database, what mechanisms are you using to make sure the input is valid.

· Cross Site scripting attack: What is the effect of adding script to a column that your assembly uses to update another area in SharePoint?

2. Performance:

Watch out for the following:

· Load: What burden are you placing on your web front end servers to run the assembly each time an event occurs? Use performance counters to determine this.

· Long Running Operations: Consider creating a custom SharePoint timer job. Kick off/ Schedule the Timer Job from the event rather than running all the logic inside the event. This will allow you to use the features of SharePoint to view whether the Timer Job ran successfully.

· Sync vs Async Events: Synchronous events have to wait until your code completes before returning the page, whereas Asynchronous events show the page immediately.

3. Error Handling:

When using synchronous events and you decide to cancel an event, let the user know why the event was cancelled. For example, update a Task List with a message why it failed.

Log your errors so that you can determine what issue is occurring when your system is in production environment.

4. Connections: Cater for external systems being down when you are trying to connect to them. Don’t let your code / solution go belly up because you cannot connect to a database.

5. Bulk Operations:

The MSDN documentation mentions that event handlers will not fire when bulk operation is occurring. For example, when a new list is created, the FieldAdding event will not fire.

Limitations of Event Handler in SharePoint

Strangely there is no “SiteAdding”, “SiteAdded” event. However, if you really need this event you could create a “feature” to accomplish this. Features in SharePoint have a “FeatureActivated” event, where you could perform an action on creation of a site.

Very Good site about sharepoint

http://www.sharepointkings.com/2009/07/accessing-content-type-via-object-model.html
http://www.sharepointkings.com

Wednesday, December 16, 2009

To check page is in edit mode or not for publishing page

This field can be used to check whether page is in edit mode or not

By checking value of this hidden field we will come to know about page is in edit mode or not.

Friday, December 11, 2009

Caml Query

Substracting 5 days from the current date in the caml query.

SPSite site = new SPSite("http://url");
SPWeb web = site.OpenWeb();
SPList list = web.Lists["ListName"];
string querystring = ""
+ "";
SPQuery query = new SPQuery();
query.Query = querystring;
DataTable table = list.GetItems(query).GetDataTable();

Running code with elevated previliges

Often it is useful to write code which has the ability to perform tasks that the user executing the code cannot do. For example, you may want to capture feedback from a user through a custom web part and add that feedback to a SharePoint list that the user does not have access to directly. Since server-side code executes in the context of the current user, the attempt to write the list item would fail.

The way around this is to use a method on SPSecurity called RunWithElevatedPrivileges. This method accepts an anonymous delegate which will contain all of the code you want to execute. Any code within this delegate will execute as the system account.

// this code runs in the context of the user
SPWeb web = SPContext.Current.Site.RootWeb;
SPList list = web.Lists["My List"];

// this code will run in the context of the system account
SPSecurity.RunWithElevatedPrivileges(delegate()
{
SPSite rootSite = new SPSite("http://myserver");
SPWeb rootWeb = rootSite.RootWeb;
SPList myList = rootWeb.Lists["My List"];
});

// now we're back to the user context
int itemCount = list.ItemCount;

One important thing to note is that only objects instantiated within the RunWithElevatedPrivileges code block will have the context of the system account. So objects created outside of that will still have the context of the current user - even if they are used within the RunWithElevatedPrivileges block.

// create an object in the context of the user
SPWeb web = SPContext.Current.Web;

// run as system account
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// this will execute as the current user, not the
// system account because it is accessing the web
// object which was instantiated outside of the
// RunWithElevatedPrivileges block
SPList myList = web.Lists["My List"];
});

Event Receivers
RunWithElevatedPrivileges is often used in Event Receivers to perform some sort of automation. Event receiver methods are passed SPItemEventProperties objects which provide easy access to the current list, current list item, current web, etc. However, you cannot use these objects directly within a RunWithElevatedPrivileges block because they were instantiated outside in the context of the user. As a workaround, you can re-create these objects within the context of the system account.

public override void ItemAdded(SPItemEventProperties properties)
{
// start sys account context
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// accessing the list item directly from the properties
// will execute as the end user - not the system account
properties.ListItem["Title"] = "Hello";

// instead, re-instantiate these objects using data from the
// properties, but not the actual objects themselves
SPSite site = new SPSite(properties.SiteId);
SPWeb web = site.OpenWeb(properties.RelativeWebUrl);
SPList list = web.Lists[properties.ListId];
SPListItem item = list.Items.GetItemById(properties.ListItemId);
item["Title"] = "Hello";

item.Update();
}
}