Complex Type Custom Properties and Sharepoint .dwp file

.DWP files lets you add default values for a Webpart - this is really cool - this way you could ship multiple instance of same webpart just by changing the default values..

The things get messy when your custom propperties gets compleX. I was trying to put default value for a custome property of "Enum" type - tried following things - which didn't work

Enum Games
{
BasketBall,
BaseBall,
Rugby
}

<game xmlns="http://mynamespace">1</game>
<game xmlns="http://mynamespace" >Games.Rugby</game>

Finallly this worked
<game xmlns="http://mynamespace">Rugby</game>

Looks like "Rugby" is a string type but internally Sharepoint engine map this to Games.Enum

The most annoying part of this exersise was that SharePoint engine gives very cryptic error when you try ot drop webpart on a page. All it say is "One of your custom Properties could not be deserialize"

Wish MS could provide better technique to catch such error or alteast a callstack of code which throws this error

Tired of Adobe PDF loading... Try Foxit

I found this FOXIT PDF Reader(http://www.foxitsoftware.com/pdf/rd_intro.php) ...of course via google search :) It opens PDF files atleast 5 times faster than ADOBE.... I guess it does not load all dlls in the begining like ADOBE does...

"New wine in old bottle" - AJAX

Just remembered Steven Covey ' famous quote "New wine Old bottle" when I saw this posting
http://www.adaptivepath.com/publications/essays/archives/000385.php about AJAX(Asynchronous JavaScript + XML) -

We have been using Asynchronous Javascript with XMLHttp for almost 4 years now to dynamically updates some part of the browser without refreshing the whole screen but never thought of coined a name for this technique, But since Gooogle started using in Gmail and Google Maps, it become a buzzword in town. I guess you have to be famous to coin a pharse :)


Javascript/XML HTTP technique been existed since IE4 but I guess people were afraid of using it for couple of reasons,

1) Security - Since this could be potentially be a security bug (some hacker could gain control of your html page and then submit content to their server)

2) Not compatible with other browsers. The only other browser at time in radar was "Netscape" which needless to say didn't support such things. But with FireFox and new Mozilla browsers "AJAX" is getting the momentum

Request.Form, Request.QueryString or Request[] collection

This week couple of people asked me about Request object related question. The question was when should Request.QueryString() or Request.Form or simply Request[] to be used??

When you are sure that incoming HTTP request is in POST format - you should use Request.[] collection and when you are sure its a GET request you should use Request.QueryString[] collection


However when you are not sure if the Request is either POST or GET then you should simply use Request["some variable"] . The good ( or if you like to call it bad) part of Request[] collection is it will only store all the QueryString and FORM variables but it also contains your "Cookies"!!!!