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
The Opening Keynote was given by Richard McAniff, a Corporate Vice President for
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
(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
· 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
· Database size can increase, because more information about the page, not just the data, must be stored.
· Time to render can increase, since
· 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
· Mike Fitzmaurice gave a nice shout out to Office Developer content on MSDN during his
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…