Object model?!

When looking into the SPFieldLookup-class you find the properties LookupField, LookupList and LookupWebId. LookupWebId and LookupField can easily be set via the object model. The documentation says that LookupList is read and writeable which is not true. Setting LookupList throws an exception stating out “Cannot change the lookup list of the lookup field.”.

SchemaXml and Regex to the rescue

The SchemaXml-property of a SPField can be used to manipulate the LookupList. One stumbling block is that you do not know the Guid of the LookupList currently stored in the schema. Even if you define a Guid inside your xml-field-definition SharePoint puts in an other Guid. Here a simple regular expression comes to help.

The code for connecting a site-column with a list somewhere in some web:

// Declarations (myWeb is the context given by a feature receiver scoped "web")
var rx = new Regex("List=\"([^\"]*)\"", RegexOptions.IgnoreCase | RegexOptions.ECMAScript);
var root = myWeb.Site.RootWeb;
 
// myListInstance is an instance of a SPList existing somewhere
var lookupField = (SPFieldLookup)root.Fields["MyLookupField"];
var xml = lookupField.SchemaXml;
xml = rx.Replace(xml, String.Format("List=\"{0}\"", myListInstance.ID.ToString("B")));
lookupField.SchemaXml = xml;
// Do not call update here!
// Quote from MSDN "Do not call the Update method when using the SchemaXml  property to modify a field."
 
// Fetch the field again and apply the web-id
var lookupFieldReFetch = (SPFieldLookup)root.Fields["MyLookupField"];
lookupFieldReFetch.LookupWebId = myWeb.ID;
lookupFieldReFetch.LookupField = "Title";
lookupFieldReFetch.Update(true);

This problem still persists in the beta of SharePoint 2010. I hope this will get fixed in the RTM. Creating a lookup-field-connection is far more easy by the way …

In a SharePoint project I’m working on it was necessary to get the default page of a publishing web in case where it differs from default.aspx.
 
In the environment the project takes place the “normal SharePoint user” is not allowed to use the SharePoint Designer. The page itself can be fully viewed by these users but the following code throws a SecurityException due to the missing “Remote interface”-permission.

// ... web is instantiated and disposed of course!
var pub = PublishingWeb.GetPublishingWeb(web);
var defaultPage = pub.DefaultPage;
 
// ....

In order to work in my projects environment this peace of code needs to be wrapped inside a resource-expensive SPSecurity.RunWithElevatedPrivileges-delegate. Makes absolutely no sense to me…

SharePoint 2010 has a lot of improvements for the “publishing infrastructure”. Lets hope this is fixed, too.

If you only want to display that field-value you can simply use the ControlMode-property and set it to Display. If you want to display only the date-part of that datetime just set the DateOnly-property to true…

Thats the theory. If you do it like that you get a nice Object reference not set to an instance of an object-error. The cause is

DateTimeField.set_DateOnly

Reflectoring the control reveals that when the control is in “DisplayMode” the inner DateTimeControl is not created and that is why DateOnly cannot be set.

Its seems this control was developed by a drunken programmer as my friend stated out a bug in this control a while ago.

We do not support modifying a custom site definition or a custom area definition after you create a new site or a new portal area by using that site definition or area definition. Additionally, we do not support modifying the .xml files or the .aspx files in the custom site definition or in the custom area definition after you deploy the custom site definition or the custom area definition.

So site definitions are a one way ticket. All your requirements (even future ones) must be implemented before you actually create sites based on your site definition! This is far from “real life”.

This “supported and unsupported-link” is not referenced within the SDK (MOSS or WSS). The SDK describes the nice way of creating site definitions, how to deploy them e cetera. Once deployed your site definition has to be immutable! But this fact is not mentioned inside the SDK!
Even more confusion is spread when you want to lock down SharePoint Designer (which is now available for free) following Microsoft’s kb article filed under http://support.microsoft.com/kb/940958/en-us. If you read the article you will see that it suggests to modify the existing onet.xml files so that the changes also affects already provisioned sites.

Microsoft tells us that changing the site definition after sites have been provisioned with it is unsupported but on the other hand writes a kb article where site definitions should be modified to reflect changes to already provisioned sites! Another example of how difficult communication is!

Conclusion

SharePoint is a static environment when you rely on the “xml-ways” of customizing SharePoint. This issue also appears when using Content Types. Once a Content Type is deployed Microsoft “does not support” changes in the Content Type xml-definition.

