Here’s a great tutorial that shows you how to set up a branding project that can be activated as a feature.
Monthly Archives: January 2011
I found a project on codeplex that allows you to customize the branding of my sites. It’s great because it’s just a wsp that is activated wherever your my site is hosted. It’s a great start for anyone looking to change the look and feel of My Site.
A lot out there –> http://www.codeplex.com/site/search?query=sharepoint%202010&ac=3
Here’s a link to a blog with the “How-to” and a link to the site to create your js files to do the font replacement.
This is a huge topic that has many optional paths, but this link is a nice walk through the basic steps involved…
Update 5/20/2010: This turned out not to be a good “free hosting” plan. You can’t use SP Designer to go against the free site.
I’ve used the 30 day trial in the past, but I didn’t want to pay for a subscription since I was only using my site to create demos for my blog. SharePointHoster has removed the 30 day limit now which is great. Check it out…
I think the blog below does a great job breaking down the decision criteria to pick the right solution for your requirement. You can see the original blog here.
A SharePoint event handler or event receiver is a piece of code that runs when an event, such as the adding, deleting, or changing of a SharePoint list item or document, takes place.
They react to changes just like a SharePoint workflow can react to those same changes made to an item.
SharePoint event handlers vs. SharePoint workflows
The main differences between SharePoint event handlers and SharePoint workflows are:
SharePoint event handlers are automatically initiated, while SharePoint workflows can be initiated either automatically or manually.
A SharePoint event handler always responds to an event that has taken or is taking place on an item, while a SharePoint workflow does not necessarily have to react to an event that is taking place. While it can react to an item being created or changed, you can also manually start a workflow after an item has been created.
SharePoint event handlers have no user interface, so users cannot interact with event handlers. On the other hand, you can create either ASP.NET or InfoPath forms to provide user interactivity with SharePoint workflows. And you can add even more interactivity by using SharePoint Tasks lists along with the workflow.
SharePoint event handlers run for a short period of time (generally seconds), while SharePoint workflows may run for a much longer time period (days, months, or even years).
Since SharePoint workflows are hydrated and dehydrated, they can “survive” server reboots, while SharePoint event handlers cannot.
When to choose what?
When deciding whether to go with a SharePoint event handler or a SharePoint workflow for a piece of functionality or business logic that you require, consider the 5 points mentioned above.
Go with a SharePoint event handler if the tasks you want to perform are directly related to the user taking a particular action on an item (such as adding, editing, or deleting it), you do not require the user to interact with your code, and whatever the event handler has to do is of a short duration.
Go with a SharePoint workflow if the tasks you want to perform are not directly related to the user taking a particular action on an item, you require interaction between the user and your code, your code may run for a long duration, and should live through server reboots.