Last week, I presented this topic at the Houston SharePoint Users Group. I really enjoyed giving the presentation, only slightly disappointed that I wasn’t able to attend the technical track which was occurring simultaneously…. I’ll get over it though
The presentation itself contains a lot of useful information. Thanks to all who provided feedback, and my colleagues at Catapult who helped put it together.
I have uploaded the presentation here.
I am now offering this same course with Field Advantage Training, check them out at http://www.fieldadvantagetraining.com/ for the latest on upcoming sessions, pricing, and new courses. The name of the course has been changed to SPDC101 – Core SharePoint 2007 Development.
The last SharePoint Developer – Weekend Crash Course was a complete success. I’d like to extend a big thanks to all of you who participated in helping me put it together, and to all of the attendees for your positive feedback and references; you all rock!
Based on the number of inquiries I’ve had from readers and references who’ve shown interest in taking the course, I’ve decided to repeat the course here in Houston on September 12th and 13th of 2009.
This course is designed to cover the most common and critical SharePoint development topics I’ve come to expect from SharePoint implementations, based on several years of experience across multiple industry sectors. The course is meant for experienced .NET developers with entry to mid level SharePoint development experience.
The class will consists of a series of discussions and instructor led hands-on labs. The full agenda has been listed below. Attendees will need to bring their own laptops, for which I have posted minimum requirements (see hardware and software requirements below.)
Attendees will receive:
- An external USB 2.0 Hard Drive with 80 GB or more of storage
- A Virtual PC image running trial versions of Windows 2003, SharePoint 2007, and Visual Studio (included in the hard drive.)
Core Concepts (8:30 am – 9:45 am)
15 minute break
Extending the Out of the Box Experience (10:00 am – 12:00 pm)
1 hour lunch break
Custom Web Part Development (1:30 pm – 2:45 pm)
15 minute break
Custom Site Definitions (3:00 pm – 5:00)
Feature Development and Feature Stapling (8:30 am – 9:45 am)
15 minute break
Content Types and Event Handlers (10:00 am – 12:00 pm)
1 hour lunch break
Custom Application Pages and Extending the Menu System with Action Items (1:30 pm – 2:45 pm) Instructor led Hands On Lab
15 minute break
SharePoint Solution Packaging and Deployment (3:00 pm – 5:00pm)
Hardware and Software Requirements:
- Laptop computer with a processor speed of at least 2.5 GHz with Hyper Threading or Dual Core Technology
- RAM capacity of 2 GB minimum (3-4 GB recommended)
Must be able to allocate a minimum 1 GB of RAM to the Virtual OS
- Operating System: Windows XP Professional or Windows Vista
- Additional Software: Adobe Acrobat, Microsoft XPS Viewer
- This course is not meant to provide an introduction to SharePoint or the .NET framework. Attendees are expected to have experience with the SharePoint platform as well as .NET development with Visual Studio.
- Registration is limited.
550 US dollars per person
(group discount rates available)
Catapult Systems, Houston
10370 Richmond Ave. Suite 1250, Houston, TX 77042
1. Click here to download the registration form
2. Complete the registration form and fax toll free to (877) 819-0945
Call 832-472-3648 or e-mail email@example.com for more information
Please refer to http://www.rafelo.com/sharepointtraining for the latest information.
Here’s what some of the attendees had to say about the last session:
“Rafael’s Developer Crash Course was excellent! It really was a crash course covering a lot of concepts in a short period of time. But every item covered was a practical, real-world solution that I can use as a .Net Developer to help our Administrators more easily manage our SharePoint farm. And he made it easy….” – Barry Thomas, Panhandle Energy
“I was excited about the class before it started and was not disappointed when it was over. You delivered everything I expected and more.” – Don McKenzie
“Rafael provided clear, step-by-step instruction as to the ins and outs of content management in Microsoft Office SharePoint Server 2007. I would recommend this class as an effective, inexpensive way to hone your SharePoint development skills.” – Troy Lanphier, Catapult Systems
“Rafael’s training series gets two thumbs up. The precision of this course was a balance of a technical and functional workshop to illustrate real life scenarios of business solutions utilized in our day to day corporate operations.” ”I recommend this course to developers and functional people who wish to add value to their organization and grow within the SharePoint community. Rafael, best wishes and continued success on all of your SharePoint endeavors.” – Reece Collins, Inseptions
“Prior to attending the class, I was convinced that I would need a great deal of C# training before I could begin to develop in SharePoint. Rafael’s class provided insight that allowed me to build and deploy solutions for my clients’ SharePoint environments.” – Marlene Lanphier, GUIO
This posting is in response to a comment I had on a previous posting; “Using the InputFormSection and InputFormControl to build Custom Application Pages that look like OOTB Pages”. One of the readers posted a comment asking how to go about using the submit button to post to a list. Needless to say, I didn’t feel that answering his question by replying to his comment would be the best response. So I’ve decided to post my response here, where its a little bit easier to elaborate on the subject.
Application pages can in fact be used to create list items, but there are a number of things to consider. The first and probably most important thing, is that application pages can be accessed from any site in your SharePoint farm. If the list the form is meant to write to is accessible globally this may not be much of a problem, but I’d have to question how that list was created and where it is stored. Application pages are part of what I consider to be a fairly modular development framework in SharePoint, and the scenario mentioned doesn’t sound very modular at all; a page that is deployed or accessible from every site, but the list it writes to is only deployed to one. What if the site containing the list is deleted? Or certain fields changed? The site administrator would likely be able to do either, but he/she wouldn’t be able to update the Application Page, which would likely break.
So how do I recommend using Application Pages to write to lists? There are many ways, most (if not all) of which would involve Features. The following is a sample approach:
1. Develop a site or site collection Feature that creates a list. Since we will be writing to this list from a Custom Application Page, I recommend that the list be hidden. This recommendation stems from the fact that we don’t want anybody accidentally deleting or modifying the list, which may impact the Application Page. Of course this would probably mean creating another page to view and/or edit list items; this could be a Content Page or Application Page.
2. Develop the Application Page that writes to the list created by the feature, including logic in it that checks if the feature is activated. If the logic determines that the feature is not activated, the page should display a message stating that the feature needs to be activated for the page to work.
3. Use Custom Actions and Custom Action Groups to create a link to the Application Page(s) from the “Site Settings”, or “Site Actions” menu.
I don’t mean to imply that an Application Page shouldn’t be used to save items to a single globally accessible list. But it requires even more consideration and planning than the scenario mentioned above. Actually, I’ve had to develop such pages; in one example the list resides in Central Administration and is created as part of a Feature scoped at the Farm level.
In another scenario, the list may not be hidden, or even created by the feature. The list may be manually created (to capture very specific criteria) by a site or farm administrator, in which case another Application Page may be used to capture the location of the list, and save it in the property bag of the site or site collection. The Application Page that writes to the list, fist looks at the property bag to determine its location, if the property has not been set, the page simply returns a friendly error.
Like the above mentioned scenarios, I’m sure there are hundreds more. The point is all of them require some thought. Unless strictly used to display information that you know is always available, an Application Page is rarely a solution as a whole. Take time to carefully plan and design your Application Pages, examine your solution from multiple angles making sure it doesn’t easily break. Remember, if you fail to plan you are planning to fail.
I’ll be presenting at the upcoming H-SPUG event this May. The topic will be:
Project Planning for SharePoint Implementations
Whether you are implementing SharePoint for the first time or for the hundredth time, very few things are going to be as important as a solid road plan. There are an infinite number ways to get between point A and point B, but what may appear to be shortest path may not be the best or quickest way to get there. To make matters worse SharePoint provides a large range of services; what works for one type of SharePoint implementation may not work for another. During this session, I will cover the many aspects of putting together a proper project plan and schedule for SharePoint. We will share lessons learned, approaches, key milestones, and tasks that should be part of almost every SharePoint related project plan; and provide a detailed overview of a real world project schedule for a successful SharePoint implementation.
The event will be held at Microsoft’s Houston headquarters: 2000 W. Sam Houston Pkwy. S., Houston, TX 77042, United States
Hope to see you there