SharePoint: Office Developer Conference, Day One
Man, my brain is full.
For those of you who don't know, yesterday was the first day of the Office Developer Conference, a three-day extravaganza of technical presentations covering all aspects of Office development, from client applications to server technologies to custom solutions presented by Microsoft partners.
I have to admit, one of the things I really enjoy about working here is easy access to the people who create the software I use to do so much of my job. Got a question about how Word uses XML? Walk down the hall and ask the guy who wrote the Word SDK. So now, for three days, developers from outside companies can get that same level of access.
And for me personally, this couldn't have come at a better time. Yesterday I sat through five presentations dealing with developing Windows SharePoint Services. More than just the technical information presented, I now feel like I've got a much better handle on how WSS is structured, why it works the way it does, and what the problems are that it was created to solve. The Q&A's were also a valuable opportunity for a writer-programmer like me to get a peek into what issues are on developers' minds.
The Opening Keynote was given by Richard McAniff, a Corporate Vice President for Microsoft Office. The two main technologies he stressed were XML and SharePoint. XML being the mechanism by which we enable the user to move their data into and out of the applications they use, and SharePoint as the tool that lets them collaborate on and store that information.
And here are some random technical issues that seemed to come up in a variety of ways throughout the WSS presentations:
· Seems nobody is a fan of Collaborative Application Markup Language (CAML), which is used to define sites and lists, including fields, views, or forms. The best practice seems to be an iterative approach: make a change in the CAML, then test that change to make sure it functions as you want. Then make another change, re-test, etc. You can't really debug CAML, or apply a schema to it. Yet CAML provides a vital function: it's the reason SharePoint can render hundreds of web sites so quickly without having to have a huge server farm. Call it a necessary evil (or at least, annoyance.)
(Here's a pointer to more information on CAML: Introduction to CAML.)
· Site definitions: Best practice seems to be, copy an existing site definition, rename it and then modify it. Try not to modify existing site definitions if you can help it. Microsoft reserves the right to make changes to those site definitions, so be aware that if you do modify the default site definitions, we might over-write your changes later.
· Concerning CAML and site definitions in general, I got the impression that the SharePoint team didn't realize so many developers would want to customize them so extensively. It seems like perhaps the SharePoint team thought that Web Parts would be the main avenue by which users developed sites. Certainly the developer story for Web Parts seems a lot more stream-lined and supported. That's just my impression, however.
· How does a site definition differ from a template? A template is actually just the changes a user has made to the properties of a site built based on an existing site definition. A site definition is a complete set of instructions for building a site from the ground up. The template stills needs the site definition it's based on to function; remove that site definition, and the template is broken.
· Customizing pages: When SharePoint renders a web page based on a page definition, it basically reads the user data from the back-end database, then plugs it into the page definition, which resides on the front-end server, and renders the page. That's one of the reasons SharePoint can render pages so quickly. The specific page the user is navigating to doesn't actually exist; it's a union of the specific data and the page definition. However, if you alter the page by editing the aspx, then SharePoint has to store more information in the database. This has three ramifications:
· Database size can increase, because more information about the page, not just the data, must be stored.
· Time to render can increase, since SharePoint has to load more information from the back-end database.
· Inheritance is broken; in other words, if you later make changes to the page definition, those changes do not get propagated to the customized page.
Because FrontPage alters the aspx of the page, if a user saves the page in FrontPage, that page is now customized. Not that that's necessarily undesirable; but if you let your users edit SharePoint pages in FrontPage, just be aware of what the ramifications might be.
· Mike Fitzmaurice gave a nice shout out to Office Developer content on MSDN during his SharePoint presentation on customizing and branding WSS. Here's the links to articles that discuss pretty much all the technical points I listed above (and probably much more coherently):
Branding a SharePoint Portal Server 2003 Site (Part 1 of 2)
Customizing SharePoint Sites and Portals (Part 1 of 3)
And with that, it's off to the InfoPath sessions…
Comments
- Anonymous
February 05, 2005
Andrew, this was a VERY informative post. I hope you can find the time to post more on the Office DevCon. Good job.