http://www.expertsharepointconsulting.com/Free-Standard-SharePoint-Master-Pages.aspx
As I mentioned previously, I’ve had the wonderful opportunity to gain more experience developing a MOSS application for a fantastic client with two other consultants (with the project lead being a SharePoint veteran in our company.) Sadly, my contribution to the project has come to a close as the other two consultants prepare to deploy the finished product; however, I’m grateful for two things:
- Aside from the usual bumps in the road, we were successful in providing our client with what they asked for within the time and budget we were given.
- My experience was enjoyable and successful to a point that I can be even more useful in future MOSS projects. This happens to be critical for our Atlanta office, because now it puts us in a better position to compete for upcoming MOSS projects without having to use resources from other offices to fill them, therefore increasing our utilization as a team.
More than likely, the next project for me will not be a MOSS application, but will instead be “just” an ASP.NET application – which I’m actually looking forward to. But before that time comes and while it’s fresh on my mind, I’d like to share a few more thoughts on what I think others should know about MOSS development:
- Lists, lists, lists. At the beginning of the project, our project lead kept referring to all of these “lists”. I had lists coming out of my ears! In our design, we even had plans for a “list of lists”. As a favor to me, we refrained from calling it a “list of lists” to stop my head from spinning; but it didn’t change the fact that everything in SharePoint is stored in a list – basically a configurable data table. The more you grasp that concept, the better you was able to understand how to create and automate them with our C# code.
- “Out of the box” or custom. If you’re building a custom MOSS application, you’ll need to find out early how much custom development you’ll need versus automating what’s already there for you. When the client starts asking for something to behave just slightly different than how it works “out of the box” (we must have said this phrase about 50 times in the past 6 weeks), you’ll discover the need to create custom webparts and/or a lot of research finding out how to change default behaviors. For example, it took us days just to figure out how to make our column names wrap in an edit form – that was frustrating!
- No “Page_Load” for you. Throw out the regular ASP.NET page events that you’re used to – no good. For example, if you want an action to be triggered by another action (I don’t know, like when the “page loads”!), you have to create a “feature” and code it to be “activated” when the site is created. To this day, we were puzzled to not find a place to put code that would run every time a page was rendered. In our case , this meant that we unable to refresh our left navigation in the event that a new site was created asynchronously; so we had to find several other places to strategically fire this code, leaving holes where the navigation the user sees may not be entirely accurate.
- Getting to know the GAC and “iisreset” better. When you’re building a MOSS application, you’re not building a new application from the ground up; instead, you adding pieces (webparts, features, and other class libraries) to the existing SharePoint application framework. This means that your development environment has to be on a server (we each used a Windows Server 2003 VPC with MOSS and Visual Studio installed on it). Then every time you want to test your stuff, you have to build your DLLs, copy them to the GAC, and reset IIS … every time! And then if you want to debug your code, don’t forget to attach to the “w3wp.exe” process in Visual Studio. It was nerve racking at first, but now I can do it in my sleep (I probably did!)
- SharePoint really is “hot”. Now that I’ve basically given an overview of the quirks and frustrating things about MOSS development, now it’s time to tell you this: SharePoint is really “hot” and for good reason. I'm always amazed at how much we can accomplish in a matter of weeks. The configurable pieces it already has are incredibly useful, and the possibilities of creating custom collaborative solutions to make a company more efficient are endless. Despite several setbacks getting used to MOSS development, I do know that we could not have built this solution we’re about to deploy as quickly, scalable, and lot of other things than if we built it from scratch using just ASP.NET. Sharepoint is well worth the learning curve!
I was reminded this week why it's important not to be lazy when it comes to design, specifically when it comes to our refactoring moments ... no matter how insignificant you think it might be at the time.
Early on in my first SharePoint project, I had the tasks of creating 3 lists for a site dynamically (2 document libraries, 1 picture library). When I asked if we'd need to create other types of lists on the fly, I was told "no, these will be the only three." So it was extremely tempting to just create 2 routines (1 for the document libraries, 1 for the picture library) and be done with it. Upon further review, I noticed that I could create one routine for both; question is, was it worth the refactoring effort for only 3 lists?
I choose to refactor, it just didn't seem right to me to have the same identical functionality in two places. You can only guess what happened later ... that's right, the scope of the project changed upon which we needed not only needed another 10 discussion boards - but they also needed to be dynamically generated based on another list already created. Happy that I refactored to one routine, I simply added one more line of code to the existing loop and was finished.
Having said that, a lack of refactoring in this case would not have hurt this project at all (it would have been easy to refactor at that point as well); but in a different scenario that was more complex and further along in the project, I know it would have been much more tempting not to go back and refactor that code. The only way to prevent that is good design, especially at the beginning of your project.
My goal to learn SilverLight has taken a backseat to a great opportunity I was given to learn SharePoint (MOSS 2007 really). There's a lot of parts to it, so it's easy to get lost. Fortunately for me, I am learning "on the job" with another consultant that has a ton of experience with MOSS development. My other saving grace is that custom development is ASP.NET-based, so it plays very well with the ASP.NET I already have. Plus, I've also have experience creating webparts, one of the basic building blocks of custom MOSS development - which MOSS actually make a little easier to use in my opinion.
So far, I've been very pleased with the work we've been able to accomplish in a short amount of time on the project we're working on, and I look forward to being able to share what I've learned down the road. In the meantime, I am still in "learning mode"; so I plan on attending SharePoint Saturday that will happen in Atlanta on April 18, 2009 so that I can get as much exposure as I can. Right now, they're looking for speakers; but since I already know a few developer friends that will be presenting, I think I'll just be an attendee this time and maybe consider presenting at another code camp or something.
Bottom line ... those of you that haven't made the jump to SharePoint and MOSS development out of "fear of the unknown", I am here to say that it's not as scary as you think and I encourage you to give it a try and/or attend a conference to see what it's all about.