What gets clear when reading the kb article (http://support.microsoft.com/kb/898631/en-us) is that changing/updating via code is always supported. Perhaps its time to move away from the xml-based declarative approach to the code-based approach.

Lets hope SharePoint 2010 will fix all these issues!

Disguise

Unfortunately the list where the pages reside is hidden to the UI. So the user has no option to check-in the created page. The only way to access the list is to retrieve the id of the “pages-list” (e.g. via SharePoint Manager). Now you can pass it to the ManageCheckedOutFiles.aspx inside the _layouts-folder. Alternatively you can connect via SharePoint Designer and uncheck the “hide in browser”-option.

Your url looks like this: http://myserver/myweb/_layouts/ManageCheckedOutFiles.aspx?List=%7B6F145CFF%2D8779%2D4D38%2D8B11%2D6B37EBA0A76C%7D

You are now able to “overtake” the checked-out page for yourself for further editing. But your odyssey is not yet over!

If you want to check-in the document you get an error. It’s simply not possible! What helps is:

1. Copy the affected page with SharePoint-Designer
   
2. Paste it into the “pages-list”
3. Delete the old checked-out page
4. Rename the pasted page to the old page name
5. Now your page is fully visible!

Prepare for the future

Because the pages-list does not have any views defined its hard to help users. If you have the list-id of this list you can use every management-page to customize this list (e.g. _layouts/listedit.aspx?List=%7B6F145CFF%2D8779%2D4D38%2D8B11%2D6B37EBA0A76C%7D).

Conclusion

I believe this is a bug. Perhaps there will be a fix. But don’t rely on it … What is really annoying is the fact that this list is a “special list” and you cannot add views to it. So if you ever get a page that does not show: use your SharePoint tools!-)

Update

The customer had a lot of workspaces where this has happened. This bug is really annoying! I have colored (yes that nice orange) the important part to fix this problem.

Flow of actions

Here is what I did…

	Enable ContentType-Management
	List-Overview with enabled ContentType-Management. The ContentType “Task” is attached to the list.
	Field overview of the ContentType inside the “Task-List”. The field Status is named “Status”.
	Properties of the Field of the ContentType “Task” inside the list. The StaticName of the field is “Status” as one can see inside the red ellipse.
	The fields available when navigating to the properties of the ContentType “Task” inside the “Site Content Type Gallery” of the site collection. Note: One can already see that the “Status-Column” is named “Task Status” here.
	If you navigate deeper into the field properties of the base ContentType “Task” you see (inside the red ellipse) that here the StaticName is “TaskStatus”.

Bug

This is definitely a bug. These StaticName properties of the fields should be the same! What is even more weird is the fact that the Id’s of the fields are identical! Both have a guid of “c15b34c3-ce7d-490a-b133-3f4de8801b76″!

If you look inside the schema.xml of the default task list (found in 12/Template/Features/TaskList/Tasks/schema.xml) you see that the StaticName is set to “Status”. If you take a look inside the ContentType-definitions of the sharepoint-core (found in 12/Templates/Features/ctypes/ctypeswss.xml) you will notice that the name of the field with the id “c15b34c3-ce7d-490a-b133-3f4de8801b76″ is set to “Status”, too.

So I cannot explain why the fields in the ContentType “Task” are prefixed with “Task”. The field DueDate is also affected. Inside lists its StaticName is “DueDate” inside the ContentType its named “TaskDueDate”.

Conclusion

It seems that you can’t even rely on the StaticName! Instead always make use of the Id of a field!

Web Service

To work with SharePoint one has the option to use the “in-memory object model” or via Web Services. If your are dealing with SPListItems you will likely be using the List-Service and one of its methods GetListItems to fetch the items stored in a list. Nothing dramatic here.

The response will look like this (taken from the MSDN)

<listitems xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" 
   xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 
   xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" 
   xmlns="http://schemas.microsoft.com/sharepoint/soap/">
   <rs:data ItemCount="2">
      <z:row ows_Number_Field="6555.00000000000" 
         ows_Created="2003-06-18T03:41:09Z" 
         ows_ID="3" ows_owshiddenversion="3" />
      <z:row ows_Number_Field="78905456.0000000" 
         ows_Created="2003-06-18T17:15:58Z" 
         ows_ID="4" ows_owshiddenversion="2" />
   </rs:data>
</listitems>

As you see each item is represented by a z:row item in the xml-markup. Each field (column) is represented by a xml-attribute (ows_ID, ows_MyStaticFieldName).

Lets take their newlines from them

The trouble just started. If you have a field of type node which has multiline support all your newlines are now killed and transformed to spaces by the xml-parser!! I repeat you don’t have newlines anymore when fetching multiline-fields via the Web Service of SharePoint.

Believe it

Microsoft seems to be aware of this nice bug and it looks like this bug is known for a while. So why wasn’t this fixed in SP1?!

The famous w3c shows how to handle newlines (and other special characters) in xml-attributes. So a simple (html-) encoding of special characters would solve the problem. But that was to easy to implement in SharePoint?! I don’t know…

The workaround (as stated in KB928316) “creating a custom Web Service” works fine. You create your own Web Service and can now correctly encode the data or simply put the values inside the xml-node.

Conclusion

I cannot believe you have to do this! It takes extra time no one would think about or pay for.

In my opinion the Web Service of SharePoint becomes totally useless.
I haven’t tested it which richtext-fields but I fear problems will occur there, too.