Browse DevX
Sign up for e-mail newsletters from DevX


Push the Limits of SharePoint Customization

Now that the SharePoint API is fully .NET-based, you've gained access to almost the entire SharePoint object model. Learn how to use this new functionality while building a very simple console application using C# and the .NET Framework.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

harePoint has a very extensive API that connects to almost any part of the SharePoint functionality through your code. With SharePoint 2003 Microsoft has re-written most of the base API using .NET. Because it is now fully .NET-based, the SharePoint API gives you the full power of the .NET framework in manipulating the various aspects of a SharePoint portal. The API gives you access to manipulate almost the entire SharePoint object model.

There are two ways to manipulate SharePoint Portal objects. One is using the SharePoint Object Model API and other is connecting to the Web service interfaces exposed by SharePoint and using the functionality given. The former provides more power and control over almost all parts of SharePoint, while the latter is good to use if you want to use a non-.NET-based language or you want to manipulate the site parameters from an external machine.

Introducing Widgets, Inc.
One of the most common tasks in migrating the existing documents of any company to the SharePoint-based Intranet/Internet site, is to create proper area structures and add documents to them, so that the documents are logically ordered and sorted. This logical separation helps users find the required information quickly when they navigate through the proper area structure.

SharePoint Areas help organize and logically divide the information of any Website into various small sections. A section may be a document library, or pages with custom Web parts, displaying data based on the current area.

The sample case discussed in this article revolves round a hypothetical organization called Widgets Inc. who manufacture and sell widgets. Widgets Inc. keeps detailed records of all their many customers and their entire business revolves round proper and up to date customer information. They would like to organize all this customer data into a Sales Portal, for easy access by their sales team.

Presently, they store their customer information under various heads, like "Proposals," "Invoices," "Contact Details," "Business Research," and "Contracts." The main problem in migrating all this information to their Sales Portal is that someone has to create all these folder structures as areas.

Figure 1. Area Hierarchy: The image shows the area hierarchy for storing documents.

Based on the above scenario, there are three obvious solutions you can use in order to meet Widgets Inc.'s objective:

  1. Manual creation: You would need to sit and create the entire list of sub areas under the main Customers area—a very error-prone and time-consuming process. And what if you wanted to add another sub-area under each customer or rename a particular area?
  2. Use a commercial tool: This would automate the manual process, speeding it up and making it error-free. The main problem with a commercial tool is that it may not be flexible enough to render your area structure exactly the way you want it to look. Don't forget that there's also a cost involved in buying a tool, along with the accompanying learning curve.
  3. Build your own utility: This requires good technical knowledge and will take some time, but is a cost-effective way to end up with a solution fully-customized to your exact specifications.
With some quick coding and effective use of the SharePoint API, you can create your own Area Creator utility that you can use to automate this otherwise cumbersome and error-prone process.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date