What are the situations when we must use 'Custom Action' on SharePoint 2010 List, Ribbon etc.
many times same functionality can be achieved by other means also. Why 'Custom Action' is must in that situation?
2 Answers
It is common when customizing SharePoint 2010 to want to extend the user interface. Fortunately, this is easy to do by using the ribbon menu. You can add new functionality to the SharePoint 2010 ribbon as custom actions. Custom actions enable you to expand or extend the standard behavior of SharePoint 2010 core components such as using a custom action to email the details of a list item.
From the article Adding a Custom Action to a Display Form for List Items you get a general answer on the topic, but I'd like to add a case. Consider a scenario where you have an editor group of users who need to access all site content in 60 different markets on an external web site powered by SharePoint. It's very hard to keep track on where you are, at all times, and how you can (quickly) access other site contents. Then a custom action in the Site Actions menu would be a quick way to point to a an admin page containing all these 60 markets All Site Content links, with the proper label. No need for editors to start fiddle with url's.
There's a bunch of other cases where you can make life easier for SharePoint users by improving the way we navigate in SharePoint.
answered Jun 22, 2013 at 8:17
As with many things in SharePoint, it is often to your advantage to adhere to the packaging and deployment architecture that is there instead of "achieving it by other means." You can usually get away with doing things your own way in a small scale deployment, but you are much more likely to run into issues eventually in a large scale deployment with multiple front ends and an atypical topology or configuration.
On top of this, a CustomAction (as most items of this sort) has a lot of nice built-in features that you get for free that would take considerable time and effort to develop on your own. Simply because you don't need these features now doesn't mean you won't in the future. A few examples are Rights, ShowInLists, RootWebOnly, RequiredAdmin and RegistrationType.
I'd urge you to look at the site below and consider the code you'd have to write to implement some of the functionality on your own.
http://msdn.microsoft.com/en-us/library/ms460194.aspx
As a general rule, if the SharePoint framework provides a way to do what you want to do, then you should leverage the framework.
