I received some feedback on the Sharepoint extension article that I would like to share (I had to change < to [ in the code to get CommunityServer to display it):
Hi,
Thanks for sharing this great code. I encountered 2 problems and could find some workaround:
1) Columns with a number data type would throw an exception on a French Machine due to the impossibility to convert xml number automatically because of the decimal sign (which is "," in french). I guess it may also be the case in other languages. I used this workaround :
<![CDATA[if ( col.DataType == typeof(Single) )
newRow[col] = XmlConvert.ToSingle(val);
else
newRow[col] = val;
]]>2) GetListItems return data base on the default view if no view is specified. If the default view has some filter, you will collect a filtered list of items. I used this workaround:
<![CDATA[XmlElement query = ListInfoNode.OwnerDocument.CreateElement("Query");
query.InnerXml ="[WHERE>[GT>[FIELDREF Name='\"ID\"' />[VALUE Type='\"Counter\"'>0[/VALUE>[/GT>[/WHERE>";
]]>
Frédéric LATOUR
About the second remark: that is a great trick, Frédéric! Thanks for sharing.
Now about the converting of numerics in non-english cultures. I think that the XML returned by the Sharepoint web service is not using English or American formatting, but rather the InvariantCulture. Now rather than making different conversions for different types (have you considered Double, DateTime, etc...), I would prefer to let the framework do the figuring. I think that everything will work out fine if you set the CurrentCulture of the thread to CultureInfo.InvariantCulture while copying data from the XML to the DataRow. I haven't had the time to test yet, but give it a try:
<![CDATA[System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.InvariantCulture; ]]>
Don't forget to set your culture back to it's original setting.
POSTSCRIPT:
I have tested this situation now and it seems indeed to be solved by setting the current culture to InvariantCulture. Before the foreach loop (the one that copies fields from XML to the datatable), you insert this code:
<![CDATA[System.Globalization.CultureInfo oldCulture = System.Threading.Thread.CurrentThread.CurrentCulture;
System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.InvariantCulture;
]]>
and after the loop, you set you preferred culture back:
<![CDATA[System.Threading.Thread.CurrentThread.CurrentCulture = oldCulture;]]>
Ready!
When you want to create connectable web parts in ASP.NET 2.0, the preferred way to pass information is by specifying an interface with one or more properties. You can read up on how it works in this article by Carlos Aguilar Mares (based on beta 1). The nice thing of using interfaces is that you can have an IStringValue interface that just returns a string value and have an IZipCode interface deriving from IStringValue without adding or overriding any members. Of course, a zip code is a string, but a string is not always a zip code. This way, you can use zip code providers to feed both zip code consumers and consumers of string values.
To allow my connection providers to be connected to your connection consumers, they must be based upon the same interface for passing information. To make it easy for third party developers to connect to each others web parts, in beta 1 Microsoft included a small number of very simple interfaces. The most basic of them all was IField, which allowed you to pass an object (any object). They also included IParameters (set of name-value pairs), IRow (collecion of objects) and ITable (collection of isomorphic IRows). If your part does something very specific, you should specify your own interfaces, to make sure that only parts providing the right kind of info can connect to yours. But if you want your part to work with as many other parts as possible, you want to settle on a widely known interface, preferably from the framework.
Now in beta 2, all of these basic interfaces seem to have disappeared. Why is that? You can easily create these interface yourself, of course, but my interface would then be different from yours and parts from different vendors could never connect (well, you could start writing connection transformers for every combination, but that's another story).