Go to page: 1 2
Printer Friendly Version
The core reason for pursuing development in Microsoft SharePoint at all is the ability to maximize productivity. While it may be fun to work on the latest and greatest technology, most development is done for a business purpose. Because development is done for business, the most important reason to work with SharePoint is improving productivity. Productivity might be viewed from the perspective of the time saved by not having to develop features that users may want but which are difficult to implement.
Productivity might also be viewed from the perspective of flexibility to adapt to changing requirements in the future or reusability of the software that is developed between different parts of the solution. No matter which way you look at the problem there are some distinct advantages to developing with SharePoint. However, on the other side of the fence there are some barriers to productivity when developing with SharePoint, not the least of these is the learning curve that every architect and developer must overcome when building SharePoint-based solutions. In this article, we'll look at this learning curve and how to make it easier.
Learning Curve
SharePoint is a robust platform. Developing with it is a consideration for any organization that is developing solutions in ASP.NET. It's hard to miss the tight Microsoft Office client integration including version control, check in/check out, and workflows. It's equally hard to miss the idea of building applications in units of parts of pages and not complete pages.
However, the power of the platform comes at a cost. In order to gain the advantages of the platform there can be a fairly steep learning curve. Part of the learning curve is understanding ASP.NET at a deeper level, some of the learning curve is learning ancillary technologies that SharePoint uses, and some of the learning curve is unique to SharePoint. When you add the amount of learning together it can be overwhelming and frustrating to any developer, development lead, and development manager.
Most ASP.NET developers who've been doing ASP.NET development for a few years would say that they're pretty good ASP.NET developers -- and rightly so. However, SharePoint as a platform exploits a wide variety of ASP.NET's lesser known features.
SharePoint takes advantage of ASP.NET 2.0 master pages. The Master Pages feature allows the developer to develop one common template which contains the core navigation and framework for pages -- and then fill in the blanks with the pages themselves. Understanding how pages come together in SharePoint means that you'll need to understand the relationship between master pages and the pages themselves. For instance, master pages can contain content inside of a placeholder. When content is in a place holder in the master page that content is used whenever the page doesn't contain a reference to the placeholder. This minimizes the amount of code in each page while still allowing for special circumstances. The default master page in Windows SharePoint Services includes 31 placeholders that pages can fill in. A typical ASP.NET application developed inside an organization has less than ten. In many cases master pages have less than five placeholders.
The Web Part technology that SharePoint is built upon is a technology that was rolled into ASP.NET 2.0 -- but one relatively few developers have played with as of yet. Web Parts expose the concept of configuration based development. In a nutshell configuration based development is building components that behave differently based on the configuration information that is provided to them.
One of the features of web parts that most developers haven't had experience with is web part connections. The web part framework allows you to connect the output of one web part into the input of another web part. Building solutions that can be composed of multiple web parts chained together like paperclips isn't a normal approach for most developers. It will require a change in perspective to get the most out of the web part framework.
Ancillary technologies that may not be in a typical ASP.NET developers arsenal include XML and XSLT. Even if you've got a more than passing understanding of XML you may find that you've still got something to learn. Most of the XML in SharePoint uses a namespace. That means that using XPath to pick out nodes from the XML requires the use of the local-node() function or inclusion of a name table in each call. Similarly the XSLT used in some places in SharePoint numbers hundreds of lines long so even decoding what's happening in the style sheet transformation can be a challenge.
From a design perspective Cascading Style Sheets (CSS) are the preferred way to implement the colors and images which will make the page look the way that it should look. SharePoint both takes advantage of CSS -- and does not. The CSS sheets that SharePoint uses can be quite long as each element on the page is targeted with different colors, images, and classes. Determining what classes to override in order to get the look and feel you want isn't a trivial matter. On the other side, there are some items which cannot be overwritten. SharePoint sometimes emits hardcoded values in the HTML itself that CSS can't override. A solid understanding of CSS is essential to determine what can and cannot be done.
SharePoint adds to this mix its own set of new technologies. From the options you have for branding your sites, which includes site definitions, site templates, master pages, and themes, to delivering your solutions through a technology called Solutions Packages, SharePoint does have its own set of things to learn. Most of these items are well documented at this point. For instance, there are at least four publically available articles on how to create a SharePoint Solutions package.
Go to page: 1 2
Printer Friendly Version
Images
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
